Path: utzoo!attcan!uunet!cbmvax!ditto
From: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Newsgroups: comp.sys.m68k
Subject: Re: quad-aligning the 68020 stack
Summary: 64-bit alignment is not useful for in-memory objects & structures
	 but is useful for data to be shared between different systems.
Keywords: 68020 stack longword alignment quad
Message-ID: <4434@cbmvax.UUCP>
Date: 8 Aug 88 02:27:00 GMT
References: <2194@uhccux.uhcc.hawaii.edu> <4431@cbmvax.UUCP> <2727@winchester.mips.COM>
Reply-To: ford@kenobi.cts.com (Mike "Ford" Ditto)
Organization: Commodore Technology, West Chester, PA
Lines: 69

In article <4431@cbmvax.UUCP> ditto@cbmvax.UUCP (That's me) wrote:
>For real 32-bit 68020 systems, I am a firm believer in keeping all
>stacks and structures longword aligned at all times.

In article <2727@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes:
>Right philosophy, but consider thinking further ahead to 64-bit objects,
>at least.
 [ ... ]

I don't see a real reason for this.  Admittedly, the older 68000 compilers
that only aligned to 16 bits were a mistake, but that is because the 68000
has a 32-bit archetecture.  I can't imagine an extention to the 68000
archetecture that will have objects larger than 32 bits (other than floats)
nor an object-code-compatible chip with a wider-than-32-bits data bus.
64-bit chips and memories are certainly on their way to popularity, but
they really don't have much affect on 680x0 performance decisions, or
vice-versa.

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.  If you
create a data structure like:

	struct myrecord
	{
	    short   a;
	    long    b;
	    long    c;
	    quad_t  d;		/* Assume quad_t is a 64-bit integer */
	};

you could have some problems on several types of machines.  The first
problem is that on a 16-bit machine like the 8086, for example, the "b"
field is at offset 2, while a 68020 compiler should put it at offset 4
(skipping 2 bytes after "a").  The next problem is analogous for the "d"
field; suppose that on a 68000 quad_t is typedefed as long[2].  The
compiler would put "d" at offset 12, which is fine for a 68020, but a
machine with instructions to access 64-bit data on a 64-bit bus would
work faster if "d" were at offset 16, a 64-bit boundary.

What this all means, is that such structures should be *explicitly*
padded so that they will have a high probability of having the same
meaning on any machine.  In the above example, a "short" dummy field
should be placed after "a", and a "long" dummy field placed after "c".

This is not only for efficiency reasons, but also because a larger
machine might not have a way to declare a struture with a structure-
packing method that is inefficient for its archetecture.  For example,
if I write a program on my Z-80 (8-bit) system that writes its output
file in this format:

	struct myrecord
	{
	    char    a;		/* 8 bits at byte offset 0 */
	    short   b;		/* 16 bits at byte offset 1 */
	};

It is impossible to declare or reference that structure type in a
reasonable way on a 68000.  A wise programmer would have put a
one-byte pad field between a and b.

-- 
					-=] Ford [=-

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