in reply to Re: Understanding endianness of a number
in thread Understanding endianness of a number

Thanks a boatload, haukex!

After I wrote my question here, I continued doing research. I was comparing endianness with the year long work I've been doing with hardware registers, so I could not quite grasp things until it did click (then you re-affirmed) that endianness (mostly) refers to byte storage, not (typically) bit storage.

By the time I wrote my post here, I thought I had it, but just wanted clarification. You covered it perfectly, even down to sometimes bits, and how some 32 or 64 bit ints may even have the middle bytes reversed. I think I'll leave that for another day until I run into it, if ever. :)

I also agree with your shift first then perform and/or-ing. I ran into that while playing around during this whole lesson. Not only can it catch edge case problems, I feel it's quicker to digest/comprehend when glancing through code. Thanks for that tidbit too.

The endianness issue cropped up because I was getting weird (read: backwards) results when trying to read two bytes as a single 16-bit int from an Arduino over I2C. This case is present in this post that I made, within the Arduino sketch portion of it, within the __read_analog() function.

Thanks again,

-stevieb

Replies are listed 'Best First'.
Re^3: Understanding endianness of a number
by haukex (Archbishop) on Jul 23, 2017 at 20:14 UTC

    Glad to help!

    endianness (mostly) refers to byte storage, not (typically) bit storage

    Yeah, I think there's some ambiguity there, e.g. whether LSB and MSB mean bytes or bits - Wikipedia makes a good point about context:

    LSB can also stand for least significant byte. ... If the abbreviation's meaning least significant byte isn't obvious from context, it should be stated explicitly to avoid confusion with least significant bit.

    Although the entry on Endianness does differentiate a bit more clearly:

    The order of bits within a byte or word can also have endianness (as discussed later); however, a byte is typically handled as a numerical value or character symbol and so bit sequence order is obviated.

    And then goes on talk about "Bit endianness" in its own section.

[reply]

      Yep, definitely gleaned that from the article. It just took a few iterations before I fully separated the two. For years, ever since I began coding around ~Y2K, I've heard and saw "endian" thrown around quite a bit, but never had the need to research what it actually was.

      All of it is quite fascinating, and I'm enjoying everything I've been working on dealing with how electronics store and use bits and bytes.

[reply]
Re^3: Understanding endianness of a number
by Marshall (Canon) on Jul 23, 2017 at 22:04 UTC
    how some 32 or 64 bit ints may even have the middle bytes reversed
    I don't know of a thing like that. How the data is stored in memory has a simple algorithm. See this link which also gives a list of "endianess" for various file formats.
[reply]

      Thanks Marshall for the reply.

      I phrased it incorrectly, as in this regard I definitely have a juvenile understanding of the terminology. Also, I haven't done much digging (and testing) beyond a 16-bit int at this point. From the mentioned Wikipedia article, what I meant was:

      Mixed forms also exist, for instance the ordering of bytes in a 16-bit word may differ from the ordering of 16-bit words within a 32-bit word. Such cases are sometimes referred to as mixed-endian or middle-endian. There are also some bi-endian processors that operate in either little-endian or big-endian mode.

      Cheers for the link. The more info I have to expand and hone my understanding, the better it is for me.

[reply]
        Well in the computer world, just about every wild scheme that you can imagine has probably been tried! Over time the variations that are actually "seen in the wild" have become fewer. For the most part, you will either see pure little endian like Intel or pure big endian like Motorola. Over time, for example "byte" has come to mean "8 bits" although historically that has not been strictly true.

        update:
        For example in the "famous" IBM punched card format, there are 12 bits available for each printed character. There are actually 3 Hollerith codes which were used with IBM punched cards, I only worked with IBM system 26 and IBM system 29. I never saw the predecessor to System 26 which itself was already obsolete in the 70's. Anyway each punched card could have 12 bits per character, certainly not "8 bits". This wiki article doesn't clearly explain the difference between the 3 Hollerith codes, but gives an idea Hollerith codes. If there is interest, I can dig up the official names for the 3 Hollerith codes that IBM used, but I don't think that matters here. The point here being that a single character could have been 12 bits, not 8 bits in the distant past.

        More weirdness: the "zigamorph", yes that is an actual word. I think this was 12-11-0-7-8-9 multi-punch. In FORTRAN IV, this signals a comment on the same line as a statement. I never wrote code that used that, but it was a possibility.

        System 29 keypunch system 29.

[reply]

        PDP-11 was very common in its time, and used the 'BADC' byte order.

        I thought wikipedia would have that tidbit, but apparently not. [softwareengineering.stackexchange.com/questions/215535|This]#1 seems to have a good answer. Anyway, one benefit of the little-endian architecture is that it can help you with pointer addressing. One may cast an int pointer to unsigned char pointer, and use that to inspect the "character value" of a small int. Zero offset ie no index uses the simpler addressing mode and may yield more compact machine code.

        Little-endian is conceptually similar to positional number system, where the number base is exponentiated by index. Index 0 for the smallest digit and so on. (In big-endian, the offset is offset by the operand width. Buffalo buffalo buffalo;)

        #1. Linking to stackexchange is prohibited?

[reply]

In Section Seekers of Perl Wisdom