The 4004 may have used serial adders, but the 8080 used parallel. Most of the PDPs used parallel also. In fact I am sure that all the PDPs built from the late 60s on used parallel adders. Back in the 60s most systems used serial adders since they used transistors. It takes a lot of transistors to make a serial adder, so it was after ICs were invented that they started using parallel adders.
I suspect that little endian was an accident. It is easy to design little endian for a serial adder as John pointed out. You can't tell the difference on a word addressed machine since you need to be able to see the same data with different views to tell how it is stored. Oddly enough a left shift is defined as shifting to the most significant bit in both little endian and big endian systems, which is one reason I think that little endian was an accident. -----Original Message----- From: John Alvord [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 10:34 AM To: [EMAIL PROTECTED] Subject: Re: big and little endian The way I understand it, the little endian scheme is optimized for mini/micro hardware of the middle 1970s (4004. 8080, PDP etc). Those had tiny memory caches. When adding numbers together, you start with the least significant part of the number, store the result, use the overflow indicator with the next sigificant part. Think of how manual decimal addition is performed. Starting at the least significant part is simplest. Having the least siginifcant part as the lowest memory address is efficient for cases with minimal cache buffer... the fetch on one section will bring in the next part. In the big-endian case, fetching the higher address would not pull in the prior address. By now, this is ancient history. But the exegies of binary compatibility have kept the memory model congruent. And truthfully it doesn't make any real difference these days. john alvord On Wed, 6 Aug 2003 09:44:45 -0700, "Wolfe, Gordon W" <[EMAIL PROTECTED]> wrote: >Ah, yes, but when you look at a NUMBER, whether it be base-2, base-10 or base-16, you tend to look at it with the MOST significant digit on the LEFT. It depends entirely upon whether you're looking at it as a NUMBER or as the contents of a STRING OF ADDRESSES. > >"Always do right. This will gratify some people and confound the rest." - Mark Twain >Gordon W. Wolfe, Ph.D, (425) 865 - 5940 >VM Technical Services, the Boeing Company > > >-----Original Message----- >From: Ward, Garry [mailto:[EMAIL PROTECTED] >Sent: Wednesday, August 06, 2003 9:36 AM >To: [EMAIL PROTECTED] >Subject: Re: big and little endian > > >Perception of end. > >visually, most folks look at low addresses in storage as on the left >hand and ascending to the right. Big Endian puts the most significant >digits on the left and hence the lower address, puts the big end of the >number at the lower end of storage. > >There is also something about which end of a register the hardware >starts it's arithmetic operations on, whether it operations on a right >to left pattern for bit level operations or on a left to right pattern >for bit level operations. > > >-----Original Message----- >From: Bernd Oppolzer [mailto:[EMAIL PROTECTED] >Sent: Wednesday, August 06, 2003 12:23 PM >To: [EMAIL PROTECTED] >Subject: Re: big and little endian > > >What I never understood about this: how can big ENDian be explained ? >Because, the number formats called big ENDian have the LEAST significant >byte at the END, and the little ENDians have the MOST significant byte >at the END. > >Can anybody explain ? > >Regards > >Bernd > > >Am Mit, 06 Aug 2003 schrieben Sie: >> Has to do with the order of bytes and significance. Whether, for >> example, decimal 123456789 which is hex 0x75BCD15 is stored as 07 5B >CD >> 15 (big endian) or 15 CD 5B 07 (little endian). Intel is little >endian. >> >> ~ Daniel >> > > >Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
