chris@mimsy.UUCP (Chris Torek) (05/17/88)
In article <524@wsccs.UUCP> terry@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@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. There may be (and probably are) bugs in the Sun-4 compilers that are now available. There are enough bugs in those supposedly stable, and much longer tested, 4BSD and AT&T SysV compilers, that I would be very surprised if no one ever found a bug in Sun's SPARC compilers. The bugs, though, are likely to be in little-used corners in the compiler: things like `double d; ... d *= d == 3.14;'. Terry complains about other things: things like variable argument lists and structure padding, things that have never been guaranteed anywhere. Code is made portable by virtue of not assuming those things that are not guaranteed. If you write code using variable argument lists and do not stick to <varargs.h> (or, now, <stdarg.h>), your code is by definition not portable. In one of those other articles Terry says something that amounts to `my code runs on many machines, therefore it is portable'. It is not so. An example can only disprove portability: if some code fails on a conforming system, that code is *not* portable. If the code runs, that tells you only that any constraints the code may violate are not important on that system. It is just like saying `2 is even; 8 is even; 6 is even; 24 is even; aha, all whole number are even.' One counterexample disproves it: `7 is not even: not all whole numbers are even.' Terry's code does not run on a Sun-4. Unless the Sun-4 does not conform to K&R (or perhaps the dpANS), that means Terry's code is not portable. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/19/88)
In article <11530@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: | In article <524@wsccs.UUCP> terry@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@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@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
hutchson@convex.UUCP (05/19/88)
This alignment issue is not so simple. In the IBM 360 family, the 360
machines required "ints" to be aligned mod 4; the 370 and
later processors did not. In the M68xxx family, the 68008 imposes no
alignment restrictions; the 68000 requires "shorts" and "ints" to be aligned
mod 2; the 68010 (fill in the blank); the 68020 again relaxes the alignment
restrictions.
Conclusion: regardless of what your favorite language standard says,
if (2^n)-byte quantities (n<4) are not aligned mode (2^n), the resulting
program is not portable. Having used various members of the 68000/360/600
families, I automatically align everything. Tisn't difficult, not at all...henry@utzoo.uucp (Henry Spencer) (05/27/88)
> This alignment issue is not so simple. In the IBM 360 family, the 360 > machines required "ints" to be aligned mod 4; the 370 and > later processors did not... the 68020 again relaxes the alignment > restrictions. Remember, too, that both the 370 and the 68020 impose serious performance penalties on unaligned accesses. Most any unaligned-operand machine will end up doing so, unless it only has an 8-bit memory bus. Alignment is *always* a good idea. -- "For perfect safety... sit on a fence| Henry Spencer @ U of Toronto Zoology and watch the birds." --Wilbur Wright| {ihnp4,decvax,uunet!mnetor}!utzoo!henry