> 	Items within aggregates that are forced to be unaligned (records,
> 	common blocks) should generate compile-time warning messages and
> 	inline byte extract/insert code.  Users must be educated that the

> Note the text "inline byte extact/insert code".  This implies [...]
> that the compiler must emit code to do the fixup on the fly.

> Our compiler does not do it.  Indeed, it's difficult for the compiler
> to know if access is unaligned at compile time, if its being passed a
> pointer in a function.

I wonder if it might be worth adding an __unaligned__ attribute,
syntactically parallel to const or volatile, that causes the compiler
to assume that the object could be misaligned?  You'd pay that "factor
of 30" speed penalty, but that's a lot less than you'd pay if you
trapped to the kernel.  (Though admittedly the latter incurs *no*
penalty unless it is *actually* misaligned; __unaligned__ would pay at
least some penalty even if the actual pointer happened to be aligned.)

Actually, __attribute__((__packed__)) already does something very much
like this.  I've been unable to make it work without involving a struct
type, which works but is a bit hacky.  On the SPARC, I tried

extern void bar(int);
struct blah { int v; } __attribute__((__packed__));
void foo(struct blah *x) { bar(x[0].v); }

and cc -S indicates that this does in fact do four ldub instructions
instead of a single ld.  Something similar will presumably work on the
alpha (I don't yet have a machine running NetBSD/alpha to try it on or
I would).

As I say above, I've been unable to make __packed__ work this way
without hanging it off a struct.  This presumably could be fixed
without *too* much effort; somehow gcc has tagged the int it's trying
to load as potentially misaligned in the above, and it ought to be
possible to do that without having to inherit it from a struct.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B