> 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
