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