Writing a lunar lander game for an actual lunar lander
cowlark.com
cowlark.com
>"Division. Arrgh. The AGC does have hardware division (and multiplication), but it’s strictly limited to only being able to compute x/y when |x|>|y|. Anything else, you get garbage, including in the y=x case. This hit me several times and trying to deal with all the sign issues, combined with the 1s-complement sign issues above, was really painful."
Not being expert in slightly outdated processor architectures (1s compliment!), might someone more expert than I be able to tell me _why_ this is the case and was a good design decision? It seems like a potential way for unexpected sensor data to bite you in the arse...
If you're creating hardware that's only going to be used a few times, it's probably not worth it to spend a lot of effort into giving it every feature that programmers want.
I think it's literally just to keep the math circuit logic very simple, it'll be identical to MOD (just need to look at the remainder register) and |x| <= |y| will either require some hackery to convert it (with an appropriate test) or the machine having some idea of non-integer numbers.
For implementation of division, you could have the circuit equivalence of:
uint div(x, y){
uint t = x; //temporary (don't want to touch x)
uint c = 0; //counter
while(t >= y){
t = t - y;
c = c + 1;
}
return c; //remainder is in t
}
Of course there would be no checking, hence the garbage out when you misuse it. Your checking would be done manually.
It's a surprisingly modern-ish system, in many ways, and surprisingly weird in lots of other ways. One thing which really surprised me was a complete lack of pointer support: I managed to bodge the look-up-table instruction (which evaluates its argument and adds the result to the next instruction to be executed) to do pointer dereferences instead (INDEX ptr; TC 0). And, luckily, I found a way to make the assembler emit an address as a literal value, which it really didn't want to do.
It's a shame the address space is so small (only 12 bits!) or you could totally port real software to this...
And write up of Mike Stewart's approach to handling the async logic and propagation delays.