Path: utzoo!utgpu!attcan!uunet!cbmvax!ditto
From: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Newsgroups: comp.sys.m68k
Subject: Re: quad-aligning the 68020 stack
Summary: Not needed for local (to particular machine type) data.
Keywords: 68020 stack longword alignment quad
Message-ID: <4458@cbmvax.UUCP>
Date: 10 Aug 88 02:01:10 GMT
References: <2194@uhccux.uhcc.hawaii.edu> <4431@cbmvax.UUCP> <2727@winchester.mips.COM> <4434@cbmvax.UUCP> <2641@pt.cs.cmu.edu>
Reply-To: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Organization: Commodore Technology, West Chester, PA
Lines: 41

In article <2641@pt.cs.cmu.edu> ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) writes:
>In article <4434@cbmvax.UUCP> ford@kenobi.cts.com (Mike "Ford" Ditto) writes:
>>One related subject that should be considered with the 64-bit chips in
>>mind, however, is that of alignment in portable data structures, i.e.
>>data files on disk or headers in network packets which will have to
>>be described and used on machines of various types and sizes.

 [ ... ]

>I disagree.  I'd rather pack my structs in the most reasonable way for 
>that machine, and convert to a canonical representation (like that specified 
>by SUN's XDR, for example)  for the networked or other heterogenous 
>environment.

That is what I said, isn't it?  If not, I'll summarize:  Don't worry about
aligning data for future (or any other) cpu archetectures unless you are
designing a machine-independent data format.  Just use whatever works best
on the machine it's running on.  On the 68020 this means align longword
AND 64-bit data on 32-bit boundaries.

>In Sun's Unix, for example, you have the 'htonl' and various byte ordering 
>macros and routines for working this all out.

Even these aren't enough for the assortment of machines existing today.
What about 64-bit machines where both "int" and "long" are 64 bits?
Should htonl() swap only the bottom 4 bytes or all 8?  And how do you
declare a "network long integer" (32 bits) anyway?

>Someone will always come up with an archictecture that won't fit in
>with your packing scheme.  If you find one that does happen to match, 
>consider yourself lucky and enjoy the potential performance advantage.

I think that sums it up quite well.

-- 
					-=] Ford [=-

	.		.		(In Real Life: Mike Ditto)
.	    :	       ,		ford@kenobi.cts.com
This space under construction,		...!ucsd!elgar!ford
pardon our dust.			ditto@cbmvax.commodore.com