gary@apexepa.UUCP (Gary Wisniewski) (05/20/88)
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-4343gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/24/88)
In article <326@apexepa.UUCP> gary@apexepa.UUCP (Gary Wisniewski) writes: > 2. I regretted making some assumptions about the viability of > memcpy(buf, (char *)&h, sizeof(h)); > where 'h' is anything but a char. What's the problem? memcpy() certainly does not require any particular alignment of the data it copies. (Overlaps may yield surprises, though.)
gary@apexepa.UUCP (Gary Wisniewski) (05/25/88)
In article <7959@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <326@apexepa.UUCP> gary@apexepa.UUCP (Gary Wisniewski) writes: >> 2. I regretted making some assumptions about the viability of >> memcpy(buf, (char *)&h, sizeof(h)); >> where 'h' is anything but a char. > >What's the problem? memcpy() certainly does not require any particular >alignment of the data it copies. (Overlaps may yield surprises, though.) My original posting contained an unfortunate transposition of ideas. I intended to say: 2. I regretted making some assumptions about the viability of *((type*)buf) = h; where 'type' is not the type of 'h'. Sounds better, doesn't it? The memcpy construction is, of course, portable unless the format of 'buf' is in question (memcpy a structure to a char buf, then extract items separately--naughty.) Sorry for any confusion or alarm. -- Gary J. Wisniewski Apex Software Corporation {allegra,bellcore,cadre}!pitt!darth!apexepa!gary Phone: (412) 681-4343