From: cs1cl@stoat.shef.ac.uk (C Lamb) Newsgroups: alt.folklore.computers Subject: big, little and middle endian-ness Date: 27 Dec 1998 23:29:20 GMT Organization: Sheffield University, UK Lines: 18 Message-ID: <766fsg$ktu$1@bignews.shef.ac.uk> Reply-To: cs1cl@stoat.shef.ac.uk NNTP-Posting-Host: stoat.shef.ac.uk X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!diablo.theplanet.net!news-lond.gip.net!news.gsl.net!gip.net!nntp.news.xara.net!xara.net!server5.netnews.ja.net!news.shef.ac.uk!stoat!cs1cl Not really a burning question that needs answering immediately, but I am way too young to know about the origins of these 3 types. I used to program on 6502 and if I wanted to represent a 32 bit number I would do it so: num=0x12345678 at address 00 value 0x12 at address 01 value 0x34 at address 02 value 0x56 at address 03 value 0x78 It seemed resonable to me to to have MSB at the left and LSB at the right. Obviously this wasn't so for others so, which was natural for you and what influences were operating on h/w designers to influence the final result as big/middle/little endian? regards C ###### From: john@ucc.gu.uwa.edu.au (John "West" McKenna) Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: 28 Dec 1998 12:14:02 +0800 Organization: The University of Western Australia Lines: 27 Message-ID: <7670ia$aou$1@mermaid.ucc.gu.uwa.edu.au> References: <766fsg$ktu$1@bignews.shef.ac.uk> NNTP-Posting-Host: mermaid.ucc.gu.uwa.edu.au X-Newsreader: NN version 6.5.0 CURRENT #118 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!news.maxwell.syr.edu!intgwpad.nntp.telstra.net!news1.optus.net.au!optus!news.uwa.edu.au!not-for-mail cs1cl@stoat.shef.ac.uk (C Lamb) writes: >It seemed resonable to me to to have MSB at the left and LSB at the >right. Obviously this wasn't so for others so, which was natural for >you and what influences were operating on h/w designers to influence >the final result as big/middle/little endian? In the case of the 6502, there was a very good reason for little-endian. Consider the instruction LDA $1234,X. Since X is only 8 bits wide, you only need to add the low byte of the address, and sometimes add the carry into the high byte. Since the 6502 is little-endian, they can load the low byte, do the addition while the high byte is being loaded, and then load from memory while they're adding the carry into the high byte. If there was no carry (which is true almost all of the time), you can stop there. If there was a carry, you need another load to get the correct byte. Saves a cycle most of the time. STA $1234,X is different, since you can't store to an address that might be right - you have to make sure it is. So STA always takes 5 cycles. LDA usually takes 4, 5 if you're unlucky. This method isn't entirely without side-effects, however. Some I/O devices will take action if you read from a location (like clearing IRQ flags), so unexpected things can happen. But your code has to be doing very strange things for this to happen by accident. John West ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: 28 Dec 1998 18:53:02 GMT Lines: 45 Message-ID: <768k2e$g14$1@roch.zetnet.co.uk> References: <766fsg$ktu$1@bignews.shef.ac.uk> NNTP-Posting-Host: man-170.dialup.zetnet.co.uk X-Trace: roch.zetnet.co.uk 914871182 16420 194.247.40.216 (28 Dec 1998 18:53:02 GMT) NNTP-Posting-Date: 28 Dec 1998 18:53:02 GMT X-Everything: Net-Tamer V 1.08X Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!newsfeed.uk.ibm.net!ibm.net!news-lond.gip.net!news.gsl.net!gip.net!btnet-peer!btnet-feed1!btnet!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1998-12-27 cs1cl@stoat.shef.ac.uk said: :Not really a burning question that needs answering immediately, but :I am way too young to know about the origins of these 3 types. I :used to program on 6502 and if I wanted to represent a 32 bit :number I would do it so: :num=0x12345678 :at address 00 value 0x12 :at address 01 value 0x34 :at address 02 value 0x56 :at address 03 value 0x78 Erm, maybe so, but in its addressing the 6502 was little-endian. (In some circumstances it didn't even bother incrementing the high word of a pointer for indirection, though that was a bug and got fixed.) Of course, since it lacked any concept of double-precision arithmetic you could use whichever endianness you preferred. The 6800 was big-endian, as were (I believe) all of the Motorola processors. :It seemed resonable to me to to have MSB at the left and LSB at the :right. Obviously this wasn't so for others so, which was natural for :you and what influences were operating on h/w designers to influence :the final result as big/middle/little endian? It seems reasonable to do it that way, only because Western humans are accustomed to reading numbers from left to right. Computers aren't so concerned with reading numbers as with adding them, and like us, they add from the LSB; if you use a little-endian architecture you can increment a pointer through your "digits". Useful for a microprogrammer. Useful for other programmers is the fact that if you fetch a byte from a memory address defined as a word, you get the LSB - which is almost certainly what you want. For that reason, I actually like little-endian architectures. The PDP-11 was a little peculiar in that it stored bytes in words big-endian, but if it was using higher precision, the words were arranged in a little endian format. So for your example: ptr = 0x56 ( 0x5678 ) ( 0x12345678 ) +1 = 0x78 +2 = 0x12 ( 0x1234 ) +3 = 0x34 (As usual this relies on my memory functioning.) -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing ###### From: lucvdv@null.net (Luc Van der Veken) Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: Mon, 28 Dec 1998 19:07:53 GMT Organization: . Lines: 48 Message-ID: <3687bd5d.896619@news.uunet.be> References: <766fsg$ktu$1@bignews.shef.ac.uk> <7670ia$aou$1@mermaid.ucc.gu.uwa.edu.au> NNTP-Posting-Host: pool02b-194-7-79-208.uunet.be Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.5/32.451 X-No-Archive: yes Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!rill.news.pipex.net!pipex!join.news.pipex.net!pipex!krypton.inbe.net!INbe.net!not-for-mail Also sprach john@ucc.gu.uwa.edu.au (John "West" McKenna) on 28 Dec 1998 12:14:02 +0800 to alt.folklore.computers: > cs1cl@stoat.shef.ac.uk (C Lamb) writes: >> Not really a burning question that needs answering immediately, but I Translation for AOL/webTV users: "I need 2 now very urgently..." OK, I'll leave out 1 specific AOL user. > > big/middle/little endian? > > In the case of the 6502, there was a very good reason for little-endian. > Consider the instruction LDA $1234,X. Since X is only 8 bits wide, you > If there was a carry, you need another load to get the correct byte. Saves > a cycle most of the time. That's one reason - there are more. Take for example an N-[byte|word|whatever] addition routine, that takes N and 2 pointers to the values as arguments. Try to write it for little-, and for big-endian machines, and compare the code length (and execution time). It can also be seen as a question of alignment: if you add numbers on paper, you right-align them (i.e. alignment on the least significant digit), and then add the digits from right to left. For a computer it's more efficient to left-align them in memory, but write them down backwards (i.e. least [base 256] digit first, = aligned on the least significant digit), and add them from left to right. Or: try to add a 16-bit to a 32-bit value in both systems, and find out which one results in the smallest and fastest code (assuming speed & space are crucial, so you don't want to convert the 16-bit to a 32-bit value first). This isn't purely hypothetical: IIRC, it was on the TRS-80 that I first noticed that a C compiler (Aztec?) used different addition methods for long+long and int+long, instead of first converting the int to a long and then doing long+long. BTW, I always mix up whether the 'end' is the first byte or the last in these discussions - that's why you don't find any reference to that in my post. ###### From: bayko@aristotle.cs.uregina.ca (John Bayko) Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: 28 Dec 1998 19:28:47 GMT Organization: University of Regina, Dept. of Computer Science Lines: 22 Message-ID: <768m5f$stk$1@sue.cc.uregina.ca> References: <766fsg$ktu$1@bignews.shef.ac.uk> NNTP-Posting-Host: aristotle.cs.uregina.ca Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!199.170.121.3!falcon.america.net!news.pagesat.net!decwrl!tribune.usask.ca!news.uregina.ca!not-for-mail In article , William Hamblen wrote: >C Lamb (cs1cl@stoat.shef.ac.uk) wrote: > >: It seemed resonable to me to to have MSB at the left and LSB at the >: right. Obviously this wasn't so for others so, which was natural for >: you and what influences were operating on h/w designers to influence >: the final result as big/middle/little endian? > >Oh, No, Endian Wars! The only correct format is centre-endian, where the most significant bit is in the exact centre, and the rest are arranged in a spiral pattern outward. This allows you to discard the sign bit - positive numbers spiral clockwise, negative ones spiral counterclockwise (there is only one zero, a single 0 bit in the centre, with no spiral). -- John Bayko (Tau). bayko@cs.uregina.ca http://www.cs.uregina.ca/~bayko ###### From: "Donald Tees" Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: Tue, 29 Dec 1998 00:47:37 -0500 Organization: IGS - Information Gateway Services Lines: 36 Message-ID: <769psk$784$1@news.igs.net> References: <766fsg$ktu$1@bignews.shef.ac.uk> <768m5f$stk$1@sue.cc.uregina.ca> NNTP-Posting-Host: ttye16.kw.igs.net X-Trace: news.igs.net 914909908 7428 206.248.37.150 (29 Dec 1998 05:38:28 GMT) X-Complaints-To: abuse@igs.net NNTP-Posting-Date: 29 Dec 1998 05:38:28 GMT X-Newsreader: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!130.185.14.36!torn!nntp.igs.net!news.igs.net!not-for-mail The real problem with the middle-endian approach is the shift instructions. Not only do you need a shift left and a shift right, but you also need a shift inwards and a shift outwards. Cpu's with that sort of built in shiftiness tend to be problematic on overflow. The shift inwards, of course, is the biggest problem. You can get overflow left, overflow right, and overflow both. Rotate instructions work out rather better, though they can result in the programmer going cross-eyed. John Bayko wrote in message <768m5f$stk$1@sue.cc.uregina.ca>... >In article , > William Hamblen wrote: >>C Lamb (cs1cl@stoat.shef.ac.uk) wrote: >> >>: It seemed resonable to me to to have MSB at the left and LSB at the >>: right. Obviously this wasn't so for others so, which was natural for >>: you and what influences were operating on h/w designers to influence >>: the final result as big/middle/little endian? >> >>Oh, No, Endian Wars! > > The only correct format is centre-endian, where the most >significant bit is in the exact centre, and the rest are arranged in a >spiral pattern outward. This allows you to discard the sign bit - >positive numbers spiral clockwise, negative ones spiral >counterclockwise (there is only one zero, a single 0 bit in the >centre, with no spiral). > >-- >John Bayko (Tau). >bayko@cs.uregina.ca >http://www.cs.uregina.ca/~bayko ###### Message-ID: <36885D3B.48972E6B@flash.net> From: Richard Lamb Reply-To: lamb01@flash.net Organization: Earth X-Sender: "Richard Lamb" (Unverified) X-Mailer: Mozilla 4.04 [en]C-FLASHNET (Win95; I) MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness References: <766fsg$ktu$1@bignews.shef.ac.uk> <768m5f$stk$1@sue.cc.uregina.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 30 Date: Tue, 29 Dec 1998 04:32:55 GMT NNTP-Posting-Host: 209.30.152.21 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 914905975 209.30.152.21 (Mon, 28 Dec 1998 22:32:55 CDT) NNTP-Posting-Date: Mon, 28 Dec 1998 22:32:55 CDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!news.maxwell.syr.edu!nntp.flash.net!news.flash.net!not-for-mail JOHN! Shame on you. Intel is now trying to implement that BS on the next Pentium! John Bayko wrote: > > In article , > William Hamblen wrote: > >C Lamb (cs1cl@stoat.shef.ac.uk) wrote: > > > >: It seemed resonable to me to to have MSB at the left and LSB at the > >: right. Obviously this wasn't so for others so, which was natural for > >: you and what influences were operating on h/w designers to influence > >: the final result as big/middle/little endian? > > > >Oh, No, Endian Wars! > > The only correct format is centre-endian, where the most > significant bit is in the exact centre, and the rest are arranged in a > spiral pattern outward. This allows you to discard the sign bit - > positive numbers spiral clockwise, negative ones spiral > counterclockwise (there is only one zero, a single 0 bit in the > centre, with no spiral). > > -- > John Bayko (Tau). > bayko@cs.uregina.ca > http://www.cs.uregina.ca/~bayko ###### From: Robert Billing Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: Tue, 29 Dec 1998 17:40:10 +0000 Organization: Tanglewood Message-ID: <368913FA.284DF77D@tnglwood.demon.co.uk> References: <766fsg$ktu$1@bignews.shef.ac.uk> <768k2e$g14$1@roch.zetnet.co.uk> NNTP-Posting-Host: localhost.demon.co.uk X-NNTP-Posting-Host: tnglwood.demon.co.uk:158.152.132.30 X-Trace: news.demon.co.uk 914953896 nnrp-03:9455 NO-IDENT tnglwood.demon.co.uk:158.152.132.30 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.31 i586) Lines: 38 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!uninett.no!news-feed.inet.tele.dk!bofh.vszbr.cz!dispose.news.demon.net!demon!news.demon.co.uk!demon!tnglwood.demon.co.uk!not-for-mail lisard@zetnet.co.uk wrote: > The PDP-11 was a little peculiar in that it stored bytes in words > big-endian, but if it was using higher precision, the words were > arranged in a little endian format. So for your example: > ptr = 0x56 ( 0x5678 ) ( 0x12345678 ) > +1 = 0x78 > +2 = 0x12 ( 0x1234 ) > +3 = 0x34 Not Quite. The LSB of the first word is at address 0 and so on. However there is something about this in Vol2 of Knuth IIRC. It's an oddity of the way we write numbers that the direction in which we write the digits is opposite to the direction in which we propagate the carries, a blunder which no previous civilisation has made (there are well documented historical reasons for the blunder). Because of this there is a tension between writing MSB first, so that it looks like the way we always write numbers, and LSB first, so that carries propagate in the direction of increasing address. A side effect of this is that on a little endian machine long X ; short * Y ; X = 3 ; Y = (short *) &X ; printf ( "%d\n", *Y ) ; will print 3 and on a big-endian machine it will print 0. This sometimes can produce weird results when porting between different processors. -- I am Robert Billing, Christian, inventor, traveller, cook and animal lover, I live near 0:46W 51:22N. http://www.tnglwood.demon.co.uk/ "Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock phasers on the Heffalump, Piglet, meet me in transporter room three" ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: 29 Dec 1998 21:34:51 +0100 Organization: My own Private Self Lines: 113 Sender: neil@chonsp.franklin.ch Message-ID: References: <766fsg$ktu$1@bignews.shef.ac.uk> <768k2e$g14$1@roch.zetnet.co.uk> X-Newsreader: Gnus v5.3/Emacs 19.34 lisard@zetnet.co.uk writes: > > On 1998-12-27 cs1cl@stoat.shef.ac.uk said: > :used to program on 6502 and if I wanted to represent a 32 bit > :number I would do it so: > :num=0x12345678 > :at address 00 value 0x12 > :at address 01 value 0x34 > :at address 02 value 0x56 > :at address 03 value 0x78 Nope. The 6502 allways wants the least significant byte first. A snippet direct from the Commodore C64 (6502) Basic ROM listing (from the keyboard drivers interrupt handler): EB71 BD 7A EB LDA $EB7A,X EB74 85 F6 STA $F6 EB76 4C E0 EA JMP $EAE0 EB79 here comes the key code to ASCII (o.k. PETSCII) table > Erm, maybe so, but in its addressing the 6502 was little-endian. Yes. Both little endian byte ordering (see above) and bit ordering. > some circumstances it didn't even bother incrementing the high word of a > pointer for indirection Exactly one instance, the jump indirect instruction, JMP ($xxyy), 6C yy xx. This fetches the 3 bytes of instruction code normally, then it fetches the 2 bytes xxyy points to (aabb). Doing this it fetches bb and then increments only yy and forgets to carry over to xx. So for the special case of 6C FF xx you get aa from 255 lower, not 1 higher. > though that was a bug and got fixed.) AFAIK that was never corrected (that would make the corrected processors incompatible with software that knows about this "feature"). Note that this is documented behaviour (in the official MOS Technology processor manual). But what klutz tries to missalignedly place an 16 bit pointer in xxFF and (xx+1)(00) anyway? :-) (Yes, I know its 8 bit RAM). > course, since it lacked any concept of double-precision arithmetic you > could use whichever endianness you preferred. Erm. 16 bit addresses are double precision for an 8 bit processor :-). And the 6502 has explicit little endian byte ordereing wired into it becuase of this. As for bit endianness, the hardware has no idea of this, but the docu uses little endian. On the Z80 (and 8080, and 80x86) it is the same (both bits and bytes little endian), but both bytes and bits are wired into hardware (bytes into all 16 bit addresses auch as LD HL, bits into all BIT/SET/RES instructions). > The 6800 was big-endian, > as were (I believe) all of the Motorola processors. AFAIK the Motorolas use an mixage of big endian byte ordering and little endian bit ordering! At least the 6809 definitely does. Bytes are big endian, as wired into the chip. A snippet from the Dragon 32 (6809) Basic ROM listing (same piece of code): BC7D 8E BC 84 LDX #$BC84 BC80 A6 86 LDA A,X BC82 20 E4 BRA $BC68 BC84 here comes the key code to ASCII table But bits are little endian (documentation only, nothing in hardware) as in the official Motorola processor datasheet description of the ASL/ASR instructions. On the 680x0 the bits are documented little endian, but the instructions use both little endian (single bit manipulation within an byte, there since the 68000) and big endian (bitfield manipulation in an long word, only added later)! > :It seemed resonable to me to to have MSB at the left and LSB at the > :right. Obviously this wasn't so for others so, which was natural for > :you and what influences were operating on h/w designers to influence > :the final result as big/middle/little endian? As I grew up on 8 bit microprocessors (where little endian is the norm) I regard this as logical. Both for bytes (carry) and for bits (bit x has value of 2^x). OTOH the big iron guys seem to all have bits and bytes big endian (at least all PDPs before the 11), so they will regard that as more logical. > concerned with reading numbers as with adding them, and like us, they > add from the LSB; if you use a little-endian architecture you can > increment a pointer through your "digits". Useful for a > microprogrammer. At least if faced with double precision arithmetic, as in an 6502 or Z80 doing 16 bit address calculations. The 6809 pays dearly for being big endian, LDA $xx,U needs 5 cycles, LDA $xxxx,U needs full 8 cycles. Most likely why the Dragon never uses 16bit+Register addressing. -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ Programming: when you stop hammering around on the computer as if it were a piece of dumb matter and instead tell it what to do for you ###### From: hnsngr@sirius.com (Ron Hunsinger) Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: Tue, 29 Dec 1998 15:13:34 -0800 Organization: ErsteSoft Lines: 80 Message-ID: References: <766fsg$ktu$1@bignews.shef.ac.uk> <7670ia$aou$1@mermaid.ucc.gu.uwa.edu.au> <3687bd5d.896619@news.uunet.be> NNTP-Posting-Host: ppp-asok07--131.sirius.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: Yet Another NewsWatcher 2.3.1 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.berkeley.edu!news2.best.com!news1.best.com!newshub.sirius.com!newsfiler.sirius.com!hnsngr In article <3687bd5d.896619@news.uunet.be>, lucvdv@null.net (Luc Van der Veken) wrote: > Take for example an N-[byte|word|whatever] addition routine, that > takes N and 2 pointers to the values as arguments. > Try to write it for little-, and for big-endian machines, and > compare the code length (and execution time). You're making some assumptions here. For one, you're assuming that the address of an integer is the address of its leftmost digit (that is, the digit at the lowest address). The problem you describe only manifests itself when the address of the integer is the address of the MSB (whichever side that's on). For example, the IBM 1620 was big-endian, but integers were addressed from the LSB (highest address) end. The addition algorithm worked down from there through lower addresses. And that suggests a more general way to handle big-endian even if addressing the MSB. If you know the length ahead of time, you only need to add that to the address you're given to get the LSB address (plus one), and use the intuitive algorithm from there. As long as you know the operand sizes going in, there's no big performance difference between big- and little-endian. (Of course, that wouldn't have worked on the 1620. The MSB was recognized by having a flag over it. You couldn't determine the length of a number ahead of time without scanning it, a digit at a time.) But doing arithmetic from the MSB end isn't all that hard, either. It's a little tricky, and seems awkward since it's not the way we learned to do it in school, but it's definitely doable. In fact, the Burroughs Medium Systems computers (now the Unisys V-series) does just that. It's a big-endian decimal architecture where everything (strings, integers, and instructions) is addressed from the MSB (low address). Operands are all variable length, with the lengths (1 to 100) being specified in the instruction itself. As it adds numbers, it postpones storing any digit of the result until it learns if there will be a carry into it. To do that, it needs only two internal registers. One holds the last non-9 result digit, assuming no carry, and the other counts the number of 9s following it, still assuming no carry. Once you detect a pair of summand digits whose sum is not 9, you know what to do with everything to the left. If you have a carry, store the saved non-9 digit plus one, then store as many zeroes as you've counted nines. Otherwise, store the saved non-9 digit as is, followed by the indicated number of nines. The virtue of this is that you can detect overflow before modifying the result. That was very important for the Medium Systems computers, whose architecture had a frightening level of compatibility with COBOL. In COBOL, if you say: ADD A TO B ON OVERFLOW ...do something... . then, if there is an overflow, you are guaranteed by the language that B has not been modified. The way arithmetic worked on the Med.Sys. computers made that easy to implement. (If you don't say "ON OVERFLOW", the language allows the compiler to do anything it wants with overflow. In this case, the compiler followed the hardware's lead, and left B unchanged. This could surprise people coming from other platforms, who expected overflow to do modular arithmetic.) One thing that becomes apparent if you work a lot on big-endian computers is that numeric comparisons become much easier if you address numbers by their MSB. You can often tell which of two numbers is bigger without having to examine them completely. You only have to scan down to the first difference. This is the same way we compare strings, which are always addressed by their MSB, even on little-endian machines. (Of course, my previous comment that, if the length is known ahead of time, it's trivial to convert between the MSB and LSB addresses on any architecture, now applies in reverse.) Still, I like the idea that big-endian numbers are stored the same way as strings, and compared the same way. -Ron Hunsinger ###### From: jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: Tue, 29 Dec 1998 19:08:35 GMT Organization: Videotron Communications Ltd. Lines: 53 Message-ID: <36892587.8966456@news.prosurfr.com> References: <766fsg$ktu$1@bignews.shef.ac.uk> NNTP-Posting-Host: c9169-002.prosurfr.com X-Newsreader: Forte Free Agent 1.11/32.235 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!newsfeed.wirehub.nl!howland.erols.net!newsfeed.direct.ca!news.insinc.net!stimpy.cal.sfl.net!news.videotron.ab.ca!not-for-mail cs1cl@stoat.shef.ac.uk (C Lamb) wrote, in part: >Obviously this wasn't so for others so, which was natural for >you and what influences were operating on h/w designers to influence >the final result as big/middle/little endian? Certainly, it is natural for English speakers to expect to encounter the most significant part of a number first when proceeding through a computer's memory in the same direction as one does to go from the start to the end of a character string. Arabic is written from right to left, but numbers still have their most significant digit on the right, and so from that viewpoint, the "little-endian" convention of the 6502, the PDP-11, and the 8086 would seem natural. But that isn't the reason some computers were little-endian. Essentially, the little-endian convention started with inexpensive minicomputers. These computers had short word lengths, and often needed to do arithmetic on integers that were twice as long as the computer's word length. Since this was an add-on feature, an afterthought, instead of adding circuitry to the computer so that when fetching the doubleword at address n, word n+1 would be fetched first, then word n, since when doing addition one starts with the least significant part, and then carries, the designers of many minicomputers thought nothing of putting the most significant word after the least significant one. Then, along came the PDP-11, where it was thought to keep things consistent by reversing the order in which 8-bit characters were stored in a 16-bit word, and the "little-endian" option became fully fleshed out. Since early versions of Unix ran on the PDP-11, it was quite an influential computer. The IBM 360 was an example of a pure "big-endian" computer. Even the floating-point format used a hexadecimal exponent, making it possible to figure out the value of a floating-point number from a hex dump. Even the bits of a word were numbered from 0 to 31, bit 0 being the most significant. The 68000 and the TI 9900 were also big-endian. Part of this comes down to whether or not it's worth a little extra hardware or microcode to make the computer easier to program in assembly language. Bit numbering of data lines, in a microprocessor system where one might hook up a 12-bit ADC to a microprocessor with a 16-bit data bus, is one argument for another aspect of the little-endian convention; the units bit is always bit 1 if one numbers the bits starting with 1 from the least significant bit. John Savard http://www.freenet.edmonton.ab.ca/~jsavard/index.html ###### From: genew@vip.net (Gene Wirchenko) Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: Wed, 30 Dec 1998 00:06:01 GMT Organization: Posted via RemarQ, http://www.remarQ.com - Discussions start here! Lines: 23 Message-ID: <36894bf7.13419951@news.vip.net> References: <766fsg$ktu$1@bignews.shef.ac.uk> <36892587.8966456@news.prosurfr.com> Reply-To: genew@vip.net NNTP-Posting-Host: 204.209.212.66 X-Trace: 914976196 A01OARAUVD442CCD1C usenet80.supernews.com X-Complaints-To: newsabuse@remarQ.com X-Newsreader: Forte Free Agent 1.1/32.230 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news-fra1.dfn.de!news-was.dfn.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.direct.ca!remarQ73!supernews.com!remarQ69!not-for-mail jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote: [snip] >Bit numbering of data lines, in a microprocessor system where one >might hook up a 12-bit ADC to a microprocessor with a 16-bit data bus, >is one argument for another aspect of the little-endian convention; >the units bit is always bit 1 if one numbers the bits starting with 1 >from the least significant bit. IBM's standard (at least, what I encountered) was that the LSB was bit 0. This has the advantage, if dealing with integer arithmetic or logical operations, that the bit number is the same as the power of two that the bit is for. Sincerely, gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: 30 Dec 1998 04:01:26 GMT Message-ID: <76c8im$sat$2@roch.zetnet.co.uk> References: <368913FA.284DF77D@tnglwood.demon.co.uk> NNTP-Posting-Host: man-108.dialup.zetnet.co.uk X-Trace: roch.zetnet.co.uk 914990486 29021 194.247.40.138 (30 Dec 1998 04:01:26 GMT) NNTP-Posting-Date: 30 Dec 1998 04:01:26 GMT X-Everything: Net-Tamer V 1.08X Lines: 31 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!news-raspail.gip.net!news-lond.gip.net!news.gsl.net!gip.net!dispose.news.demon.net!demon!ayres.ftech.net!news.ftech.net!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1998-12-29 unclebob@tnglwood.demon.co.uk said: :lisard@zetnet.co.uk wrote: :> The PDP-11 was a little peculiar in that it stored bytes in words :> big-endian, but if it was using higher precision, the words were :> arranged in a little endian format. So for your example: :> ptr = 0x56 ( 0x5678 ) ( 0x12345678 ) :> +1 = 0x78 :> +2 = 0x12 ( 0x1234 ) :> +3 = 0x34 :Not Quite. The LSB of the first word is at address 0 and so on. Oh. Well, this was second-hand from a magazine (Computer Shopper, back when it was a good technical read), so fair enough. But surely something worked this way...? :A side effect of this is that on a little endian machine :long X ; :short * Y ; :X = 3 ; :Y = (short *) &X ; :printf ( "%d\n", *Y ) ; :will print 3 and on a big-endian machine it will print 0. This :sometimes can produce weird results when porting between different :processors. (Isn't that what I said?) -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: 30 Dec 1998 04:01:29 GMT Lines: 81 Message-ID: <76c8ip$sat$3@roch.zetnet.co.uk> References: NNTP-Posting-Host: man-108.dialup.zetnet.co.uk X-Trace: roch.zetnet.co.uk 914990489 29021 194.247.40.138 (30 Dec 1998 04:01:29 GMT) NNTP-Posting-Date: 30 Dec 1998 04:01:29 GMT X-Everything: Net-Tamer V 1.08X Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!news.maxwell.syr.edu!ayres.ftech.net!news.ftech.net!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1998-12-29 neil@franklin.ch.remove said: :lisard@zetnet.co.uk writes: :> On 1998-12-27 cs1cl@stoat.shef.ac.uk said: :> :used to program on 6502 and if I wanted to represent a 32 bit :> :number I would do it so: [big-endianly] :Nope. The 6502 allways wants the least significant byte first. He said that was the way *he* used to do it. Aside from the fact that you have to make the pointers walk the number backwards for multiple precision arithmetic, I doubt there's much in it. :> Erm, maybe so, but in its addressing the 6502 was little-endian. :Yes. Both little endian byte ordering (see above) and bit ordering. Usually bit ordering doesn't matter - usually being when you don't have bit or bitfield instructions. I've never used one in my life, so... :> some circumstances it didn't even bother incrementing the high :>word of a pointer for indirection :Exactly one instance, the jump indirect instruction, JMP ($xxyy), :6C yy xx. I forgot which. Thanks. :> though that was a bug and got fixed.) :AFAIK that was never corrected (that would make the corrected :processors incompatible with software that knows about this :"feature"). Didn't the 65C02 correct it, as well as adding all kinds of other useful instructions? I'm pretty sure the 65C802/816 did. :> course, since it lacked any concept of double-precision :> arithmetic you could use whichever endianness you preferred. :Erm. 16 bit addresses are double precision for an 8 bit processor ::-). OK, when you show me the single 6502 instruction to add two 16-bit quantities I'll believe you. Note the key word "arithmetic". A 6502 without double precision support at all would be, erm, a bit sad... :> The 6800 was big-endian, :> as were (I believe) all of the Motorola processors. :AFAIK the Motorolas use an mixage of big endian byte ordering and :little endian bit ordering! At least the 6809 definitely does. I thought the question of endianness primarily related to bytes...? :On the 680x0 the bits are documented little endian, but the :instructions use both little endian (single bit manipulation within :an byte, there since the 68000) and big endian (bitfield :manipulation in an long word, only added later)! I guess that counts as a "feature"... What of the 88x00 and PowerPC? Do they swap at will? :> concerned with reading numbers as with adding them, and like us, :> they add from the LSB; if you use a little-endian architecture :> you can increment a pointer through your "digits". Useful for a :> microprogrammer. :At least if faced with double precision arithmetic, as in an 6502 or :Z80 doing 16 bit address calculations. The 6809 pays dearly for :being big endian, LDA $xx,U needs 5 cycles, LDA $xxxx,U needs full :8 cycles. Most likely why the Dragon never uses 16bit+Register :addressing. Ouch! (Although since even 8 cycles would have been faster than the alternative, it's quite conceivable that they would just not have needed to use an offset bigger than 8 bits.) -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: 30 Dec 1998 04:01:31 GMT Message-ID: <76c8ir$sat$4@roch.zetnet.co.uk> References: <36892587.8966456@news.prosurfr.com> NNTP-Posting-Host: man-108.dialup.zetnet.co.uk X-Trace: roch.zetnet.co.uk 914990491 29021 194.247.40.138 (30 Dec 1998 04:01:31 GMT) NNTP-Posting-Date: 30 Dec 1998 04:01:31 GMT X-Everything: Net-Tamer V 1.08X Lines: 17 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!news-raspail.gip.net!news-lond.gip.net!news.gsl.net!gip.net!dispose.news.demon.net!demon!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1998-12-29 jsavard@tenMAPSONeerf.edmonton.ab.ca(JohnSavard) said: :The IBM 360 was an example of a pure "big-endian" computer. Even the :floating-point format used a hexadecimal exponent, making it :possible to figure out the value of a floating-point number from a :hex dump. Even the bits of a word were numbered from 0 to 31, bit 0 :being the most significant. The 68000 and the TI 9900 were also :big-endian. Part of this comes down to whether or not it's worth a :little extra hardware or microcode to make the computer easier to :program in assembly language. In my experience of debugging at the machine code level on an x86, you do get used to flipping the bytes yourself after reading (far) too many stack dumps... -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing ###### From: andrew@cucumber.demon.co.uk (Andrew Gabriel) Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: 30 Dec 1998 13:18:53 GMT Organization: home Message-ID: <76d97t$dq@cucumber.demon.co.uk> References: <766fsg$ktu$1@bignews.shef.ac.uk> <36892587.8966456@news.prosurfr.com> <36894bf7.13419951@news.vip.net> NNTP-Posting-Host: cucumber X-NNTP-Posting-Host: cucumber.demon.co.uk:158.152.58.86 X-Trace: news.demon.co.uk 915024206 nnrp-04:8420 NO-IDENT cucumber.demon.co.uk:158.152.58.86 X-Complaints-To: abuse@demon.net X-Newsreader: knews 0.9.6 Lines: 14 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!btnet-peer!btnet!dispose.news.demon.net!demon!news.demon.co.uk!demon!cucumber.demon.co.uk!usenet In article <36894bf7.13419951@news.vip.net>, genew@vip.net (Gene Wirchenko) writes: > > IBM's standard (at least, what I encountered) was that the LSB >was bit 0. I'm pretty sure the IBM 360 had MSB as bit 0. However, if I'm wrong, I'm sure someone will be along to correct me shortly... -- Andrew Gabriel Consultant Software Engineer ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: 30 Dec 1998 20:59:24 +0100 Organization: My own Private Self Lines: 101 Sender: neil@chonsp.franklin.ch Message-ID: References: <76c8ip$sat$3@roch.zetnet.co.uk> X-Newsreader: Gnus v5.3/Emacs 19.34 lisard@zetnet.co.uk writes: > > On 1998-12-29 neil@franklin.ch.remove said: > > :Yes. Both little endian byte ordering (see above) and bit ordering. > > Usually bit ordering doesn't matter - usually being when you don't have > bit or bitfield instructions. I've never used one in my life, so... But as soon as the processor has bit instructions (Z80, 80x8x, 680x0) then it does count. Even if one never uses them (I never did either). > :> though that was a bug and got fixed.) > > :AFAIK that was never corrected (that would make the corrected > :processors incompatible with software that knows about this > :"feature"). > > Didn't the 65C02 correct it, as well as adding all kinds of other useful > instructions? I'm pretty sure the 65C802/816 did. That is possible. I had left the 8 bit world by then (hello 80286). But being incompatible on 1/4 of newly added instructions (C0..FF?) sure makes this change harmless. > :> course, since it lacked any concept of double-precision > :> arithmetic you could use whichever endianness you preferred. > > :Erm. 16 bit addresses are double precision for an 8 bit processor > ::-). > > OK, when you show me the single 6502 instruction to add two 16-bit > quantities I'll believe you. Note the key word "arithmetic". Will adding an 16 bit and an unsigned extended 8 bit do? If so: STA $aabb,X adds an 16 bit (aabb) and an zero-extended 8 bit (00XX) to form the effective address to store A into. That _is_ known as address arithmetic :-). And it is in double precision. And it dictates arangement, making the 6502 hardwarily little endian. O.K. I am stretching it a bit. > A 6502 > without double precision support at all would be, erm, a bit sad... Not just support (the carry flag) but actual instruction using dual precision (at least as far as the address arithmetic part goes). > :> The 6800 was big-endian, > :> as were (I believe) all of the Motorola processors. > > :AFAIK the Motorolas use an mixage of big endian byte ordering and > :little endian bit ordering! At least the 6809 definitely does. > > I thought the question of endianness primarily related to bytes...? There are 2 separate endiennesses, bit and byte. Usually the same (big/little), which is why many do not recognize them to be 2 things. 680x0 makes the distinction neccessary. > :instructions use both little endian (single bit manipulation within > :an byte, there since the 68000) and big endian (bitfield > :manipulation in an long word, only added later)! > > I guess that counts as a "feature"... What of the 88x00 and PowerPC? Do > they swap at will? I have never looked at their instruction formats in that detail. I would assume that Motorola has learned its lesson before making the 88x00. And the PPC was defined by IBM anyway, so most likely full big endian. > :At least if faced with double precision arithmetic, as in an 6502 or > :Z80 doing 16 bit address calculations. The 6809 pays dearly for > :being big endian, LDA $xx,U needs 5 cycles, LDA $xxxx,U needs full > :8 cycles. Most likely why the Dragon never uses 16bit+Register > :addressing. > > Ouch! (Although since even 8 cycles would have been faster than the > alternative, it's quite conceivable that they would just not have needed > to use an offset bigger than 8 bits.) Well the code I was looking at, which required an 16 bit base with variable offset (analog to 6502 LDA $xxxx,X), does the alternative: it uses 2 instructions, LDU xxxx and then LDA A,U. -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ Programming: when you stop hammering around on the computer as if it were a piece of dumb matter and instead tell it what to do for you ###### Date: 30 Dec 98 13:59:48 -0800 From: "Charlie Gibbs" Subject: Re: big, little and middle endian-ness References: <76c8ip$sat$3@roch.zetnet.co.uk> Message-ID: <325.668T2433T8395522@sky.bus.com> Newsgroups: alt.folklore.computers Lines: 22 X-Newsreader: THOR 2.5a (Amiga;TCP/IP) NNTP-Posting-Host: news.skybus.com X-Trace: 30 Dec 1998 17:37:51 -0800, news.skybus.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.berkeley.edu!newsfeed1.earthlink.net!news-stk-1.sprintlink.net!news-backup-west.sprintlink.net!news.sprintlink.net!news.westel.com!news.skybus.com!204.244.247.114 Things are getting way too serious here... What's this? 8080 8086 8088 80186 80286 80386 80386SX 80486 80486SX Pentium Ten little-endians! (One little, two little, three little Intels...) -- cgibbs@sky.bus.com (Charlie Gibbs) Remove the first period after the "at" sign to reply. ###### From: cs1cl@stoat.shef.ac.uk (C Lamb) Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: 30 Dec 1998 21:51:45 GMT Organization: Sheffield University, UK Lines: 36 Message-ID: <76e79h$j29$1@bignews.shef.ac.uk> References: <76c8ip$sat$3@roch.zetnet.co.uk> Reply-To: cs1cl@stoat.shef.ac.uk NNTP-Posting-Host: stoat.shef.ac.uk X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!news.tele2.nl!newsfeed1.swip.net!swipnet!rill.news.pipex.net!pipex!server1.netnews.ja.net!server5.netnews.ja.net!news.shef.ac.uk!stoat!cs1cl lisard@zetnet.co.uk wrote: : Didn't the 65C02 correct it, as well as adding all kinds of other useful : instructions? I'm pretty sure the 65C802/816 did. I had a manual for the 6502/65C02 and among the extra instructions were a set of 8 BBS (branch on bit set) instructions : :> course, since it lacked any concept of double-precision : :> arithmetic you could use whichever endianness you preferred. : :Erm. 16 bit addresses are double precision for an 8 bit processor : ::-). : OK, when you show me the single 6502 instruction to add two 16-bit : quantities I'll believe you. Note the key word "arithmetic". A 6502 : without double precision support at all would be, erm, a bit sad... exactamundo, I was trying to beat the BBC micros own draw line algo so I needed 16 bit addition and I went on to produce 32bit add, mul, sub and the biggie, divide (I don't know why but I was very proud getting it all by shift and subtracts rather than repeated subs. Well, I was rather young at the time (~15yrs)) Oh, and I *never* beat the BBC micro for drawing lines. Which brings me onto the unusual method it had for addressing the screen in hi-res(2 colours), rather than a raster like display the first byte was 8 pixels @ topleft corner but the second byte represented the 8 pixels below it, the following 6 bytes below that, then the 9th byte represented the 9th to 16th pixels to the right of the 1st byte, a load of mini columns across the screen. Made text display really fast but addressing the screen in graphics a complete cow. regards C ###### From: turbid@my-dejanews.com Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: Thu, 31 Dec 1998 01:57:31 GMT Organization: Deja News - The Leader in Internet Discussion Lines: 44 Message-ID: <76elmb$o6q$1@nnrp1.dejanews.com> References: <76c8ip$sat$3@roch.zetnet.co.uk> <76e79h$j29$1@bignews.shef.ac.uk> NNTP-Posting-Host: 203.20.108.35 X-Article-Creation-Date: Thu Dec 31 01:57:31 1998 GMT X-Http-User-Agent: Mozilla/4.06 [en] (X11; I; Linux 2.0.34 i586) X-Http-Proxy: 1.0 quokka:3128 (Squid/2.1.PATCH2), 1.0 x9.dejanews.com:80 (Squid/1.1.22) for client 203.20.108.15, 203.20.108.35 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!204.238.120.130!news-feeds.jump.net!nntp2.dejanews.com!nnrp1.dejanews.com!not-for-mail > exactamundo, I was trying to beat the BBC micros own draw line algo > so I needed 16 bit addition and I went on to produce 32bit add, mul, you need 16 bit addition to do a line draw? What computer were you using? > Oh, and I *never* beat the BBC micro for drawing lines. Which brings > me onto the unusual method it had for addressing the screen in > hi-res(2 colours), rather than a raster like display the first > byte was 8 pixels @ topleft corner but the second byte represented the 8 > pixels below it, the following 6 bytes below that, then the 9th byte > represented the 9th to 16th pixels to the right of the 1st byte, > a load of mini columns across the screen. Made text display really > fast but addressing the screen in graphics a complete cow. Actually, this was a rather usual method for many computers, particularly those based on a 6845 or similar address and timing generator. The architecture made it easy to implement text mode by reading the character definition from an appropriate ROM or RAM. Graphics, which was less frequently used, was an added bonus. The beeb and (I believe) CGA and Hercules boards for peecees used 6845s and had this quaint graphics addressing. The Commodore 64 did too, for the same reasons, but using their own VIC II chip. And so did my first home-brew computer which used a 6845 ;-) Graphics addressing quirk aside, I really liked the 6845 as it was a simple yet very flexible design. You could put program the address generators and timers to set the screen to whatever size you liked and get rid of the "fixed border" that you got on personal computers of the day. It had an interlace mode for "bonus" resolution if you had the graphics memory. It had a "half-scan" mode where odd frames were offset by half a scan line to give a "smoother" look just like a tv, providing you had a reasonably persistent monitor. Raster interrupts were easy to implement with an external counter and (I think) it had an internal light pen counter. Of course, I'm romanticising somewhat ;-) Back in those days every cycle I could save coding graphics routines on my Commodore 64 counted and I hated that graphics addressing format... :-) -t. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ###### From: turbid@my-dejanews.com Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: Thu, 31 Dec 1998 04:02:03 GMT Organization: Deja News - The Leader in Internet Discussion Lines: 25 Message-ID: <76esvr$tni$1@nnrp1.dejanews.com> References: <76c8ip$sat$3@roch.zetnet.co.uk> <325.668T2433T8395522@sky.bus.com> NNTP-Posting-Host: 203.20.108.18 X-Article-Creation-Date: Thu Dec 31 04:02:03 1998 GMT X-Http-User-Agent: Mozilla/4.06 [en] (Win95; I) X-Http-Proxy: 1.0 x6.dejanews.com:80 (Squid/1.1.22) for client 203.20.108.18 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!howland.erols.net!news-peer1.sprintlink.net!news.sprintlink.net!newsfeed.berkeley.edu!nntp2.dejanews.com!nnrp1.dejanews.com!not-for-mail In article <325.668T2433T8395522@sky.bus.com>, "Charlie Gibbs" wrote: > Things are getting way too serious here... > > What's this? > > 8080 > 8086 > 8088 > 80186 > 80286 > 80386 > 80386SX > 80486 > 80486SX > Pentium > > Ten little-endians! ... and they're all junk :-) -t. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ###### From: Kin Hoong CHUNG Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: 1 Jan 1999 07:41:38 GMT Organization: University of New South Wales Lines: 36 Message-ID: <76hu7i$dla$1@mirv.unsw.edu.au> References: <76c8ip$sat$3@roch.zetnet.co.uk> NNTP-Posting-Host: alpha.maths.unsw.edu.au User-Agent: tin/pre-1.4-980618 (UNIX) (OSF1/V4.0 (alpha)) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!feeder.qis.net!sunqbc.risq.qc.ca!news.uow.edu.au!news.usyd.edu.au!unsw.edu.au!not-for-mail Neil Franklin wrote: : I have never looked at their instruction formats in that detail. I : would assume that Motorola has learned its lesson before making the : 88x00. And the PPC was defined by IBM anyway, so most likely full big : endian. The PPC (according to the Moto WWW site) is big-endian, with a little-endian option. It is also now both 64-bit and 32-bit, with segments available only in 32-bit mode (:-( if you like Multics). :> :At least if faced with double precision arithmetic, as in an 6502 or :> :Z80 doing 16 bit address calculations. The 6809 pays dearly for :> :being big endian, LDA $xx,U needs 5 cycles, LDA $xxxx,U needs full :> :8 cycles. Most likely why the Dragon never uses 16bit+Register :> :addressing. : Well the code I was looking at, which required an 16 bit base with : variable offset (analog to 6502 LDA $xxxx,X), does the alternative: : it uses 2 instructions, LDU xxxx and then LDA A,U. Well, the 6809 was not designed with speed as the primary concern, and it was certainly not designed with RISC principles. One often needed to look at the instruction timing to maximise the speed (for example CLR A is preferred to LDA #0). The most irritating part of it was the lack of registers... the number of times people perform TFR D,X to avoid an expensive register-memory operation is quite high. Still, it had its niceties, like a 6-cycle multiply (pity it only worked on 8-bits and used both the A and B registers) and position independent code (again with the irritating choice between a quick BRA +8-bit argument and the slower LBRA +16-bit argument for PC-relative branches). Cheers, Kin Hoong ###### From: newcomer@flounder.com (Joseph M. Newcomer) Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: Fri, 01 Jan 1999 22:03:34 GMT Organization: Pittsburgh OnLine, Inc. Lines: 69 Message-ID: <369a45ba.272132526@206.210.64.12> References: <766fsg$ktu$1@bignews.shef.ac.uk> <36892587.8966456@news.prosurfr.com> NNTP-Posting-Host: ppp6.s8.pgh.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.5/32.451 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!nntp.abs.net!newsfeed.fast.net!news.pgh.net!not-for-mail John von Neumann insisted that the only correct way to write numbers was to put the LSD on the left, going to the right to the MSD. For example, it made them easy to type because you didn't have to figure out how many spaces had to precede the number so that the LSDs all lined up. He not only asserted this, he actually wrote his numbers that way. This made it awkward because when he was lecturing he would often write numbers in his inverted order and confuse his audience. joe On Tue, 29 Dec 1998 19:08:35 GMT, jsavard@tenMAPSONeerf.edmonton.ab.ca (John Savard) wrote: >cs1cl@stoat.shef.ac.uk (C Lamb) wrote, in part: > >>Obviously this wasn't so for others so, which was natural for >>you and what influences were operating on h/w designers to influence >>the final result as big/middle/little endian? > >Certainly, it is natural for English speakers to expect to encounter >the most significant part of a number first when proceeding through a >computer's memory in the same direction as one does to go from the >start to the end of a character string. > >Arabic is written from right to left, but numbers still have their >most significant digit on the right, and so from that viewpoint, the >"little-endian" convention of the 6502, the PDP-11, and the 8086 would >seem natural. > >But that isn't the reason some computers were little-endian. > >Essentially, the little-endian convention started with inexpensive >minicomputers. These computers had short word lengths, and often >needed to do arithmetic on integers that were twice as long as the >computer's word length. > >Since this was an add-on feature, an afterthought, instead of adding >circuitry to the computer so that when fetching the doubleword at >address n, word n+1 would be fetched first, then word n, since when >doing addition one starts with the least significant part, and then >carries, the designers of many minicomputers thought nothing of >putting the most significant word after the least significant one. > >Then, along came the PDP-11, where it was thought to keep things >consistent by reversing the order in which 8-bit characters were >stored in a 16-bit word, and the "little-endian" option became fully >fleshed out. Since early versions of Unix ran on the PDP-11, it was >quite an influential computer. > >The IBM 360 was an example of a pure "big-endian" computer. Even the >floating-point format used a hexadecimal exponent, making it possible >to figure out the value of a floating-point number from a hex dump. >Even the bits of a word were numbered from 0 to 31, bit 0 being the >most significant. The 68000 and the TI 9900 were also big-endian. Part >of this comes down to whether or not it's worth a little extra >hardware or microcode to make the computer easier to program in >assembly language. > >Bit numbering of data lines, in a microprocessor system where one >might hook up a 12-bit ADC to a microprocessor with a 16-bit data bus, >is one argument for another aspect of the little-endian convention; >the units bit is always bit 1 if one numbers the bits starting with 1 >from the least significant bit. > >John Savard >http://www.freenet.edmonton.ab.ca/~jsavard/index.html Joseph M. Newcomer newcomer@flounder.com http://www3.pgh.net/~newcomer ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: big, little and middle endian-ness Date: 4 Jan 1999 03:18:01 GMT Message-ID: <76pbt9$d5o$1@roch.zetnet.co.uk> References: NNTP-Posting-Host: man-053.dialup.zetnet.co.uk X-Trace: roch.zetnet.co.uk 915419881 13496 194.247.41.66 (4 Jan 1999 03:18:01 GMT) NNTP-Posting-Date: 4 Jan 1999 03:18:01 GMT X-Everything: Net-Tamer V 1.08X Lines: 64 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!news-raspail.gip.net!news-lond.gip.net!news.gsl.net!gip.net!dispose.news.demon.net!demon!demeter.clara.net!news.clara.net!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1998-12-30 neil@franklin.ch.remove said: :> Usually bit ordering doesn't matter - usually being when you :> don't have bit or bitfield instructions. I've never used one in :> my life, so... :But as soon as the processor has bit instructions (Z80, 80x8x, :680x0) then it does count. Even if one never uses them (I never did :either). Surely not if one never uses them, it doesn't - unless someone else does and you're debugging it, but I was assuming this case came under "not one's own doing". I don't know or care which end of the x86 word is bit 0 and which is bit 7, precisely because I never use those instructions. (x > 2) :> Didn't the 65C02 correct it, as well as adding all kinds of other :>useful instructions? I'm pretty sure the 65C802/816 did. :That is possible. I had left the 8 bit world by then (hello 80286). :But being incompatible on 1/4 of newly added instructions (C0..FF?) :sure makes this change harmless. Depends whether the instructions were no-ops before; well-behaved 6502 programs wouldn't have used the undocumented instructions. That's the point of upward compatibility. And as you said, most programmers would not have used it as a feature, they just would have word aligned their pointers. :> OK, when you show me the single 6502 instruction to add two 16-bit :> quantities I'll believe you. Note the key word "arithmetic". :Will adding an 16 bit and an unsigned extended 8 bit do? If so: Explicitly not! ;> :STA $aabb,X adds an 16 bit (aabb) and an zero-extended 8 bit (00XX) :to form the effective address to store A into. That _is_ known as :address arithmetic :-). And it is in double precision. And it It shouldn't be; it's indexing. I'd believe it to be address arithmetic if you had an LEA instruction... And it's mixed precision, so there. :P :dictates arangement, making the 6502 hardwarily little endian. Agreed. (Though it wouldn't surprise me to find somewhere where addresses and data were kept in a different endian-ness.) :O.K. I am stretching it a bit. :> Ouch! (Although since even 8 cycles would have been faster than :> the alternative, it's quite conceivable that they would just not :> have needed to use an offset bigger than 8 bits.) :Well the code I was looking at, which required an 16 bit base with :variable offset (analog to 6502 LDA $xxxx,X), does the alternative: :it uses 2 instructions, LDU xxxx and then LDA A,U. Strange. What's the cycle count of that? (They may just not have known, or had a compiler that didn't know, about the longer variant.) -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing