🚀 go-pugleaf

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")