Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mcnc!gatech!cuae2!ihnp4!chinet!steinmetz!davidsen From: davidsen@steinmetz.steinmetz.UUCP (william E Davidsen) Newsgroups: comp.arch Subject: Re: byte order: be reasonable - do it my way... Message-ID: <1116@steinmetz.steinmetz.UUCP> Date: Mon, 19-Jan-87 16:59:35 EST Article-I.D.: steinmet.1116 Posted: Mon Jan 19 16:59:35 1987 Date-Received: Wed, 21-Jan-87 22:24:11 EST References: <760@orcisi.UUCP> <112@lmi-angel.UUCP> <172@ames.UUCP> Reply-To: davidsen@kbsvax.UUCP (william E Davidsen) Organization: General Electric CRD, Schenectady, NY Lines: 113 Keywords: byte order, big-endian, little-endian In article <172@ames.UUCP> lamaster@pioneer.UUCP (Hugh LaMaster) writes: >The Motorola MC68000 series is big-endian in data formats, but is >inconsistent in instructions and addressing. The VAX machines are >distinctive in that they are not even consistent in data formats. >I am not sure about the Intel machines. Perhaps an Intel booster >could enlighten me. The Intel 80*86 series seems to be consistent in being little endian in the integer formats. The first (lowest address) byte is at the same address for all integer data formats, followed by the other bytes, if any, in increasing order. This is not true of text strings, which have the first byte at the lowest location, including BCD numbers, as I recall. > >As one of the instigators of the current discussion, I would like to >summarize some of what I have learned from subsequent arguments: >a) Some very very small machines may save a little bit of temporary >register space by being little endian (I looked up some hardware >diagrams and discovered that none of the more recent PDP-11's used >reduced size memory data registers, but some of the early small >machines might have...I don't know) It does allow some code to be simpler when processing the same data using several word lengths. This is in the area of making the code easier to write, rather than (necessarily) more efficient. >b) Some variable length memory to memory instructions could be >benefited by using little endian notation. Very much was is implied by (a). >c) Most people assume that there are other easy to prove properties >of "their" personal favorite ("If God had wanted us to use Hex, He >would have given us 16 fingers"). To date, I have not seen any such >argument that holds water. How many fingers do you have? Seriously, the notation should be a factor of the word length. Machines which have 9 bit bytes, such as the GE/Honeywell/Hitachi series, DEC 10/20, etc, are much easier to understand in octal. I don't see that this effects endian at all. >d) Some people believe that systems programmers don't have to read >dumps (Ha Ha Ha!). (The same people believe that Pascal HAS ALREADY >REPLACED Cobol and Fortran :-) :-) ) See previous comment. > >As I said before, those of us who work in multi-user environments >need to be able to move binary data files between machines. The >IEEE floating point standard was the declaration of independence; >now we are fighting the war. I wrote a little routine on the Cray to generate binary files for a VAX or PC (running a BASIC program yet) in about 2 minutes and 4 lines of code. The war isn't in integers, but float, where everyone uses what they like, and IEEE if they feel like it. The micros are MUCH better at staying with the standard. For what it's worth, it was far easier to output the integers LSB first on any machine, since machines with short word lengths may not have the bits needed to output MSB first. > Big manufacturers will never willingly >make it easier to move data between machines. Fortunately, small >manufacturers will. It is important that a standard for the mapping >of integers and floating point numbers onto bits, bytes, and words, >be developed. Before this effort can succeed, it may be necessary >for microprocessor and workstation manufacturers to agree. Why not >form an IEEE committee? What am I missing? FP and bytes I can see, but bits? > >One last point: As a systems programmer, I think it would be nice >if data formats, addressing, instruction formats, and notation were >all consistently big-endian or little-endian. That's one of the things I don't like about the 680?0 series, I would expect an integer with a value of 0x12345678 to be in memory as either 12345678, or 87654321, or 78563412 even, but not 34127856. I consider that "middle-endian". (yes I have att7300, Suns, etc, save you flames about how much I would like them) > As a user, all I really >care about are that the data formats are consistently one way or the >other on ALL machines. All the mainframes that I know of have >big-endian data formats; so does the (by far) most popular >microprocessor >for engineering and scientific use (MC68020). Does that mean that if it uses a National or Intel chip it isn't a workstation? > That gives big-endians >a big head start. But the (to be formed) committee may vote the other >way. As long as a standard is chosen, I don't care particularly. > >By the way, for those that missed it, the Danny Cohen article that is >often referred to is in the October '81 IEEE Computer magazine. > > Hugh LaMaster, m/s 233-9, UUCP: {seismo,hplabs}!nike!pioneer!lamaster > NASA Ames Research Center ARPA: lamaster@ames-pioneer.arpa > Moffett Field, CA 94035 ARPA: lamaster%pioneer@ames.arpa > Phone: (415)694-6117 ARPA: lamaster@ames.arc.nasa.gov > >"He understood the difference between results and excuses." > >("Any opinions expressed herein are solely the responsibility of the >author and do not represent the opinions of NASA or the U.S. Government") Anyone trying to categorize me as a lover of one endian over the other has not read my comments carefully. I hate trying to read 680?0 dumps, and fortunately don't do it often. -- bill davidsen sixhub \ ihnp4!seismo!rochester!steinmetz -> crdos1!davidsen chinet / ARPA: davidsen%crdos1.uucp@crd.ge.com (or davidsen@crd.ge.com)