Alignment issues and SPARC (commentary)

[Gary Wisniewski]

I have recently ported 50K lines of C code to the SPARC and have discovered
that:
	1.  From the C programmer's point of view, the SPARC is just another
	    architecture.
	2.  I regretted making some assumptions about the viability of
		memcpy(buf, (char *)&h, sizeof(h));
	    where 'h' is anything but a char.
	3.  Porting from Sun-3 to Sun-4 took less time than porting from
	    Sun-3 to PC.
	4.  The Sun-4 compiler has some minor problems, but cost me little
	    time or effort to overcome.

To me, ALL of the above (even 4) simply constitute the work at hand.  I do
not soon expect to live in a world where machine architects restrain
themselves from imposing curious restrictions.

Recent discussions on the net have criticized the SPARC because it has made
porting more of a pain.  Yes, I agree, but why flame the architecture?  Why
not use the new architecture as a forum for exploring the current limitations
on portability and how we can move beyond them?  Clearly, C does not address
many issues of portability, such as packed structure compatibility (especially
for files), data type formats, etc.  Most of these are important only for
data exchange.  I would rather discuss these issues than flame a particular
architecture.

Of course, if there really are inconsistencies in an architecture, or if
a compiler incorrectly accounts for particular architectural anomaly, then
these things are worth considering.  Such fact-finding trips often involve
blind-alleys, and maybe we're going through the Sun-4 fact/fiction pruning
process.  My intent was not really to criticize those on the net (I KNOW
BETTER :-) ), but simply to indicate my opinion that SPARC is not so much
of a problem as some posters might make it out to be.

-- 
Gary J. Wisniewski				  Apex Software Corporation
{allegra,bellcore,cadre}!pitt!darth!apexepa!gary  Phone: (412) 681-4343