Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: RISC data alignment
Summary: not a RISC-vs-CISC issue
Message-ID: <573@cresswell.quintus.UUCP>
Date: 25 Jan 88 03:59:49 GMT
References: <2635@calmasd.GE.COM>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 29

In article <2635@calmasd.GE.COM>, gjo@calmasd.GE.COM (Glenn Olander)
asks about data alignment in RISCs and is worried that
> If this is true, then it would seem to also be true that a C structure
> could have different lengths, depending on whether it was compiled 
> on a RISC or non-RISC machine.  Further, it would seem that
> if that C structure were written out to a file, it could only be read
> properly by a machine of the same type as that which wrote it.

Yes, both of these problems exist.  But 68010s require 16-bit alignment
for 16-bit and 32-bit data, whereas 68020s do not, so the problem may
exist even within a processor family.  (The same is true of IBM's
mainframes:  the old models had stricter alignment requirements.)
Even on a single machine, there is no reason to expect two compilers
to lay structures out the same way.  There is even one machine where
the byte sex is determined at powerup (if I've read the manuals
properly), so a data file might written by one program might not be
readable by another, even though both used the same compiler and
the same #include file.  Then of course there are floating-point
differences...

This isn't really a C problem, either.  The problem exists in any
language having records.

Also, even on machines which don't require 32-bit alignment, there
may be a substantial speed advantage in aligning the data anyway.
(We've seen figure of 30% for C-coded examples.)  So a compiler
may well align things for speed.

There are two solutions: write data files as text, or use XDR.