I don't worry about how my ALU represents numbers internally or whether it's wired up the best way possible. Nothing I can do about it. I program 'em. I don't fix 'em.
in fact, you do care about it, you cannot do otherwise, the way its represented internally DOES affect the way you program it, and thats all i was saying, and thats what you dont seem to grasp.
you would be true if you only did add sub mul div without knowing how its represented.
but look at ultrano s code.
it DOES have some ands, some decs and some negs, and it DOES make assumptions on what a particular bit means, and it DOES use it to decide what action must be taken, and it DOES rely on the fact its 2 complemeted, and it DOES give the result in a 2 complement form, for use with later instructions.
if things were sign/ampl, it would be simpler for a programmer (" i only program them", huh?) to do what he wants and although it is still possible to do what you want, something like
"calculate the quotient and remainder of a signed division by 4 when the dividend is between -210 and 9 "
isnt something trivial for someone experimented like ultrano, let alone myself.
with sign amplitude, its more obvious i think.
thats all.
The round off was not an error. It was probably not the right selection he intended. The FPU gives you 4 different rounding methods of which rounding toward minus infinity is included. You can round anyway you want in twos complement if you program it that way, so the shuttle is safe. Ratch
i m not talking about the fpu here, and anyway, although i m not sure about how its handled internally, it might well be that it works like i said, simce the external convention IS sign-ampl (no?)
I feel happy about the way x86 cpus work, - bytes can get nice values, floats are using 4 bytes so we don't think about losses there, and the transition of 0 to -1 being 00000000 to 11111111 is absolutely logical - decrementing a D-trigger counter does exactly this. Currently I'm a little tired so I can't remember exactly the schematic of backward-counter but a forward-counter with inverted outputs explains it too.
But even if the other way is better, we can't change x86 since it's a standard that is too hard to remove :) It's all been decided long before I was born :grin:
But even if the other way is better, we can't change x86 since it's a standard that is too hard to remove :) It's all been decided long before I was born :grin: