Reverse-engineering the multiplication algorithm in the Intel 8086 processor
righto.com
righto.com
If you interpret the arguments as unsigned, you can treat the input high bits as zeroes. But if it's signed then you need to conceptually sign-extend the high bit. So they're different operations with different results in the high word.
[1] There was an 8 bit multiply too. It didn't have this property and looked more like a normal instruction, kens would have to tell us if it shared the same microcode.
> It didn't have this property and looked more like a normal instruction, kens would have to tell us if it shared the same microcode.
If you're thinking of "IMUL reg,reg" it was added only in 80186. If instead you're thinking of AAD, then yes it reuses the CORX subroutine; it's only unsigned so it doesn't need the parts that deal with negation.
Until today, I don't believe I ever even realized that AAD could be used to perform a (non-widening) 8 bit multiplication by an immediate. Thanks for the reference.
These instructions were also implemented in PMA, the Prime Macro Assembler, in the OS so that if a machine didn't have these instructions, a UII fault occurred and the instruction was simulated in software. I implemented a lot of the easier instructions in C in the Prime emulator, but for the more complex things like decimal math, I let those fault so the Prime OS would handle them.
Thanks!
170 Q -> tmpc
171 AH -> tmpb CALL CORX
172 AL -> tmpb ADD tmpc
173 ZERO -> AH JMP 179
179 SIGMA -> AL RNI
F
So take it with a grain of salt when you hear someone claim that RISC is invariantly superior to CISC. Times and times again, the truth lies somewhere in the middle.
If you really need integer division, you can typically optimize it by doing a FP iteration and then fixing up the approximate result.
Integer division is still on the slower side operations on the machines, but the advice to avoid division at all costs is outdated. In comparison, the FP divide instructions are in the ~13/14 cycles, it would be hard for you to shuffle data to that side and back and not be slower. (And no, they are not doing this internally -- both have separate integer divide units.)
I don't think hardware multiplication is a RISC or CISC thing. The "reduced instructions" that RISC is concerned with chiefly involve code flow mechanisms such as linkage, flag behavior, and interfacing with memory. It doesn't mean you need to create all your math operations from increment and bitwise instructions.
The RISC/CISC thing stopped being meaningful once ...
A) processors went all-in on out-of-order execution (this means everything was split into uops and reordered and your instruction stream no longer represents what the CPU does much of the time)
B) processors started having parallel vector instructions.
An article was posted here on HN making the case for considering "Out of Order" a new paradigm and it made a lot of sense to me.
MUL and DIV instructions are not exactly transistor count friendly, so they caused an expected contradiction at the RISC camp back in the day.
Yes. That's why it has become more and more ridiculous to claim that C is 'close to the metal'.
one i could take with me on a holiday and return having every transistor accounted for (and probably foolishly assuming i finally understand how the wretched thing works!)