From owner-freebsd-alpha Thu Feb 15 16:42:58 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id CE7B737B491 for ; Thu, 15 Feb 2001 16:42:53 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id LAA15265; Fri, 16 Feb 2001 11:42:49 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01K06DHJICMOO2JK4Y@cim.alcatel.com.au>; Fri, 16 Feb 2001 11:42:41 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f1G0gj069192; Fri, 16 Feb 2001 11:42:45 +1100 (EST envelope-from jeremyp) Content-return: prohibited Date: Fri, 16 Feb 2001 11:42:44 +1100 From: Peter Jeremy Subject: Re: unaligned access In-reply-to: <200102160013.RAA10748@usr08.primenet.com>; from tlambert@primenet.com on Fri, Feb 16, 2001 at 12:13:39AM +0000 To: Terry Lambert Cc: Peter.Blok@inter.NL.net, freebsd-alpha@FreeBSD.ORG Mail-followup-to: Terry Lambert , Peter.Blok@inter.NL.net, freebsd-alpha@FreeBSD.ORG Message-id: <20010216114244.G90937@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <000001c09746$af96e2a0$8a02a8c0@ntpc> <200102160013.RAA10748@usr08.primenet.com> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 2001-Feb-16 00:13:39 +0000, Terry Lambert wrote: >> Thanks for the hints. One big cause was the embedded alloc routines, that >> doesn't do aligning. The next buffer allocated was unaligned, because the >> previous size was unaligned. I haven't looked closely enough to the >> structures. I also had one unaligned access in a varargs construction. >> Haven't found the cause yet. > >But remember that your problem is not the fixups themselves, >but that the code does not operate in the presence of fixups, >which it should. That assumes that the code is not time critical and is not trying to perform atomic operations on non-aligned objects. Each fixup implies a trap to kernel mode and then emulating the instruction - this is at least 2 orders of magnitude slower than if the reference was aligned. If unaligned accesses are printed, that probably adds another couple more orders of magnitude slowdown (even graphical console I/O is glacial compared to instruction issue rates). Atomic accesses are inherently incompatible with non-aligned objects. I didn't keep the head of the this thread, but I've also found that "all the world's a VAX" (or at least an i386) is still alive and healthy in the freeware world. There's a _lot_ of code that assumes that ints, longs and pointers are all 32 bits and you can safely store a pointer in an int. Most of these assumptions are likely to lead to segmentation violations. Compiling your code with lots of warnings enabled can be very enlightening. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message