Skip site navigation (1)Skip section navigation (2)
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 +0000
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: <http://docs.FreeBSD.org/cgi/mid.cgi?20010216114244.G90937>