<p>The way it was explained to me -- how this distinction without a difference came about -- is quite simple. If we are storing text in a file, it is quite natural (for users of ASCII, which has one byte per character) to place the characters one after another, starting with the first one at position zero. If more is added to the file, it easily goes on the end. This agrees with the convention of writing left to right, say on a board (white, green, brown, black, or otherwise.).</p>

<p>The wrinkle in the rug is that <em>numbers</em> are often larger than one byte (gosh darn it) and so we have two choices for how to write them in to a file, send in a stream, transmit data by radio from one Hawaiian island to another (the founding of the internet) and so on:</p>

<ul>
<li>send the most significant byte first  </li>
<li>send the least significant byte first  </li>
</ul>

<p><em>Huh</em>. Now there is a stumper for you. Which should we do? It is natural when the digits of a base-10 number are written in a text file, like "12,345", to send the first byte, well, first, eh? But someone decided that numbers should send the least significant <strong>bit</strong> first and then forward from there to the most significant bit. This makes total sense if you are writing out, say, the bits of a data stream (image file, encrypted data, etc) and so then it would be just like the ASCII text case, except bit-wise, and the bits should ascend as we write them on a board... uh, left to right. Yeah.</p>

<p>Bits, bytes, schmytes... What does it really matter? Well, just like how we ended up with cars going on the left in some parts of the world and otherwise right, just like how we have 220 V AC in parts of the world and 110 V split phase in other parts, just like how some languages are written in letter-scripts and others are written using ideograms, it makes no difference whatsoever, unless moving from one system to the other. The real question is:  </p>

<blockquote>
  <p>"why can't we all just get along?"</p>
</blockquote>

<p>Or in other words: <strong>why do standards emerge only after two or more groups have already made a big investment in different schemes?</strong> That is the subject of a larger course.</p>

CC BY-SA 3.0
2018-01-12T14:52:49.490Z
2018-01-12T14:52:49.490Z
user3929
<p>Mabye something here will be of use...</p>

<p>Little-endian means the lowest byte address holds the least significant bit (and byte).  Big-endian means the lowest byte address holds the most significant bit (and byte).</p>

<p>So, Little = Lowest Least.</p>

<p>And Big is the other one...</p>

<p>There are multiple possible ways because storing (and retrieving) a word in multiple bytes <em>is a form of serialization &amp; deserialization</em> &#8212; breaking down one large object into smaller chunks and vice versa.  These processes are inherently order sensitive by nature as each smaller chunk has a different specific placement within the larger.</p>

<p>Further, since the smaller sized chunks (here bytes) adds up to the same bit count as that of the larger item (here words), the arrangement of the ordering must be prescribed in advance (and otherwise it would take additional bits to indicate the order or encoding scheme (not to mention the additional logic to handle that)).</p>

<p>Two of those ways are fairly obvious: lowest least and lowest most.  In both those schemes, the address of a word is the lowest address of all of the bytes used in storing the word.  Given this addressing constraint, there are only two schemes for storing a 16-bit value in 2-bytes, though there are more permutations of byte order for storing a 32-bit value in 4-bytes.  </p>

<p>(Further, we might also consider that the address of a word is the address of the highest address therein, which would give rise to additional schemes, but these would give up the desirable property that word aligned addresses are even.)</p>

<p>In human terms we can write text left-to-right or right-to-left, or top-to-bottom or bottom-to-top, etc...  We can relate these various schemes to lower-to-higher addresses (maybe even to higher-to-lower addresses).</p>

<p>I consider that humans do little-endian for numbers <em>when we line them up e.g. for long arithmetic</em>, though right-to-left instead of lower-to-higher.  When we need larger numbers we expand digits to the left, anchoring the least significant digit in the same column; little endian pointer addresses point to LSBs regardless of the size of the data type.</p>

<p>By  contrast, to get more digits, big-endian shifts the number over to higher addresses in order to insert more digits at lower addresses (rather odd IMHO).  So, the byte at the address for a word points to an MSB.</p>

<pre><code>  Human    Little-Endian   Big-Endian
    92       29               92
+  910       019              910
 -----       ----             -----
  1002       2001             1002
</code></pre>

<p>You can see that little-endian (here shown with addresses increasing left-to-right) is mirror image of human.</p>

<p>Another approach I use is to show addresses on the right side of a word-sized dump for little endian.</p>

<pre><code> words      address
xxxxxxxx  &lt;- 0000
xxxxxxxx  &lt;- 0004
xxxxxxxx  &lt;- 0008
xxxxxxxx  &lt;- 000C
</code></pre>

CC BY-SA 3.0
2018-01-11T12:47:26.483Z
Quite similar, but I tend to use little endian = little end first, big endian = big end first. Seems to stick with the people I have explained it to.
Koekje
CC BY-SA 3.0
2018-01-11T02:35:50.567Z
2018-01-11T02:35:50.567Z
Erik Eidt
<p>TL;DR Items are numbered (indexed). For big-endian, start the count with the most significant item and work toward the least. For little-endian start with the least significant item and work toward the highest.</p>
<p>The <a href="https://en.wikipedia.org/wiki/Endianness" rel="nofollow noreferrer">Wikipedia page</a> and the post by user <a href="https://cseducators.stackexchange.com/a/4160/1293">Erik Edit</a> provide good technical details, but I'd rather give a memorable &quot;picture&quot; of what is going on.</p>
<p>First, if you only work on one computer architecture then <em>endianness</em> is automatic and of little consequence. It is when you need to transfer data from one system to another (if they have different architectures) that it matters. An early story is that in attempting to send &quot;Unix&quot; from one machine to another, &quot;nUxi&quot; showed up at the other end.</p>
<p>Suppose that you have a large group of &quot;marchers&quot; (bits) in a &quot;field&quot; (system memory). Suppose that you want to send them all to another field, but they must pass one at a time through a &quot;hallway&quot; (bit stream) to another field that may be organized differently. Each field has an &quot;organizer&quot; (architecture) that knows something about the organization (duh) of that field.</p>
<h2>Simplest case: one level organization</h2>
<p>We will first consider the simplest case of a single level of organization at each end with some similarities between them as described below.</p>
<p>In each field, the marchers are organized into &quot;squads&quot; of, say, 8 marchers per squad (note it is the same at both ends, one of the simplifications for now). Each squad has a leader (most significant bit), though the leader isn't marked in any way. The leader looks like any other marcher, but when the squad lines up the leader is always to the left. Since the marchers aren't very smart (just &quot;bits&quot;, remember), the organizer of a field will help them arrange themselves by instructing the members of the squad to each stand in a numbered location on the field. The locations for the members of an individual squad are numbered 0 through 7.</p>
<p>A field can be big-endian (think the big end of an egg), in which the leader of a squad stands on location 0 for that squad, with the other members arranged to its left. The last member (the least significant member) will be on slot 7.</p>
<p>Alternatively, a field can be little-endian (eggs again), in which slot numbers are reversed so that the leader of the squad is still to the left, but on this field that slot is number 7 so that the least significant marcher (bit) winds up in slot 0.</p>
<p>It is really only the field organizer that is responsible for the relative arrangement of the slots. If you look at a squad (or the whole field) ignoring those, a big-endian squad and a little-endian squad will look the same, with the leader to the left.</p>
<p>Now, however, one desires to move the marchers on a field to another field. Since this happens a lot, the &quot;association of organizers&quot; (standards groups) have decided that when going through a hallway (in single file), the leaders will go first, followed by the rest of its squad. It could have been the other way and there are a few places in which the rules aren't obeyed, but that leads to chaos so mostly the leader-first rule is used.</p>
<p>But it is the organizer of a field who must send marchers to the hallway and the organizer at the other end who must take marchers as they emerge from the hallway and line them up again.</p>
<p>Let's look at the sending organizer first. The organizer will &quot;point&quot; at a squad and then call off slot numbers for the movement of that squad to the hallway. If it is a big-endian field, then the organizer will count upwards from 0 to 7 for that squad, so that the leader (slot 0, remember) goes first and the rest follow, with the marcher in slot 7 going last for that squad. Other squads may follow as well, but we will come to that.</p>
<p>If the field is little-endian, however, the organizer simply counts downward from 7 to 0 instead. But this, again, sends the leader first.</p>
<p>Now we look at the other end of the hallway. The receiving organizer has to take the squads as they emerge and assign them to positions. A position has room for a squad, and it has numbered slots for the members as usual. If this field big-endian, the slots are, as usual numbered 0-7 left to right but if it is little endian the slots are numbered 7-0 left to right. So, the organizer at this end, takes marchers as they emerge from the hallway, and knowing that the leader of a squad will be first, just points to a location and counts off slot numbers appropriately. If this is a big-endian field, the organizer counts starting from 0, but a little-endian organizer will count downward from 7.</p>
<h2>Several levels</h2>
<p>Suppose, however, that the situation is more complex. Suppose that each squad is part of a larger grouping, a &quot;platoon&quot;. A platoon might consist of, say four squads, and they need to be treated for some purposes as a group. Again, the organizer of any given field needs to know things about that field, but as little as possible about other fields.</p>
<p>The biggest complication is that a field might be big-endian for squads, but little-endian for platoons (mixed endian). This is really only a complication for how you think of it, however. The organizer will do the right thing. We will assume here that the squads and platoons are organized the same. The squads of a platoon stand together (think a row) with one squad next to another. There will be four sets of squad-slots making up a platoon formation. Just like the numbering of the individual squad slots, the sets are numbered for the squads of a platoon. If the numbering from left to right is 0 through 3 then the platoon organization is big-endian. If it is 3 down to 0 it is little-endian. In all cases the squad to the left is the more significant squad and the one to the right is the least significant squad whatever the numbering.</p>
<p>Now, again, the organizer wants to send marchers through the hallway and will send the squads one after the other. The organizer knows the numbering of the platoon formation slots (0-3 or 3-0). So, to send a platoon through the hallway, supposing that we have big-endian throughout, the organizer first points to squad 0 (the most significant squad) and then counts off the marchers 0-7 as before. Squad 1 is sent next, etc, ending with the least significant squad (3). But if the field is organized little-endian at the platoon level, the organizer points to squad 3 as the start and counts off marchers, etc, ending with squad 0.</p>
<p>Note that in mixed endian there is no particular difficulty as long as the organizer knows what to do at any level. But, importantly, the most significant elements at any level are given priority. They will have low index number in big-endian and larger index numbers in little-endian organization at that level.</p>
<p>The situation at the receiving end is similar. The organizer there knows that the most significant squad in a platoon will come first and within a squad the leader will be first. So, having selected a place for the incoming platoon, the organizer points to what ever slot is reserved for the most significant squad (0 for big-endian, but 3 for little) and then counts off members either upward or downward depending on the appropriate ordering for that field. This will, of course be the left-most of the squad locations. The organizer then points to the next location and counts off the second squad, etc. At the end, the platoon is lined up just as before, though the indexes of the slots won't be the same for the fields at the two ends of the hallway.</p>
<h2>Even more complex: inconsistent squad and/or platoon sizes</h2>
<p>I won't attempt a complete explanation here as there are too many possibilities. It may be that the organizers at the ends need some information about both fields, not just their own. I'll assume a single level of grouping here (squads), but higher levels (platoons) would be similar.</p>
<p>One common case is that you are sending a squad with say six members into a field in which squads have eight. The sending organizer can behave just as before, sending the leader first as usual, but counting from 0 to 5 or 5 to 0 depending on endianness. The organizer at the other end has a problem though. First it needs to know that only six marchers are coming per squad, with the leader first. It has to put the marchers into the eight slots. Normally (but not necessarily) the members would be placed so that the least significant member winds up in the least significant slot, with the two most significant slots left empty. This means that if the receiving field is big-endian, the leader of the squad winds up in slot 2, and if little-endian in slot 5.</p>
<p>Another variation is when the sending field has a squad length that is half the size of the squad length in the receiving field. Then the receiving field can do as just above, or can &quot;pack&quot; two of the incoming squads into a single squad section in this field. Keeping in mind that the squads come through the hallway most-significant-first, the first four-member squad would go to the left in the eight-marcher region and the second squad would go to the right. The slot numbers of course depend on the endianness, but the organizer just points to a place and counts off slot numbers as the marchers come through.</p>
<p>Sending from a field in which the squad sizes are larger than the receiving field is more complex and won't be described in detail here. But either some marchers get sent to the sidelines (unlikely but possible) or the incoming marchers will need to be distributed over more than one of that field's positions. The key to working out a proper protocol is that the marchers come through in most-significant-first at any level, though the organizer at the receiving end will need to know how to break up or combine the marchers into squads at that end. Remember, that all of the marchers look alike. There is nothing to distinguish any of them. The leader doesn't look anything different from any other marcher, nor is there any way to &quot;mark&quot; divisions between squads. That needs to be known to the organizer in advance.</p>
<hr />
<p>We note for the record that some systems are <em>bi-endian</em> and can be organized (either in hardware or software) either big- or little-endian. At a given moment, they are one or the other, unless you want chaos to rule.</p>

CC BY-SA 3.0
2018-01-11T22:45:06.550Z
"First, if you only work on one computer architecture then endianness is automatic and of little consequence" I have to disagree with that. When I write disassemblers on Intel which use little endianness and the code coming out is little endian and [Intel Architecture Software Developer Manuals](https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf)  make references in big endian, then not knowing this will ruin your day. Continued
Guy Coder
CC BY-SA 3.0
2018-01-11T22:45:47.127Z
I can't remember how much of a problem it was because after I figured it out I was able to abstract it away in a function, but for disassemblers of little endian processors I would not say "of little consequence" :)
Guy Coder
CC BY-SA 3.0
2018-01-11T14:21:54.333Z
2018-01-11T17:00:30.150Z
2020-06-18T08:36:57.023Z
Buffy
<p>I have explained big and little endian from time to time in my teaching career, but it is quite dry, and asking my students which direction each one goes three months later has revealed to me that my lesson doesn't make which "end" goes with which part of memory really <em>stick</em> for my students.</p>

<p>I would like to explain endian-ness so that it is fun, memorable, and makes clear why the two systems exist, but I haven't found a good way yet. It's a small concept, so it can be a short demonstration, but I still want to make it effective.</p>

<p>Does anyone have any classroom tricks up their sleeves for this one? </p>

CC BY-SA 3.0
2018-01-11T03:01:23.693Z
I remember using the concept several decades back when it was reasonable for a hobbyist with a soldering iron to put together a "state of the art" home computer. In industry, I have needed to be aware of it occasionally and handle it rarely. I still have to look it up when I need it, after decades in industry. But ... the concept is important so you can recognize when you need to look it up again.
pojo-guy
CC BY-SA 3.0
2018-01-12T06:51:17.527Z
Endian is named after the end of an egg that the lillyputians eat their eggs from, precisely because it does not matter. If code is written well, it does not matter. All you need is an awareness of the problem, and how not to depend on it.
ctrl-alt-delor
<lesson-ideas>
Big-endian, Little-endian
# Big-endian, Little-endian

(Asked by: username_0 on 2018-01-10)

I have explained big and little endian from time to time in my teaching career, but it is quite dry, and asking my students which direction each one goes three months later has revealed to me that my lesson doesn't make which "end" goes with which part of memory really *stick* for my students.

I would like to explain endian-ness so that it is fun, memorable, and makes clear why the two systems exist, but I haven't found a good way yet. It's a small concept, so it can be a short demonstration, but I still want to make it effective.

Does anyone have any classroom tricks up their sleeves for this one?

**Tags:** lesson-ideas

> **Comments:**
> **username_1**: I remember using the concept several decades back when it was reasonable for a hobbyist with a soldering iron to put together a "state of the art" home computer. In industry, I have needed to be aware of it occasionally and handle it rarely. I still have to look it up when I need it, after decades in industry. But ... the concept is important so you can recognize when you need to look it up again.  
> **username_2**: Endian is named after the end of an egg that the lillyputians eat their eggs from, precisely because it does not matter. If code is written well, it does not matter. All you need is an awareness of the problem, and how not to depend on it.  

---

## 3 answers

### Answer by username_3 on 2018-01-12. Score: 2

The way it was explained to me -- how this distinction without a difference came about -- is quite simple. If we are storing text in a file, it is quite natural (for users of ASCII, which has one byte per character) to place the characters one after another, starting with the first one at position zero. If more is added to the file, it easily goes on the end. This agrees with the convention of writing left to right, say on a board (white, green, brown, black, or otherwise.).

The wrinkle in the rug is that *numbers* are often larger than one byte (gosh darn it) and so we have two choices for how to write them in to a file, send in a stream, transmit data by radio from one Hawaiian island to another (the founding of the internet) and so on:

* send the most significant byte first
* send the least significant byte first

*Huh*. Now there is a stumper for you. Which should we do? It is natural when the digits of a base-10 number are written in a text file, like "12,345", to send the first byte, well, first, eh? But someone decided that numbers should send the least significant **bit** first and then forward from there to the most significant bit. This makes total sense if you are writing out, say, the bits of a data stream (image file, encrypted data, etc) and so then it would be just like the ASCII text case, except bit-wise, and the bits should ascend as we write them on a board... uh, left to right. Yeah.

Bits, bytes, schmytes... What does it really matter? Well, just like how we ended up with cars going on the left in some parts of the world and otherwise right, just like how we have 220 V AC in parts of the world and 110 V split phase in other parts, just like how some languages are written in letter-scripts and others are written using ideograms, it makes no difference whatsoever, unless moving from one system to the other. The real question is:

> "why can't we all just get along?"

Or in other words: **why do standards emerge only after two or more groups have already made a big investment in different schemes?** That is the subject of a larger course.


---

### Answer by username_4 on 2018-01-11. Score: 1

Mabye something here will be of use...
Little-endian means the lowest byte address holds the least significant bit (and byte).  Big-endian means the lowest byte address holds the most significant bit (and byte).
So, Little = Lowest Least.
And Big is the other one...
There are multiple possible ways because storing (and retrieving) a word in multiple bytes is a form of serialization & deserialization — breaking down one large object into smaller chunks and vice versa.  These processes are inherently order sensitive by nature as each smaller chunk has a different specific placement within the larger.
Further, since the smaller sized chunks (here bytes) adds up to the same bit count as that of the larger item (here words), the arrangement of the ordering must be prescribed in advance (and otherwise it would take additional bits to indicate the order or encoding scheme (not to mention the additional logic to handle that)).
Two of those ways are fairly obvious: lowest least and lowest most.  In both those schemes, the address of a word is the lowest address of all of the bytes used in storing the word.  Given this addressing constraint, there are only two schemes for storing a 16-bit value in 2-bytes, though there are more permutations of byte order for storing a 32-bit value in 4-bytes.  
(Further, we might also consider that the address of a word is the address of the highest address therein, which would give rise to additional schemes, but these would give up the desirable property that word aligned addresses are even.)
In human terms we can write text left-to-right or right-to-left, or top-to-bottom or bottom-to-top, etc...  We can relate these various schemes to lower-to-higher addresses (maybe even to higher-to-lower addresses).
I consider that humans do little-endian for numbers when we line them up e.g. for long arithmetic, though right-to-left instead of lower-to-higher.  When we need larger numbers we expand digits to the left, anchoring the least significant digit in the same column; little endian pointer addresses point to LSBs regardless of the size of the data type.
By  contrast, to get more digits, big-endian shifts the number over to higher addresses in order to insert more digits at lower addresses (rather odd IMHO).  So, the byte at the address for a word points to an MSB.
  Human    Little-Endian   Big-Endian
    92       29               92
+  910       019              910
 -----       ----             -----
  1002       2001             1002

You can see that little-endian (here shown with addresses increasing left-to-right) is mirror image of human.
Another approach I use is to show addresses on the right side of a word-sized dump for little endian.
 words      address
xxxxxxxx  <- 0000
xxxxxxxx  <- 0004
xxxxxxxx  <- 0008
xxxxxxxx  <- 000C

> **Comments:**
> **username_5**: Quite similar, but I tend to use little endian = little end first, big endian = big end first. Seems to stick with the people I have explained it to.  

---

### Answer by username_6 on 2018-01-11. Score: 1

TL;DR Items are numbered (indexed). For big-endian, start the count with the most significant item and work toward the least. For little-endian start with the least significant item and work toward the highest.

The [Wikipedia page](https://en.wikipedia.org/wiki/Endianness) and the post by user [Erik Edit](https://cseducators.stackexchange.com/a/4160/1293) provide good technical details, but I'd rather give a memorable "picture" of what is going on.

First, if you only work on one computer architecture then *endianness* is automatic and of little consequence. It is when you need to transfer data from one system to another (if they have different architectures) that it matters. An early story is that in attempting to send "Unix" from one machine to another, "nUxi" showed up at the other end.

Suppose that you have a large group of "marchers" (bits) in a "field" (system memory). Suppose that you want to send them all to another field, but they must pass one at a time through a "hallway" (bit stream) to another field that may be organized differently. Each field has an "organizer" (architecture) that knows something about the organization (duh) of that field.

## Simplest case: one level organization

We will first consider the simplest case of a single level of organization at each end with some similarities between them as described below.

In each field, the marchers are organized into "squads" of, say, 8 marchers per squad (note it is the same at both ends, one of the simplifications for now). Each squad has a leader (most significant bit), though the leader isn't marked in any way. The leader looks like any other marcher, but when the squad lines up the leader is always to the left. Since the marchers aren't very smart (just "bits", remember), the organizer of a field will help them arrange themselves by instructing the members of the squad to each stand in a numbered location on the field. The locations for the members of an individual squad are numbered 0 through 7.

A field can be big-endian (think the big end of an egg), in which the leader of a squad stands on location 0 for that squad, with the other members arranged to its left. The last member (the least significant member) will be on slot 7.

Alternatively, a field can be little-endian (eggs again), in which slot numbers are reversed so that the leader of the squad is still to the left, but on this field that slot is number 7 so that the least significant marcher (bit) winds up in slot 0.

It is really only the field organizer that is responsible for the relative arrangement of the slots. If you look at a squad (or the whole field) ignoring those, a big-endian squad and a little-endian squad will look the same, with the leader to the left.

Now, however, one desires to move the marchers on a field to another field. Since this happens a lot, the "association of organizers" (standards groups) have decided that when going through a hallway (in single file), the leaders will go first, followed by the rest of its squad. It could have been the other way and there are a few places in which the rules aren't obeyed, but that leads to chaos so mostly the leader-first rule is used.

But it is the organizer of a field who must send marchers to the hallway and the organizer at the other end who must take marchers as they emerge from the hallway and line them up again.

Let's look at the sending organizer first. The organizer will "point" at a squad and then call off slot numbers for the movement of that squad to the hallway. If it is a big-endian field, then the organizer will count upwards from 0 to 7 for that squad, so that the leader (slot 0, remember) goes first and the rest follow, with the marcher in slot 7 going last for that squad. Other squads may follow as well, but we will come to that.

If the field is little-endian, however, the organizer simply counts downward from 7 to 0 instead. But this, again, sends the leader first.

Now we look at the other end of the hallway. The receiving organizer has to take the squads as they emerge and assign them to positions. A position has room for a squad, and it has numbered slots for the members as usual. If this field big-endian, the slots are, as usual numbered 0-7 left to right but if it is little endian the slots are numbered 7-0 left to right. So, the organizer at this end, takes marchers as they emerge from the hallway, and knowing that the leader of a squad will be first, just points to a location and counts off slot numbers appropriately. If this is a big-endian field, the organizer counts starting from 0, but a little-endian organizer will count downward from 7.

## Several levels

Suppose, however, that the situation is more complex. Suppose that each squad is part of a larger grouping, a "platoon". A platoon might consist of, say four squads, and they need to be treated for some purposes as a group. Again, the organizer of any given field needs to know things about that field, but as little as possible about other fields.

The biggest complication is that a field might be big-endian for squads, but little-endian for platoons (mixed endian). This is really only a complication for how you think of it, however. The organizer will do the right thing. We will assume here that the squads and platoons are organized the same. The squads of a platoon stand together (think a row) with one squad next to another. There will be four sets of squad-slots making up a platoon formation. Just like the numbering of the individual squad slots, the sets are numbered for the squads of a platoon. If the numbering from left to right is 0 through 3 then the platoon organization is big-endian. If it is 3 down to 0 it is little-endian. In all cases the squad to the left is the more significant squad and the one to the right is the least significant squad whatever the numbering.

Now, again, the organizer wants to send marchers through the hallway and will send the squads one after the other. The organizer knows the numbering of the platoon formation slots (0-3 or 3-0). So, to send a platoon through the hallway, supposing that we have big-endian throughout, the organizer first points to squad 0 (the most significant squad) and then counts off the marchers 0-7 as before. Squad 1 is sent next, etc, ending with the least significant squad (3). But if the field is organized little-endian at the platoon level, the organizer points to squad 3 as the start and counts off marchers, etc, ending with squad 0.

Note that in mixed endian there is no particular difficulty as long as the organizer knows what to do at any level. But, importantly, the most significant elements at any level are given priority. They will have low index number in big-endian and larger index numbers in little-endian organization at that level.

The situation at the receiving end is similar. The organizer there knows that the most significant squad in a platoon will come first and within a squad the leader will be first. So, having selected a place for the incoming platoon, the organizer points to what ever slot is reserved for the most significant squad (0 for big-endian, but 3 for little) and then counts off members either upward or downward depending on the appropriate ordering for that field. This will, of course be the left-most of the squad locations. The organizer then points to the next location and counts off the second squad, etc. At the end, the platoon is lined up just as before, though the indexes of the slots won't be the same for the fields at the two ends of the hallway.

## Even more complex: inconsistent squad and/or platoon sizes

I won't attempt a complete explanation here as there are too many possibilities. It may be that the organizers at the ends need some information about both fields, not just their own. I'll assume a single level of grouping here (squads), but higher levels (platoons) would be similar.

One common case is that you are sending a squad with say six members into a field in which squads have eight. The sending organizer can behave just as before, sending the leader first as usual, but counting from 0 to 5 or 5 to 0 depending on endianness. The organizer at the other end has a problem though. First it needs to know that only six marchers are coming per squad, with the leader first. It has to put the marchers into the eight slots. Normally (but not necessarily) the members would be placed so that the least significant member winds up in the least significant slot, with the two most significant slots left empty. This means that if the receiving field is big-endian, the leader of the squad winds up in slot 2, and if little-endian in slot 5.

Another variation is when the sending field has a squad length that is half the size of the squad length in the receiving field. Then the receiving field can do as just above, or can "pack" two of the incoming squads into a single squad section in this field. Keeping in mind that the squads come through the hallway most-significant-first, the first four-member squad would go to the left in the eight-marcher region and the second squad would go to the right. The slot numbers of course depend on the endianness, but the organizer just points to a place and counts off slot numbers as the marchers come through.

Sending from a field in which the squad sizes are larger than the receiving field is more complex and won't be described in detail here. But either some marchers get sent to the sidelines (unlikely but possible) or the incoming marchers will need to be distributed over more than one of that field's positions. The key to working out a proper protocol is that the marchers come through in most-significant-first at any level, though the organizer at the receiving end will need to know how to break up or combine the marchers into squads at that end. Remember, that all of the marchers look alike. There is nothing to distinguish any of them. The leader doesn't look anything different from any other marcher, nor is there any way to "mark" divisions between squads. That needs to be known to the organizer in advance.

---

We note for the record that some systems are *bi-endian* and can be organized (either in hardware or software) either big- or little-endian. At a given moment, they are one or the other, unless you want chaos to rule.

> **Comments:**
> **username_7**: "First, if you only work on one computer architecture then endianness is automatic and of little consequence" I have to disagree with that. When I write disassemblers on Intel which use little endianness and the code coming out is little endian and [Intel Architecture Software Developer Manuals](https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf)  make references in big endian, then not knowing this will ruin your day. Continued  
> **username_7**: I can't remember how much of a problem it was because after I figured it out I was able to abstract it away in a function, but for disassemblers of little endian processors I would not say "of little consequence" :)  

---

