Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!ames!pioneer!lamaster From: lamaster@pioneer.UUCP Newsgroups: comp.arch Subject: Re: byte order: be reasonable - do it my way... Message-ID: <172@ames.UUCP> Date: Fri, 16-Jan-87 14:38:37 EST Article-I.D.: ames.172 Posted: Fri Jan 16 14:38:37 1987 Date-Received: Sat, 17-Jan-87 04:46:34 EST References: <760@orcisi.UUCP> <112@lmi-angel.UUCP> Sender: usenet@ames.UUCP Reply-To: lamaster@pioneer.UUCP (Hugh LaMaster) Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 84 Keywords: byte order, big-endian, little-endian Summary: A standard for byte ordering is necessary In article <112@lmi-angel.UUCP> wsr@lmi-angel.UUCP (Wolfgang Rupprecht) writes: >In article <> mwm@cuuxb.UUCP (Marc W. Mengel) writes: >> The bit notation is strictly notational, and has no bearing on >> the operation of the cpu. One could go entirely through any >> MC68000 book and replace the bit-numbers appropriately throughout. > >Unfortunately thats not the case. Look at the BSET, BCLR, BTST (bit >set, clear and test) instructions. If you do a: >-- >Wolfgang Rupprecht {harvard|decvax!cca|mit-eddie}!lmi-angel!wsr There is a difference between a) the data formats b) addressing conventions c) instructions d) notation and documentation. Few machines are consistently big-endian or little endian on all four. The CDC Cyber 205 is one of the few machines that is consistently big-endian in ALL aspects. It is BIT addressable, byte addressable, 32-bit word addressable, and 64-bit word addressable, with completely mutually consistent addresses for each. And, a plus, it even shows the formats in the documentation numbered from the left. I believe that the National Semiconductor NS 32000 series MAY be a completely consistent little endian. If it is, then that too would be something of an accomplishment. (Remembering what Emerson said about consistency, it is still a valuable property of computer instruction sets). 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. 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) b) Some variable length memory to memory instructions could be benefited by using little endian notation. 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. 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 :-) :-) ) 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. 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? 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. 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). 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")