🚀 go-pugleaf

In article <514@aldetec.oz.au> hausler@aldetec.oz.au (Graham Hausler) writes:
>I have a problem with gcc, and wonder if there is a quick solution to it...
>I am developing communications on an m88k system to communicate with an m68k
>system, using gcc, but am having trouble with default alignments within
>structures....
>
>The m68k likes to align on even addresses, but the m88k wants to align on
>4-byte addresses, making the use of 'short's and 'char's within structures
>dangerous.... (I know the RISC m88k loves 4-byte addresses/operations..)
>
>Does gcc support 'packing' structures, ie only allocating the 'sizeof' the
>element, and not attempting to align the next element on the next 4-byte
>address (for the m88k). I would be happy if I could get it to use just 
>even address alignment. I have tried using the __align__ attribute, but with
>no effect ... I am using gcc-2.1
>
>Please email any suggestions, thanks
>Graham Hausler.
>

I'm posting to possibly save others the effort of making a similar response.

I just tried compiling

struct foo {int a,b; char c,d; short e;} foo;

f() { return foo.c + foo.d + foo.e; }

with gcc 1.37.  It put c at offset 8, d at offset 9 and e at offset 10.

So it seems like this gcc is doing what you want, aligning to natural
boundaries.  A compiler that did not do this would not be useful in
compiling many device drivers and perhaps other code.  I would be a
little surprised if any gcc for a machine like the 88k did not align to
natural boundaries.  When you do 'gcc -v ...' does gcc pass cc1 any
funky options?

I do not know what you mean about the 88k preferring 4-byte numbers.  It
can do a load-byte or load-short as well at it can do a load-word.  Its
registers are 4 bytes wide, but so are those of all 32-bit
microprocessors.

I hope this helps.

	Rob Bedichek    robertb@cs.washington.edu