On 2006-11-17, rickman <gnuarm@gmail.com> wrote:>> If variable X is a 32-bit integer at address 0x1234, reading >> it as a long, char or short always generates address 0x1234. >> For a big-endian machine, the address changes depending on how >> you want to read the variable. Reading it as a char generates >> address 0x1237. Reading it as a short generates 0x1236. >> >> Not a huge deal, but back in the day gates were more expensive. > > I can't say I undestand. If you have a 32 bit integer, in what context > would it be permissible to read it as a char?What do you mean "permissible"? In C the following is permissible: char x; long y; [...] x = y; If y is static, then the address to be read for the assignment statement can be calculated at compile time, so it doesn't really matter. If y is being accessed indirectly, then the address must be offset by 3 at run-time: char x; long *yp; x = *yp; The assigment statement above must generate a read of adderss (yp+3) for big-endian machines. On some CPUs, that would require an extra instruction or two compared with generating a read of addresss (yp).> Why would this be a function of the hardware rather than the > software?It usually isn't -- which is why a said little endian can be simpler for the hardware or the compiler. -- Grant Edwards grante Yow! -- I love KATRINKA at because she drives a visi.com PONTIAC. We're going awaynow. I fed the cat.
Endianness does not apply to byte
Started by ●November 17, 2006
Reply by ●November 17, 20062006-11-17
Reply by ●November 17, 20062006-11-17
Ulf Samuelsson wrote:> > if it had have been big endian then the same code would be > > mov al,Var+3 > > mov ax,Var+2 > > mov eax,Var > > Yuk. > > So, little endian wins in my book. > >yes and all loops end in zero, so big endian has easier multiword looping. so i prefere logical big endian as per http://indi.microfpga.com> > The final word in this discussion came about 20 years ago. > > The only good endian is a DEAD endian!and so say all the thugs!! most significant at index 0 or at index X ?? i'd store strings with first character at index 1 and a zero indexed count. and C was designed by bad bad men! ;-) cheers
Reply by ●November 17, 20062006-11-17
"karthikbg" <karthik.balaguru@lntinfotech.com> writes:> Just like Bytes make the Most Significant BYTE(MSB) and LSB of many > datatypes. > The Bits make the Most Significant BIT(MSB) and LSB of a Byte. > > It is strange that Endiannes is not dependent on the Bit_Order of a > Byte but only on the Byte_order. > > My questions are : > Why bits of a byte are of Big-Endian type ? > Then, we could have gone for Big-endian throughout all designs !! > > Why did Little-Endian come ? > > Why bits of BYTEs do not have endianness ? > Just like bytes, bits are also manipulated in many places in the form > of MSB and LSB only. > Every basic driver level interface goes to the BIT level. > > So, Why the Bit_Order has not been taken into consideration ?? > > Really strange. Any specific reasons for this ??? Eager to know about > this.Little-endiness seems to have arisen with doing mutlibyte operations on 8-bit processors. Someone thought it would be "neat" if one could start with the first byte in memory and work upward for whatever number of bytes were going to be accessed for the operation. It apparently escaped the notice of these people that starting n bytes higher and working downward accomplishes the same thing and has the bytes in a natural order for reading by humans. As for bit-numbering, IBM (once?) used a fractional notation for binary values instead of the integer notation used by everyone else. Luckily, fractional notation is really foreign to humans and has mostly died the death it deserves. There are a few older IBMers around who use it, but it's otherwise joined the dodo bird. ----------------------------------------------------------------------- "Big-Endian byte order is known as 'normal', 'intuitive', or 'obvious'. Little-Endian is sometimes called 'perverse', 'annoying', 'dysfunctional', or 'stupid'. These designations do not, of course, imply any bias or preference." Christopher R. Hertel, "Implementing CIFS" 2004
Reply by ●November 17, 20062006-11-17
On Fri, 17 Nov 2006 15:45:31 -0000, Grant Edwards <grante@visi.com> wrote:>On 2006-11-17, karthikbg <karthik.balaguru@lntinfotech.com> wrote: > >>> However it doesn't alter the fact that "big-endian" vs "little-endian" >>> is by definition a discussion of _byte_ order, not _bit_ order. >> >> It is really strange that Endiannes is not dependent on the Bit_Order >> but only on the >> Byte_order. >> >> Why, the Bit_Order has not been taken into consideration ?? > >Because on most machiens _there_is_no_such_thing_as_bit_order_.Bit order only existed with serial computers, in which it was natural to feed LS bit first to the 1 bit ALU for addition and subtraction. Serial computers were built with shift register, CCD or acoustic (mercury) delay line accumulators. However, the list time I have seen a truly serial computer was the HP-35 scientific pocket calculator in the early 1970's, while other pocket calculators used bit parallel but decimal (BCD) digit serial architectures. Paul
Reply by ●November 17, 20062006-11-17
Grant Edwards wrote:> If variable X is a 32-bit integer at address 0x1234, reading it > as a long, char or short always generates address 0x1234. For a > big-endian machine, the address changes depending on how you > want to read the variable. Reading it as a char generates > address 0x1237. Reading it as a short generates 0x1236.I've heard this argument before, but it seems somewhat contrived. Are there many programs where the same 32-bit integer needed to be read 3 different says? Most programming languages do not allow a variable to change type; the value may change type, but that usually happens when the variable is already in a register. At one point, computers were created that had addressable memory units that were smaller than their natural internal data size, and so a decision about how to store the data had to be made. Some computers went one way, and some another. The decision was likely based upon existing software that the new computer needed to try and be compatible with. That's the story in short form. Big-endian is easier for some things, little-endian for others. Neither is more "natural" than the other; both are unnatural. -- Darin Johnson
Reply by ●November 17, 20062006-11-17
Grant Edwards wrote:> char x; > long *yp; > > x = *yp; > > The assigment statement above must generate a read of adderss > (yp+3) for big-endian machines.Why? You just read *yp into a long register, then write the least significant byte into x. Now a compiler may optimize this to be just a byte read on machines where the performance would make a difference (many are forced to always read a full cache block anyway). But most instruction sets for 32-bit processors already include a displacement for addressing. (though on CISCy computers with variable length instructions, it might require more space?) Consider this case, which computers have also have to put up with regardless of byte ordering: struct mytype { int a, b, c, d; }; mytype* mp; int x; ... x = mp->d; -- Darin Johnson
Reply by ●November 17, 20062006-11-17
> However, the list time I have seen a truly serial computer was the > HP-35 scientific pocket calculator in the early 1970's, while other > pocket calculators used bit parallel but decimal (BCD) digit serial > architectures. >COP800 is bitserial. -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
Reply by ●November 17, 20062006-11-17
Paul Keinanen wrote:>... snip ...> > However, the list time I have seen a truly serial computer was the > HP-35 scientific pocket calculator in the early 1970's, while other > pocket calculators used bit parallel but decimal (BCD) digit serial > architectures.I built a machine in 1965 that used bit serial arithmetic, coupled with excess-3 decimal, and 9 significand digits floating point. The logic was DTL. The use of excess-3 and 9's complement arithmetic simplified display of negative values. See: <http://cbfalconer.home.att.net/firstpc/> -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net>
Reply by ●November 17, 20062006-11-17
On 2006-11-17, Darin Johnson <darin@usa.net> wrote:>> If variable X is a 32-bit integer at address 0x1234, reading it >> as a long, char or short always generates address 0x1234. For a >> big-endian machine, the address changes depending on how you >> want to read the variable. Reading it as a char generates >> address 0x1237. Reading it as a short generates 0x1236. > > I've heard this argument before, but it seems somewhat contrived.I agree. It's always sounded like after-the-fact rationalization to me, but I've seen that argument in various places.> Are there many programs where the same 32-bit integer needed > to be read 3 different says?Probably not.> Most programming languages do not allow a variable to change > type;My examples didn't involve a variable changing type. It involved automatic conversion of one type to another.> the value may change type, but that usually happens when > the variable is already in a register.That's certainly one way to do it. [...]> Big-endian is easier for some things, little-endian for > others. Neither is more "natural" than the other;Yup. The "net" is big-endian, so that's a pretty good arguement for using big-endian for anything that's network intensive (firewall, router, etc.). For other things, it doesn't really matter much. -- Grant Edwards grante Yow! .. does your DRESSING at ROOM have enough ASPARAGUS? visi.com
Reply by ●November 17, 20062006-11-17
On 2006-11-17, Darin Johnson <darin@usa.net> wrote:> Grant Edwards wrote: >> char x; >> long *yp; >> >> x = *yp; >> >> The assigment statement above must generate a read of adderss >> (yp+3) for big-endian machines. > > Why? You just read *yp into a long register, then write the > least significant byte into x.Sure. If you're on a load-store machine, that's probably the obvious way to implement that.> Now a compiler may optimize this to be just a byte read on > machines where the performance would make a difference > (many are forced to always read a full cache block anyway). > But most instruction sets for 32-bit processors already include > a displacement for addressing. (though on CISCy computers > with variable length instructions, it might require more space?)I was just quoting the oft-cited argument for little-endian. I didn't claim it was a good argument or that I agreed with it. I actually prefer big-ending, but that's because I work on a lot of network-centric stuff and it's easer to read hex dumps. -- Grant Edwards grante Yow! YOW!! I am having at FUN!! visi.com