1

How do you suppose to know that when 'mul ecx' was executed. ECX would be multiplied with EAX? And not with EBX or EDX?

mul ecx, eax

would make more sense though.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
user2453180
  • 131
  • 1
  • 2
  • 7
  • 4
    RTFM is how you know :) [Volume 2](http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html) – Hans Passant Jul 24 '13 at 01:30
  • 2
    It's due to a 25 year old, 32-bit extension of a 35-year old, 16 bit architecture. The Haswell architecture has a more 'modern' `mulx` instruction. – Brett Hale Jul 24 '13 at 02:29
  • if you look at some stack-based architectures or architectures with accumulated register, you'll see that the stack or accumulated register are almost always implied in the instruction. It's simply because the encoding for the instruction was not possible/not needed – phuclv Jun 20 '15 at 12:14
  • Your proposed `mul ecx, eax` syntax doesn't indicate the high half of the implicit output, EDX. – Peter Cordes Dec 23 '20 at 21:19

1 Answers1

4

The instruction set is simply defined that way.

Intel could have defined it in other ways, including ways that would have allowed you to completely specify input and output registers, but they did not.

The excuse is arguably that at the time the various multiply instructions were added to the instruction set of the CPU (8086 vintage, I think), that the existing instruction didn't have any obvious places to put multiply where it could share the general decoding scheme available to other instructions (e.g., mov, add, xor, etc), that there were not a lot of available transistors to do fancy decoding schemes to enable some other way to encode general operands, and that any transistors that were available were better dedicated to the multiplication/division logic.

Finally, the multiply instruction is needed rather less often than the general instructions (mov, add, xor) and so the effort to move the operands into place/results from fixed places doesn't cause a lot of code bloat or impact performance much. The designers did find a way to include a source operand. You should consider it lucky it wasn't simply defined as multiplying EAX and EDX to produce EDX:EAX, which is a time-honored scheme used in many earlier computer architectures. And the needs haven't changed much for integer multiply in the x86 instruction set since.

The floating point/vector arithmetic is an entirely different matter.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341