Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!rehrauer
From: rehrauer@apollo.HP.COM (Steve Rehrauer)
Newsgroups: comp.sys.atari.st
Subject: Re: cross-compiling
Message-ID: <4dba8b38.20b6d@apollo.HP.COM>
Date: 31 Oct 90 15:34:00 GMT
References: <1990Oct29.235921.23294@math.lsa.umich.edu>
Sender: root@apollo.HP.COM
Reply-To: rehrauer@apollo.HP.COM (Steve Rehrauer)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 30

In article <1990Oct29.235921.23294@math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes:
>Just a little FYI: I discovered today (sigh) that the C compiler on
>Sun Sparcstations always tries to align structure elements on longword
>boundaries. Thus my "unix-compatible" (hah) TOS disassembler fails to
>work, because there are extra pad bytes inserted to my structure declarations.
>(e.g.,
>	struct GEMHEADER {
>		short GEM_MAGIC;
>		long GEM_SEGS[GEM_NSEGS];
>		long reserved;
>		long unused;
>		short GEM_FLAG;
>	}
>This defines the start of a TOS executable file. The structure, as defined,
>is 28 bytes on an ST, and 32 bytes on a Sparc. Bleah.)
[...]
>Of course, if you're only writing for 680x0 architectures, this won't ever
>be a problem (?) since data is aligned on word boundaries (2 bytes, 16 bits)
>and not longword boundaries (4 bytes, 32 bits). [but watch out for those
>single-byte declarations!  }-)  ]

Well, not quite.  I can't speak for other vendors, but Apollo C on our 68k
workstations can also insert padding between structure members to long-align
them.  (A 32-bit fetch of a long-aligned object will run slightly faster
than a fetch of an odd-word-aligned object.)  On a DN4500, for example, your
example struct would also be 32 bytes big.
--
"I feel lightheaded, Sam.  I think my      | (Steve) rehrauer@apollo.hp.com
 brain is out of air.  But it's kind of    | The Apollo Systems Division of
 a neat feeling..." -- Freelance Police    |       Hewlett-Packard