4 ms·

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

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

by tomxor 7y ago

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.