1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Endianness does not apply to byte

Discussion in 'Embedded' started by karthikbg, Nov 17, 2006.

  1. karthikbg

    karthikbg Guest

    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, Nov 17, 2006
    #21
    1. Advertisements

  2. karthikbg

    DJ Delorie Guest

    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.
    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).
    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.
     
    DJ Delorie, Nov 17, 2006
    #22
    1. Advertisements

  3. karthikbg

    DJ Delorie Guest

    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.
     
    DJ Delorie, Nov 17, 2006
    #23
  4. 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, Nov 17, 2006
    #24
  5. 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, Nov 17, 2006
    #25
  6. The Series 32000 had bit instructions which could address
    up to 1 Gbit from a base address.


    --
    Best Regards,
    Ulf Samuelsson

    This message is intended to be my own personal view and it
    may or may not be shared by my employer Atmel Nordic AB
     
    Ulf Samuelsson, Nov 17, 2006
    #26
  7. if it had have been big endian then the same code would be
    The final word in this discussion came about 20 years ago.

    The only good endian is a DEAD endian!


    --
    Best Regards,
    Ulf Samuelsson

    This message is intended to be my own personal view and it
    may or may not be shared by my employer Atmel Nordic AB
     
    Ulf Samuelsson, Nov 17, 2006
    #27
  8. karthikbg

    rickman Guest

    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?
     
    rickman, Nov 17, 2006
    #28
  9. karthikbg

    msg Guest


    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, Nov 17, 2006
    #29
  10. karthikbg

    rickman Guest

    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.
     
    rickman, Nov 17, 2006
    #30
  11. 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).
    It usually isn't -- which is why a said little endian can be
    simpler for the hardware or the compiler.
     
    Grant Edwards, Nov 17, 2006
    #31
  12. karthikbg

    jacko Guest

    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
    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
     
    jacko, Nov 17, 2006
    #32
  13. 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
     
    Everett M. Greene, Nov 17, 2006
    #33
  14. 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
     
    Paul Keinanen, Nov 17, 2006
    #34
  15. 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, Nov 17, 2006
    #35
  16. 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, Nov 17, 2006
    #36
  17. karthikbg

    CBFalconer Guest

    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/>
     
    CBFalconer, Nov 17, 2006
    #37
  18. However, the list time I have seen a truly serial computer was the

    COP800 is bitserial.

    --
    Best Regards,
    Ulf Samuelsson

    This message is intended to be my own personal view and it
    may or may not be shared by my employer Atmel Nordic AB
     
    Ulf Samuelsson, Nov 17, 2006
    #38
  19. I agree. It's always sounded like after-the-fact
    rationalization to me, but I've seen that argument in various
    places.
    Probably not.
    My examples didn't involve a variable changing type. It
    involved automatic conversion of one type to another.
    That's certainly one way to do it.

    [...]
    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, Nov 17, 2006
    #39
  20. Sure. If you're on a load-store machine, that's probably the
    obvious way to implement that.
    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, Nov 17, 2006
    #40
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.