Endianness does not apply to byte

rickman wrote:
> What you don't seem to grasp and no one is explaining to you properly,
> is that endian-ness is not a function of the bits or the bytes, but of
> the *addressing*.  Most machines can not address bits, so bits are not
> part of endian-ness.  If a machine only addresses words and not bytes,
> it does not *have* endian-ness in any regard.
>
> You are assuming that because a word is written as 00001, the 1 is in
> the right or least or last position.  But this is not what endian-ness
> is about.  It is about how the machine addresses the units.  So
> endian-ness only applies when different sized units are addressed.
>
> Is that more clear?
>
>
> karthikbg wrote:
> > larwe wrote:
> > > DJ Delorie wrote:
> > >
> > > > Sorry, Data General and IBM mainframes have the MSB numbered '0'.
> > >
> > > PA-RISC also does this. What a pain in the ass it is, by the way. I
> > > worked with a chip that was essentially an i486 SoC where the 486 core
> > > was removed and replaced with a PA-RISC.  All the CPU registers and bus
> > > lines were numbered in the MSB=right-hand convention. All the
> > > peripherals were numbered in the MSB=left-hand convention. Possibly the
> > > worst 32-bit micro I have ever used.
> > >
> > > 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 ??
> >
> > Really strange. Any specific reasons for this ??? Eager to know about
> > this.
> >
> > Thx in advans,
> > Karthik Balaguru

Thx for all your responses. It clarified my doubts.

So  ->  endian-ness is not a function of the bits or the bytes, but of
the *addressing*.  Most machines can not address bits, so bits are not
part of endian-ness.  If a machine only addresses words and not bytes,
it does not *have* endian-ness in any regard.

Thx,
Karthik Balaguru

"karthikbg" <karthik.balaguru@lntinfotech.com> writes:
> So  ->  endian-ness is not a function of the bits or the bytes, but of
> the *addressing*.

Right.  Think of it this way - when people say "endianness" they
usually mean "byte endianness" - assume they're talking about the
addressability of bytes within words, or words within multiwords,
which can be different - Crays have "nuxi" endian - bytes are little
endian within words, but words are big endian within dwords (er, or
visa-versa).  I think ARM FPUs can be too, because the CPU is one
endian, which governs out to the data bus, but the FPU may be a
different endian, which governs things larger than the data bus.

> Most machines can not address bits, so bits are not part of
> endian-ness.

Some MCUs *can* address bits (the M32C can address the first 64k bits
*directly* and *absolutely*) and in those cases, you have to consider
both byte endianness and bit endianness (for the M32C, they're both
little-endian - the LSB of word 0 and byte 0 is absolute bit 0).

> If a machine only addresses words and not bytes, it does not *have*
> endian-ness in any regard.

It can still have word endianness - consider a machine that addresses
32 bit "units".  If you want to store a 64 bit value, you still have
word endianness to consider.

Summary:

bit endianness - whether the lowest addressed bit is the LSB or the
MSB of a byte (applies to structure bitfield layout and bit-addressing
opcodes).

byte endianness - whether the lowest addressed byte in a word is the
LSB or the MSB.

word endianness - whether the lowest addressed word in a multi-word is
the LSB or the MSB.

"word" is often defined as "the size of our data bus" because that's
where the difference (when there is a difference) often originates.

"karthikbg" <karthik.balaguru@lntinfotech.com> writes:
> Why did Little-Endian come ?

My guess is compatibility with previous processors.  I.e.  emulating
an 8 bit cpu on a 16 bit LE cpu might be easier than on a 16 bit BE
cpu.

On 2006-11-17, karthikbg <karthik.balaguru@lntinfotech.com> wrote:

> So  ->  endian-ness is not a function of the bits or the bytes, but of
> the *addressing*.

Correct.

> Most machines can not address bits, so bits are not
> part of endian-ness.  If a machine only addresses words and not bytes,
> it does not *have* endian-ness in any regard.

Exactly.  Endianness only matters if a machine can address more
than one sized chunks of bits in memory _and_ multiple
contiguous, individually adressible chunks of bits can also be
addressed as a single, larger, chunk.

If a machine can address 16-bit words and 32-bit dwords, then
endianness rears it's head once again.  However, if a machine
can only address memory in a single size (e.g. only as 32-bit
words or only as 8-bit words), then there is no such thing as
endianness _in_hardware_. 

On a machine that only addresses 8-bit bytes, there may still
be software libraries or compilers that treat multiple bytes as
a single value, and that software library or compiler will have
an "endianness".

-- 
Grant Edwards                   grante             Yow!  What UNIVERSE is
                                  at               this, please??
                               visi.com            

On 2006-11-17, DJ Delorie <dj@delorie.com> wrote:
>
> "karthikbg" <karthik.balaguru@lntinfotech.com> writes:
>> Why did Little-Endian come ?
>
> My guess is compatibility with previous processors.  I.e.  emulating
> an 8 bit cpu on a 16 bit LE cpu might be easier than on a 16 bit BE
> cpu.

Little-endian can be a bit simpler for the hardware design
and/or compiler since the address you put on the bus when you
read a variable doesn't change depending on the destination
type.  

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.

-- 
Grant Edwards                   grante             Yow!  I've got to get
                                  at               these SNACK CAKES to NEWARK
                               visi.com            by DAWN!!

"rickman" <gnuarm@gmail.com> skrev i meddelandet 
news:1163780877.951597.57660@f16g2000cwb.googlegroups.com...
> What you don't seem to grasp and no one is explaining to you properly,
> is that endian-ness is not a function of the bits or the bytes, but of
> the *addressing*.  Most machines can not address bits, so bits are not
> part of endian-ness.  If a machine only addresses words and not bytes,
> it does not *have* endian-ness in any regard.

The Series 32000 had bit instructions which could address
up to 1 Gbit from a base address.

>
> You are assuming that because a word is written as 00001, the 1 is in
> the right or least or last position.  But this is not what endian-ness
> is about.  It is about how the machine addresses the units.  So
> endian-ness only applies when different sized units are addressed.
>



-- 
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 

> 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.
>

The final word in this discussion came about 20 years ago.

The only good endian is a DEAD endian!

> But then again, it's been a long time since I worked in assembler. I might 
> have even mixed up processors above!!
>
> Mike.



-- 
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 

Grant Edwards wrote:
> On 2006-11-17, DJ Delorie <dj@delorie.com> wrote:
> >
> > "karthikbg" <karthik.balaguru@lntinfotech.com> writes:
> >> Why did Little-Endian come ?
> >
> > My guess is compatibility with previous processors.  I.e.  emulating
> > an 8 bit cpu on a 16 bit LE cpu might be easier than on a 16 bit BE
> > cpu.
>
> Little-endian can be a bit simpler for the hardware design
> and/or compiler since the address you put on the bus when you
> read a variable doesn't change depending on the destination
> type.
>
> 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?  Why would this be a
function of the hardware rather than the software?  Maybe I have been
working with MCUs too long, but I am missing this.

My understanding is that little and big endian-ness came about the same
way that msb and lsb bit numbering came about.  Two different companies
had different ideas of which was better.  If I am not mistaken, this is
still a topic of some debate.  Personally I prefer to order the bytes
with the ls byte first, followed by the ms byte and followed by all
intermediate bytes.  This way you only need to increment by 1 to
address the sign bit vs addressing the low byte.  Sounds pretty
optimal, no?

Grant Edwards wrote:

> On 2006-11-17, karthikbg <karthik.balaguru@lntinfotech.com> wrote:

>>Why, the Bit_Order has not been taken into consideration ??
> 
> 
> Because on most machiens _there_is_no_such_thing_as_bit_order_.
> 
<snip>
> You can't index into a word like this:
> 
>     unsigned u = 12345;
>     bool b = u[0];   // is u[0] MSB or LSB of u?   


I have worked on machines that include the above facility
in the ISA.  Bit order is also important in serial machines
and there are many examples of parallel architectures
which put the opcode, modifiers and addresses in
unconventional positions or orders, sometimes with
LSB first in a field.  Manipulating subsets or supersets
of these fields requires knowledge of bit order.

Regards,

Michael Grigoni
Cybertheque Museum

msg wrote:
> Grant Edwards wrote:
>
> > On 2006-11-17, karthikbg <karthik.balaguru@lntinfotech.com> wrote:
>
> >>Why, the Bit_Order has not been taken into consideration ??
> >
> >
> > Because on most machiens _there_is_no_such_thing_as_bit_order_.
> >
> <snip>
> > You can't index into a word like this:
> >
> >     unsigned u = 12345;
> >     bool b = u[0];   // is u[0] MSB or LSB of u?
>
>
> I have worked on machines that include the above facility
> in the ISA.  Bit order is also important in serial machines
> and there are many examples of parallel architectures
> which put the opcode, modifiers and addresses in
> unconventional positions or orders, sometimes with
> LSB first in a field.  Manipulating subsets or supersets
> of these fields requires knowledge of bit order.

This is unrelated to the issue of endian-ness.  Only if the bits in a
word are directly addressable as part of a general address is the
endian-ness an issue.  Sure, you need to know how the machine maps bit
fields in an instruction to make it work correctly, but everything
about accessing data is not endian-ness.

There have been a few machines that were addressable at the bit level,
but none have been popular and mostly they have had little impact on
computing.