4 ms·

I don't think that really forced any particular endianness. Endianness is only really a thing if there's addressable memory, which is not the case for a bit st

I don't think that really forced any particular endianness. Endianness is only really a thing if there's addressable memory, which is not the case for a bit stream. Whether a system is big/little/mixed-endian was only a question of how the address lines are set for multi-byte accesses.

tomxor 7y ago
I thought that too at first, but then I found this stack-overflow answer fairly convincingly confirming the OPs claim with quotes from it's designers: https://stackoverflow.com/a/36263273 https://stackoverflow.com/a/36263273 although it's still not explicitly clear why. > Shustek: So, for example, storing numbers least significant byte first, came from the fact that this was _serial_ and you needed to process the low bits first. > Poor: You had to do it that way. You had no choice. I'm wondering if it was the bit order that mattered for compatibility with the 1-bit serial processor of the Datapoint 2200, and if that determined byte ordering of it's 16bit successor?... I don't know much about 1-bit computing, but if you think about it - to be useful, it must be capable of doing operations on arbitrary length words (within some reasonable limitation), i.e not limited to 8 bits like the 8008. So maybe this put it in a funny position: while byte endianess makes no sense and bit endianness seem to make no difference for the 8008 since it was 8bit; it did make a difference to the datapoint which was serial 1-bit and could operate through the 8bit word boundaries. To be clear what i mean, imagine how a 1-bit ALU would process 16 bits, it would want them in order like this (the bits are in logical order, not numerical order): (8bit) Little Endian: byte 0000000011111111 bit 0123456789abcdef But not like this: (8bit) Big Endian: byte 0000000011111111 bit 76543210fedcba98 I don't know if this is correct, and i'm assuming here that bit endianness must determine byte endianness in the 16bit 8086. Clarification/correction is most welcome.
- Gibbon1 7y ago
  Assume you are adding two words one bit at a time with one bit of storage for the carry. You can do that with LE but not BE.
  - tomxor 7y ago
    Can you please give a bit more detail? what I don't quite understand is why it would be a problem to do so in reverse bit order? I'm assuming you are saying it's not about word boundaries? that was just my guess, but is it correct that bit order does matter?
    - JoeAltmaier 7y ago
      The carry between bytes can be applied as-you-go with LE but has to be done after with BE. Which would double the execution time (adding zero/1 to each byte of the result).
    - Gibbon1 7y ago
      When you add two binary numbers the simplest method for handling the carry is a ripple carry. The carry bit ripples up from lsb to msb. If you're trying to build a simple 1 bit ALU you only need to save the carry bit as long as you add the bits from least significant to most. if you do it the reverse you have an intermediate result that needs to be saved. One bit ALU adds like a0 + b0 => r0 + carry0 a1 + b1 + carry0 => r1 + carry1 a2 + b2 + carry1 => r1 + carry2 ... an + bn + carry(n-1) => r1 + carryn As you can see you only need to keep the carry bit. The result bit gets written back to memory immediately. What's going on is a 1 bit processor represents the most extreme trade off between gate count and speed for a given functionality. AKA low gate count but requires many clock cycles per operation.
      - tomxor 7y ago
        > as long as you add the bits from least significant to most Thanks, although I already understood what you explained, this bit made me realize more clearly the detail I was tripping up on. I was never imagining the 1-bit adder to start anywhere _but_ the LSB, what I couldn't figure out was why it couldn't simply iterate the bits in reverse logical order for big endian... I'm guessing there is a good reason why serial processors can't read a sequence of bits in reverse logical order, and it probably applies to modern CPUs too? either that or it's a design choice that cannot be dynamic. I should probably pick a book up at this point, thanks for answering my questions.

tomxor 7y ago

I thought that too at first, but then I found this stack-overflow answer fairly convincingly confirming the OPs claim with quotes from it's designers: https://stackoverflow.com/a/36263273 https://stackoverflow.com/a/36263273 although it's still not explicitly clear why. > Shustek: So, for example, storing numbers least significant byte first, came from the fact that this was _serial_ and you needed to process the low bits first. > Poor: You had to do it that way. You had no choice. I'm wondering if it was the bit order that mattered for compatibility with the 1-bit serial processor of the Datapoint 2200, and if that determined byte ordering of it's 16bit successor?... I don't know much about 1-bit computing, but if you think about it - to be useful, it must be capable of doing operations on arbitrary length words (within some reasonable limitation), i.e not limited to 8 bits like the 8008. So maybe this put it in a funny position: while byte endianess makes no sense and bit endianness seem to make no difference for the 8008 since it was 8bit; it did make a difference to the datapoint which was serial 1-bit and could operate through the 8bit word boundaries. To be clear what i mean, imagine how a 1-bit ALU would process 16 bits, it would want them in order like this (the bits are in logical order, not numerical order): (8bit) Little Endian: byte 0000000011111111 bit 0123456789abcdef But not like this: (8bit) Big Endian: byte 0000000011111111 bit 76543210fedcba98 I don't know if this is correct, and i'm assuming here that bit endianness must determine byte endianness in the 16bit 8086. Clarification/correction is most welcome.

Gibbon1 7y ago
Assume you are adding two words one bit at a time with one bit of storage for the carry. You can do that with LE but not BE.
- tomxor 7y ago
  Can you please give a bit more detail? what I don't quite understand is why it would be a problem to do so in reverse bit order? I'm assuming you are saying it's not about word boundaries? that was just my guess, but is it correct that bit order does matter?
  - JoeAltmaier 7y ago
    The carry between bytes can be applied as-you-go with LE but has to be done after with BE. Which would double the execution time (adding zero/1 to each byte of the result).
  - Gibbon1 7y ago
    When you add two binary numbers the simplest method for handling the carry is a ripple carry. The carry bit ripples up from lsb to msb. If you're trying to build a simple 1 bit ALU you only need to save the carry bit as long as you add the bits from least significant to most. if you do it the reverse you have an intermediate result that needs to be saved. One bit ALU adds like a0 + b0 => r0 + carry0 a1 + b1 + carry0 => r1 + carry1 a2 + b2 + carry1 => r1 + carry2 ... an + bn + carry(n-1) => r1 + carryn As you can see you only need to keep the carry bit. The result bit gets written back to memory immediately. What's going on is a 1 bit processor represents the most extreme trade off between gate count and speed for a given functionality. AKA low gate count but requires many clock cycles per operation.
    - tomxor 7y ago
      > as long as you add the bits from least significant to most Thanks, although I already understood what you explained, this bit made me realize more clearly the detail I was tripping up on. I was never imagining the 1-bit adder to start anywhere _but_ the LSB, what I couldn't figure out was why it couldn't simply iterate the bits in reverse logical order for big endian... I'm guessing there is a good reason why serial processors can't read a sequence of bits in reverse logical order, and it probably applies to modern CPUs too? either that or it's a design choice that cannot be dynamic. I should probably pick a book up at this point, thanks for answering my questions.