Xref: utzoo comp.arch:8017 comp.misc:4812 comp.lang.misc:2616 comp.protocols.misc:472
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!chiba!khb
From: khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering)
Newsgroups: comp.arch,comp.misc,comp.lang.misc,comp.protocols.misc
Subject: Re: Unification of big and little endian architectures.
Keywords: dump little-endian strings
Message-ID: <86957@sun.uucp>
Date: 26 Jan 89 01:46:24 GMT
References: <170@microsoft.UUCP> <4008@hubcap.UUCP> <482@babbage.acc.virginia.edu> <7193@csli.STANFORD.EDU> <1371@X.UUCP> <5462@pdn.nm.paradyne.com>
Sender: news@sun.uucp
Reply-To: khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering)
Organization: Sun Microsystems, Mountain View
Lines: 29

In article <5462@pdn.nm.paradyne.com> alan@pdn.nm.paradyne.com (0000-Alan Lovejoy) writes:
>
>It seems that several of the ccurrent RISC architectures provide for 
>either big or little endian operation (Rx000, 88k, 29k, ?).  They do
>this buy providing a global operating status that can be set by the
>user to either big or little endian.
>
>It would be better to provide load and store operations that are
>specifically big or little endian:
>
>LLE.W -- load little endian word
>SLE.L -- store little endian long
>LBE.W -- load big endian word
    and more

Perhaps I am missing something...but it appears to me that this
increases the size of the instruction set (and therefore gate size),
so we will have a more complex machine, less space for registers/other
goodies, and what we gain seems to be rather a small win.... perhaps
you could provide some statistics demonstrating how this will improve
performance. (the compatibility win is obvious, but unclear that is
sufficint to gunk up an otherwise clean design).





Keith H. Bierman
It's Not My Fault ---- I Voted for Bill & Opus