Date: Fri, 16 Feb 2001 11:42:44 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Terry Lambert <tlambert@primenet.com> Cc: Peter.Blok@inter.NL.net, freebsd-alpha@FreeBSD.ORG Subject: Re: unaligned access Message-ID: <20010216114244.G90937@gsmx07.alcatel.com.au> In-Reply-To: <200102160013.RAA10748@usr08.primenet.com>; from tlambert@primenet.com on Fri, Feb 16, 2001 at 12:13:39AM %2B0000 References: <000001c09746$af96e2a0$8a02a8c0@ntpc> <200102160013.RAA10748@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001-Feb-16 00:13:39 +0000, Terry Lambert <tlambert@primenet.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010216114244.G90937>