chris@mimsy.UUCP (Chris Torek) (05/19/88)
In article <10886@steinmetz.ge.com> davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: > Without commenting on the original issue ... I would like to say that >Terry is *not* the only person getting in trouble on the Sun4. (Probably not; but no one else seems to immediately denounce the machine because of this.) >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. On the other hand, a number of major machines (Pyramid, before the microcode tweak that allowed *(long*)((addr&~3)+2); CCI/Harris/Sperry Power 6/32; and as you mention, some Honeywell machines) have restrictions like those in the SPARC architecture. As far as I know, the Pyramid still disallows short and long word accesses on odd byte addresses, as does the 68000 and 010 (but not 020) and the venerable PDP-11 series. > Since there is no alignment algorythm which applies in all cases, >exchanging binary data requires some assumption, and that is "no >alignment.' Exchanging binary data has more than just alignment problems: aside from integer endian-clashes, there are a multitude of floating point formats. Not even the number of bits per byte is fixed. Portable programs rely on some other method of exchanging data (RPC library, ASCII interchange, etc.). As long as the claim is only `I do not like it', I shall stand aside. I am not unsympathetic---I had to fix numerous Vaxisms in Gosling Emacs when we first got our Pyramid (one of those that did not support *(long*) unless the address was 0 mod 4); finding all of these was no fun at all---but when someone claims that the machine is `broken', or does not abide K&R, or various other falsehoods, I will post corrections. -- 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/23/88)
In article <11567@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <10886@steinmetz.ge.com> davidsen@steinmetz.ge.com >(William E. Davidsen Jr) writes: ...A lot of my stuff, commented... >Exchanging binary data has more than just alignment problems: aside >from integer endian-clashes, there are a multitude of floating point >formats. Not even the number of bits per byte is fixed. Portable >programs rely on some other method of exchanging data (RPC library, >ASCII interchange, etc.). The portable method of writing binary data is to output a series of bytes, each containing 8 bits of data, LSB first. On a 32 bit 2's complement machine this is natural. On other machines it is doable. I have written portable data files on a Cray which may be read on a PC using BASIC. It gets *real* ugly on a 1's complement machine, but in no way undoable in portable C. Bit per byte is usually fixed by the data transfer program, using a file transfer protocol or mag tape. I've sent the data to a DEC-20, which I *think* is 36 bits, using the tenex FTP mode. My point here is not that you are wrong, but that the problem is resolvable without vast trickery, and that there are some of us who are doing it. >As long as the claim is only `I do not like it', I shall stand aside. >I am not unsympathetic---I had to fix numerous Vaxisms in Gosling Emacs >when we first got our Pyramid (one of those that did not support >*(long*) unless the address was 0 mod 4); finding all of these was no >fun at all---but when someone claims that the machine is `broken', or >does not abide K&R, or various other falsehoods, I will post >corrections. >-- >In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) >Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris I've been known to correct a posting containing bad info, too. I can ignore stupid opinion, but I hate to see BS presented as facts. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
guy@gorodish.Sun.COM (Guy Harris) (05/25/88)
> >Exchanging binary data has more than just alignment problems: aside > >from integer endian-clashes, there are a multitude of floating point > >formats. Not even the number of bits per byte is fixed. Portable > >programs rely on some other method of exchanging data (RPC library, > >ASCII interchange, etc.). > > The portable method of writing binary data is to output a series of > bytes, each containing 8 bits of data, LSB first. This doesn't refer to a *particular* way of doing things; ASCII interchange certainly outputs "a series of bytes, each containing 8 bits of data (although one of them will always be zero)...". If you are referring to, say, dumping a 32-bit quantity out by dumping it as 4 8-bit bytes, in a particular order, that is certainly *a* way, but equally certainly not *the* way. ASCII interchange is another; for that matter, the 4 bytes can be dumped in any one of several byte orders. Also, byte order is the least of your problems with floating point. You can dump floating-point numbers in printable ASCII, or can convert them to some "canonical" floating-point format and dump that in some standard byte order; however, you have to choose the contents of the bytes in the series that you dump - you can't just dump the bits (unless the "canonical" form happens to be identical to the internal form on your particular machine). > My point here is not that you are wrong, but that the problem is > resolvable without vast trickery, and that there are some of us who are > doing it. I don't think Chris was saying it required "vast trickery" - I don't think *anybody* would say it required "vast trickery", especially not for integral data - just that it involved more than dumping out structures with some standard alignment.