Portability and BS
William E. Davidsen Jr
davidsen at steinmetz.ge.com
Thu May 19 04:29:44 AEST 1988
In article <11530 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
| In article <524 at wsccs.UUCP> terry at wsccs.UUCP writes:
| >Summary: Portabilty and BS
|
| It was an apt summary: The text (here deleted) had a little to do with
| portability, and was mostly BS. In a number of closely spaced further
| postings, the same person flamed Sun's SPARC architecture and/or
| compilers. The curious thing, to me, is that while terry at wsccs
| complains that SPARC makes her or his `portable' code fail, I have
| never heard the same from anyone else working with a Sun-4. But
| perhaps it is just a coincidence that Terry's `portable' code fails
| while everyone else's runs.
Without commenting on the original issue (it's getting lost in the
heat) I would like to say that Terry is *not* the only person getting in
trouble on the Sun4. A number of major machines (VAX, 80x86, 68xxx) lose
performance when alignment is not preserved for 2 byte and 4 byte
quantities, but they will access the data.
My Sun VAR told me that the reason he had to tweak my code was that I
had used this in a packed data structure. He was unable to access longs
which were not zero mod four. He showed me the diffs and he had unpack
and pack with byte moves. The Honeywell L66/68 have a similar 'feature'
when accessing 36 vs 72 bit words.
Since there is no alignment algorythm which applies in all cases,
exchanging binary data requires some assumption, and that is "no
alignment.' Any program which manipulated binary data could be subject
to problems.
Whatever the value of the original posting, and I feel that it is
correct to say that the code was not portable, there are a number of
people who have been bitten by this and similar side effects.
--
bill davidsen (wedu at ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
More information about the Comp.lang.c
mailing list