alan@pdn.nm.paradyne.com (Alan Lovejoy) (01/26/89)
In article <1371@X.UUCP> john@frog.UUCP (John Woods) writes: >Ah, but consider the German for 1988: neunzehn hundert acht und achtzig >(nine-and-ten hundred eight and eighty). Middle-endian. AHA! Germans >are PDP-11s! Nein! Die PDP-11en sind Deutchen! (No! PDP-11s are German!) 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.W -- store little endian word LLE.L -- load little endian long SLE.L -- store little endian long LBE.W -- load big endian word SBE.W -- store big endian word LBE.L -- load big endian long SBE.L -- store big endian long In this scheme, applications would be responsible for keeping themselves in sync with the endianness of their data, just as they already must keep themselves in sync with the byte-length of their data. Programmers could choose the endianness of data as they saw fit--based either on convenience or performance considerations. Even if LBE.L takes more cycles than LLE.L, it might still be used advantageously in a string comparison algorithm--or a 68k emulator. If the Rx000 used this approach, then DEC would still have been free to write little-endian code (and code generators), but other peoples' big-endian code would still run on DEC machines--as long as such code brings its big-endian data sets along with it. -- Alan Lovejoy; alan@pdn; 813-530-2211; ATT-Paradyne: 8550 Ulmerton, Largo, FL. Disclaimer: I do not speak for ATT-Paradyne. They do not speak for me. ___________ This Month's Slogan: Reach out and BUY someone (tm). ___________ Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (01/26/89)
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
hascall@atanasoff.cs.iastate.edu (John Hascall) (01/26/89)
(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.W -- store little endian word >LLE.L -- load little endian long >SLE.L -- store little endian long >LBE.W -- load big endian word >SBE.W -- store big endian word >LBE.L -- load big endian long >SBE.L -- store big endian long [...example of using such a feature omitted...] Here it is again, adding instructions to a RISC machine... won't be long before we have a RISC machine with more instructions than a VAX.... :-) John Hascall ISU Comp Center Ames, IA
rrt@halley.UUCP (Robert Teisberg) (01/27/89)
In article <5462@pdn.nm.paradyne.com> alan@pdn.nm.paradyne.com (0000-Alan Lovejoy) writes: >It would be better to provide load and store operations that are >specifically big or little endian: > >LLE.W -- load little endian word >SLE.W -- store little endian word ... etc. ... The Datapoint 6600 (definitely not a RISC -- think of an 8008 grown in an entirely different fashion from the one Intel chose) had something along these lines. It had a special register which it used to relocate one page of memory cells which were then accessible with an 8-bit offset. The instructions used to reference this page included: DPL double paged load DPS double pages store DPLR double paged load reversed DPSR double paged store reversed Since I was writing SNA software for this beast, I frequently wished that Datapoint's SIL had included a way to declare a field big-endian so the compiler would know it could generate these instructions directly. Ah, memories! >Alan Lovejoy; alan@pdn; 813-530-2211; ATT-Paradyne: 8550 Ulmerton, Largo, FL. >Disclaimer: I do not speak for ATT-Paradyne. They do not speak for me. >___________ This Month's Slogan: Reach out and BUY someone (tm). ___________ >Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET. -- Bob Teisberg @ Tandem Computers, Inc. | ...!rutgers!cs.utexas.edu!halley!rrt 14231 Tandem Blvd. | Austin, Texas 78728 | (512) 244-8119
bcase@cup.portal.com (Brian bcase Case) (01/28/89)
> Here it is again, adding instructions to a RISC machine... won't > be long before we have a RISC machine with more instructions > than a VAX.... :-) And again... Sigh, RISC doesn't mean a small number of instructions. RISC means simple instructions that, for one thing, all fit in the same uniform pipeline. The number of instructions is a factor, there's no reason to have more than are really necessary, but if the instructions are of the right nature, simple to decode and uniform in semantics, you can have a gazillion of them. Thus, the emphasis is on instruction *encodings* and *semantics*, NOT THE QUANTITY. So, adding the loads and stores in both little and big endian varieties is not necessarily an anit-RISC idea. In fact, since they add to the richness of the instruction set with out requiring new hardware (the little/big endian hardware is already there in some machines!), they are very good candidates for new instructions. What about encoding? One extra bit will do, and this is not hard to decode, it should not increase decode time. What about use? Yes the code generators can be trained to deal with this. But what about passing pointers to the operating system? I guess we would need two versions of many (most?) system calls.... What else? If, considering all the software implications (which I have not had time to do), this works, I wish we had implemented it in the 29K.
mclauss@enlog.Wichita.NCR.COM (Mark Clauss) (01/30/89)
In article <5462@pdn.nm.paradyne.com> alan@pdn.nm.paradyne.com (0000-Alan Lovejoy) writes: >It would be better to provide load and store operations that are >specifically big or little endian: > >LLE.W -- load little endian word >...... This would require a large field in the coding of these instructions. Are these bits available for use? Maybe this is a real good idea when we go to 64 bit instructions. There are other ways to do this (ie. an "endian" bit in a configuration register) but they aren't very RISCY. Now that I think of it 64 bit instructions aren't very RISCY either. -- Mark Clauss Hardware Engineering, NCR Wichita <Mark.Clauss@Wichita.NCR.COM> NCR:654-8120 <{uunet}!ncrlnk! (316)636-8120 <{ece-csc,hubcap,gould,rtech}!ncrcae!ncrwic!mark.clauss> <{sdcsvax,cbatt,dcdwest,nosc.ARPA,ihnp4}!ncr-sd!
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (02/02/89)
In article <86957@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes: | 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.... This is really not in keeping with (my) concept of RISC. Rather than many new instructions, one instruction with an argument would allow setting the endedness of the load/store operations. SEL ; Set endian little MOV R14,XX ; Start compare... Please note: I am not saying that this is a good thing to do, just that it would seem easier to have one instruct control the endedness. Sure makes a neat way to flip the bits in a word, ie: SEL ; little endian MOV R14,XX ; Load xx into R14 SEB ; big endian MOV XX,R14 ; store, reversed bits Hummm... maybe this is a good idea, after all. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me