Date: Tue, 30 Jan 1996 15:08:25 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Cc: current@freefall.freebsd.org, dyson@freefall.freebsd.org Subject: Re: Optimization topics Message-ID: <199601300408.PAA18640@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Specifically, it should be possible to run FreeBSD with the unaligned
>access bit set to disallow unaligned access of word/dword/qword objects.
I implemented this in Minix about 5 years ago. My compiler generates
many misaligned access (it forgets to align switch tables) and gcc
generates a few (e.g., it generates pessimized inline code for assigning
poorly (but correctly!) aligned structs:
---
struct foo { char x[4096]; };
struct bar { char pad; struct foo slow; };
void misaligned_copy(struct bar *p, struct bar *q)
{
p->slow = q->slow;
}
---
so my alignment trap handler silently clears the alignment check in the
flags and returns (printing a warning was too annoying and not printing
a warning wasn't annoying enough for me to fix the compilers :-).
>At the very least, the kernel code should be clean of this cruft.
It isn't easy to check for alignment in the kernel because the alignment
trap doesn't apply in ring 0.
>In Windows95, some programmers apparently believe that adding 3 bytes
>to the end of a packed structure containing a byte followed by 20
>longs means "align to a longword boundry" -- at least that's what
>the comments in the DDK header files say.
>Clearly, these people never ran their own code in a kernel debugger,
>or they simply failed to see the significance of unaligned access.
Well, alignment to 32-bit boundaries is standard for the i386 (Unix)
version of gcc. The longs would be automatically aligned and the 3
bytes at the end would waste 4 bytes of space.
There is a problem for alignment of doubles. They should be aligned
on 64 boundaries but ABIs specify only 32-bit boundaries
>Many of the problems derive from unaligned stacks being passed down
>to otherwise "correct" code. Fie.
This isn't a problem for FreeBSD (except when the temporary kernel stack
was misaligned in an old version :-).
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601300408.PAA18640>