🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #11476

Re: Scalar vs Superscalar

#11476
From: Martin Golding
Date: Fri, 10 May 1991 18:11
48 lines
2560 bytes
In comp.arch you write: 
>P.S.  could somebody email me a definition of "little endian" vs.
>"big endian" ?  

(I tried email, and got bounced, and this was too much fun just to waste.)

Careful, you're into religious mysteries here. The terms refer to the
(holy) significance of bytes within larger structures (eg, words).
If you have the address of say, a 32 bit word (addressed byte plus
the bytes at the next three incrementing addresses) little endian 
means that the addressed byte is the least significant, big endian 
means the addressed byte is the most significant. Big endian is also 
referred to as "byte normal", and little endian "byte perverse" ;-)

There's a subtle trick, that Motorola missed when it designed the 68000,
that Real Computers have their bytes and bits in the _same_ order. The
68020 uses two different bit numbering schemes, byte perverse for the 
(68000 compatible) simple bit instructions and byte normal for the 
(68020 only) bitfield instructions, that may span bytes and words.

>Are RS6000's, Suns and Macintoshes "big endian"?

yes. Also HP's Precision Architecture.

>What about i860?  

I'm not certain, but Intel does cling to their heretical ways with
fanatical fervor, so the i860 is almost certainly byte perverse.

>Is it a property of the chip, or of the OS?

It is usually a property of the chip, BUT it can be a property of the
chip that it is a property of the OS. In particular, the (Advanced Micro
Devices) 29000 and the (Motorola) 88000 can be set to use either.
The Motorola version of the Unix system on the 88k is byte normal.

If you're interested in long and fiery discussions full of sound and
fury signifying nothing, I can present the arguments for both the
nonsense and correct sides of the question.

BTW to save the valuable time of the people who post useful things here
please email flames (?and I'll post a summary??)


Martin Golding    | sync, sync, sync, sank ... sunk:
Dod #0236         |  He who steals my code steals trash.
A poor old decrepit Pick programmer. Sympathize at:
{mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp
Technical Details
Message-ID: <729@adpplz.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!mintaka!ogicse!cvedc!mcspdx!adpplz!martin
References: <1991May6.152803.5886@midway.uchicago.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!mintaka!ogicse!cvedc!mcspdx!adpplz!martin
From: martin@adpplz.UUCP (Martin Golding)
Newsgroups: comp.arch
Subject: Re: Scalar vs Superscalar
Message-ID: <729@adpplz.UUCP>
Date: 10 May 91 18:11:35 GMT
References: <1991May6.152803.5886@midway.uchicago.edu>
Organization: ADP Dealer Services R&D, Portland, OR
Lines: 48