Xref:	news-dnh.mv.net comp.os.msdos.djgpp:2312
Path:	news-dnh.mv.net!mv!news.sprintlink.net!tank.news.pipex.net!pipex!dispatch.news.demon.net!demon!mail2news.demon.co.uk!chocolat.demon.co.uk
From:	Paul Shirley <PS AT chocolat DOT demon DOT co DOT uk>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Actual sizes of structs under djgpp?
Date:	Sat, 30 Sep 95 19:56:02 GMT
Organization:	a loose end.
Lines:	40
References:	<DFp6wJ DOT FBG AT jade DOT mv DOT net>
Reply-To:	PS AT chocolat DOT demon DOT co DOT uk
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway:	from newsgroup comp.os.msdos.djgpp

<DFp6wJ DOT FBG AT jade DOT mv DOT net> digisoft AT eis DOT net DOT au "Paul" writes:

>> I'm trying to transfer a lot of structures and their information from a
>> 68000 machine to a PC and it would help if there was some rule about length
>> of structs and their components. It would also help if 86s used a rational
>> byte order:-)
>> Brian O'Donnell
>> TCD Library
>> odonnllb AT tcd DOT ie
>
>It's much the same as on the 68000.  The 80x86 chips work better with 
>the proper alignment of data structures.  Longs align on 4 byte 
>boundaries, chars align on byte boundaries.  I think short's align on 
>2 byte boundaries, but I havn't had occasion to check this in a long 
>while.

With 1 big differnence, unaligned word and long access will crash a
68000,60010 and cause poor performance on higher cpus.

>
>If you design your structures with all of your longs first, then 
>words and lastly bytes you should get fairly good alignment.  Of 
>course there is something (maybe a pragma ??) that you can use to 
>tell gcc not to optimize alignment.

look under 'c extensions/variable attributes' in info gcc.

Since your problems stem from portability you should not be worrying
about structure layout without a compelling reason (hardware mapping
or extreme shortage of memory perhaps). Work out what the source 68K
ones looked like then read them field by field and let the compiler
work out where to put them.

As you've discovered its not safe to assume anything about what a
compiler has done.


-- 
Paul Shirley: too lazy to change this sig.

- Raw text -