> From: [email protected] > The bit-order *within each byte* is still "most significant on the > left" in both big- and little- endian systems.
So the Chief bit is on the left? ;-) Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html > Date: Tue, 12 Apr 2011 14:41:34 +1000 > From: [email protected] > Subject: Re: New job for mainframes: Cloud platform > To: [email protected] > > Well, let's not skew the kiddie's brains too much.. > > "Endian- ness", in the context used in these posts, refers to BYTE > order not BIT order. > > The bit-order *within each byte* is still "most significant on the > left" in both big- and little- endian systems. > > Another wrinkle: In the x86 world (little-endian) Intel "names" the > bits within a byte, from the left, 7,6,5,4,3,2,1,0 whereas in the z.. > world (big-endian) IBM "names" them 0,1,2,3,4,5,6,7. Regardless of > the naming scheme used, the "rightmost" bit in each byte is the > least-significant. :-) > > An x86 code fragment might help to illustrate: > > .code > mov eax,258 ;let's start with 258 KG > mov weight,eax > .. > .. > ret > .data > weight dd 0 ;weight in kilograms > > After that 2nd mov instruction, while the 32-bit eax register looks like: > > bits 32,31,..,24 > | bits 23,22,..,16 > | | bits 15,14,..,8 > | | | bits 7,6,5,..,0 > | | | | > eax: 00000000 00000000 00000001 00000020 > > ..the four bytes at label "weight" will look like: > > weight 00000010 00000001 00000000 00000000 > | | | | > | | | bits 32,31,..,24 > | | bits 23,22,..,16 > | bits 15,14,..,8 > bits 7,6,5,..,0 > > So, bit numbering aside, it still looks like a big-endian world once > you're "inside" the processor. > > Cheers, > Graeme > > > At 03:46 PM 11/04/2011, you wrote: > >Computer networks (including the Internet) are inherently big endian. > >Little endian CPUs, such as Intel/AMD X86 and X86-64, have to flip the bit > >order when engaging in network communications. That bit flipping obviously > >works (and is usually performed by the network driver), but it's not > >totally free in terms of instructions. > > > >ARM and Power CPUs are capable of running in either big endian or little > >endian mode. When ARM CPUs are deployed primarily for networking-related > >missions (such as embedded controllers for routers), especially in > >power-sensitive roles, there's some appeal to running in big endian mode. > >Hence, Linux (and some other operating systems) are available for ARM's big > >endian mode. That's the "armeb" flavor of Linux, specifically. Linux for > >Power always runs in big endian mode. > > > >Itanium is also bi-endian and can run in either mode. VMS, for example, > >runs on Itanium in little endian mode. I was merely pointing out that there > >are lots of big endian CPUs that are selling very well and that are running > >Linux in big endian mode, including System z, Power, and ARM. There's no > >danger that Linux will somehow forget big endian bit order any more than > >X86 CPUs will forget how to use the Internet. > > > >To pick another example, Solaris is available in both little endian > >(X86-64) and big endian (SPARC) flavors. Not surprisingly, Java is almost > >entirely endian-agnostic, but to the extent bit order matters it's big > >endian. > > > >I've known HP in its sales pitches to make a lot of fuss about endianness > >as reason why it would be oh-so-difficult for an HP-UX customer to move to > >Linux on X86, or for a Linux X86 customer to move to (or add) Linux on > >System z, depending on their sales situation. Then hundreds/thousands of HP > >customers moved without endianness difficulty, and many more will follow. > >The IT community figured out how to flip bit order a long time ago. Before > >System/360, even. That's not to say endianness isn't a problem...for HP. If > >they want to move HP-UX to a little endian CPU, they'll have a lot of > >investment to do (as Sun did for Solaris X86). For non-OS > >kernel/non-compiler programmers, which is the vast majority of us, it's not > >a real-world problem. In fact, endianness is one of the least interesting > >issues when porting from one CPU to another. > > > >For my thoughts on the HP Itanium meltdown, see The Mainframe Blog: > > > >http://mainframe.typepad.com/blog/2011/04/hp-itaniums-ignominious-demise.html > > > >- - - - - > >Timothy Sipples > >Resident Enterprise Architect > >Value Creation & Complex Deals Team > >IBM Growth Markets (Based in Singapore) > >E-Mail: [email protected] > >---------------------------------------------------------------------- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to [email protected] with the message: GET IBM-MAIN INFO > >Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
