Re: newbie: MUL product

Brian wrote:

....
There really are different opcodes for "imul eax, ebx, -9"...

00000000 69C3F7FFFFFF imul eax,ebx,dword 0xfffffff7
00000006 6BC3F7 imul eax,ebx,byte -0x9

... but I don't think that's what Herbert was getting at. These both do a signed multiply - it's just a different way to write "-9". I don't know *what* Herbert was getting at! I can't figure out how to write a lowercase "3" to try it! :)

Okay, Herbert was joking about the "case" part. But I think he was making a point about why his syntax is "better" than Intel's...

imul ebx

will multiply eax by ebx, and store the result in edx:eax - just like "mul ebx", except signed - and in this case it *does* make a difference. "mul", and "imul" in its one-operand form, can use an 8-bit register as it's operand. The two- and three-operand forms of "imul" use 16- or 32-bit registers only.

imul eax, ebx

Multiplies eax by eax and stores the result in eax.

imul eax, ebx, -9

Multiplies -9 (0xFFFFFFF7) by ebx and stores the result in eax. There's a "dword" form and a "signed byte" form to this one. They differ only in the way the immediate operand is *stored" - 0xFFFFFFF7 or just 0xF7. In the latter case, the byte is sign extended to 32 bits before the multiply is performed. (the "signed byte" forms of instructions don't have any zero-extended eqivalents)

When I wrote "They both do a signed multiply", I was thinking "but it doesn't make any difference". Herbert made this point clear.

I won't bore you with opcodes - there are a bunch of them. Herbert's syntax includes more information in the "opcode name", so once we've learned his notation(!), we can see more of what the opcode will be without looking at the operands. This is where the information "logically belongs", one might argue...

Intel syntax wants to give us fewer mnemonics to learn. We just say "imul" in every case, and let the assembler figure out which opcode from the operands. If *we* care which opcode, *we* need to figure it out from the operands, too. In some cases ("inc [esi]"), we need to tell the assembler "inc byte [esi]" or "inc word [esi]" or "inc dword [esi]". Herbert's "inc.b", "inc.w", and "inc.l" put the information "where it belongs". In the case of "muls.l" and "mulu.l"... since they generate the same opcode... logic fails me... :)

Thanks Frank. I saw that you commented on the same post in CLAX
(sorry for the cross-post).

Not a problem. In general, if you wanted to ask the same question in multiple newsgroups, you'd "cross-post" - put all the newsgroups in the "To:" field. This way, readers in all newsgroups can see all replies, and won't be bothered duplicating something you've already been told in another newsgroup.

In the case of a.l.a. and c.l.a.x. however, readers of c.l.a.x. don't *want* to read some of the replies that will (probably) appear in a.l.a.! That's why c.l.a.x. was *created* - by *vote* - from c.l.a. as a moderated group! In this case it's better to "multi-post" - different messages to different newsgroups, as you've done.

There's another issue with "cross-posting" to a.l.a. and c.l.a.x. - the appearance of the post in a.l.a. is delayed (as is expected in the moderated group), and sometimes the "From:" field is "de-spammed" even in the a.l.a. post. I don't know why this happens - seems like a "bug" to me. The "workaround" is separate messages... as you've done.

Here's your comment about Endian order:

----------------------------------------------begin Frank-------
If you're storing it in memory, don't forget little-endian!

mov [result], ax ; al at [result], ah at [result + 1]
mov [result + 2], dx ; dl at [result + 2], dh at [result + 3]
...
mov ebx, [result]
----------------------------------------------end Frank--------

Is little endian storage done on a byte by byte basis, a word by word
basis, or dword by dword?

Byte by byte. Note that when we write a number as hex, each two digits represent a byte. A single digit represents a nibble, and these are *not* reversed! So it goes in "pairs of digits" if you want to look at it that way.

mov eax, 12345678h
mov [myvar], eax

looking at "myvar" in memory:

78 56 34 12

(note that if we wrote it as "mov eax, 305419896" (decimal), the result would be exactly the same, but it would be a lot harder to see which byte goes where - which is why we like hex :)

If I understood the comment above correctly, you indicated that
writing ax to memory will write al then ah.

Right. To be perfectly clear, "then" means "after, in memory address", not "after, in time". (that's probably overkill)

Then, writing dx to the
same memory address (+ 2), will write dl, then dh. So that makes me
think that endian order is a byte by byte basis in memory, but all I
have to be concerned about is writing the low "register" first and the
high "register" last.... the processor will flip the bytes in the
individual registers automatically. Sound right?

Yeah, sounds like you've got it. In many cases, we don't need to care...

mov [myvar], eax
....
mov ecx, [myvar]

The number *is* stored in little-endian order, but we don't need to "do" anything about it. But, for example, "standard byte order" over the internet is big-endian. If we want to send a multi-byte number, we need to know that our most significant byte is at [myvar + 3] if it's a dword, or [myvar + 1] if it's a word. (if it's a byte, it obviously doesn't matter). And storing dx:ax, it matters... and I think that's where I came in...

Best,
Frank
.

Relevant Pages

  • Re: Question about jumps
    ... multiplies that value by two. ... covering the shift instructions. ... // Read integer from stdin into EAX. ... learn all the stuff needed to write your own integer input and output ...
    (alt.lang.asm)
  • Re: imul vs mul
    ... "mov eax, 69609 ... edx:eax = edi * eax ... it seems "imul" can do both signed and unsigned correctly since on the low ... EDX/RDX should not differ, since the general operation is the same either ...
    (alt.lang.asm)
  • Re: shuffling bits
    ... Swizzle A -> edx inserting 0s ... ; Trashes eax, ecx ... Here's how to do it with multiplies: ...
    (comp.lang.asm.x86)
  • Re: Who said registers are born equal ?
    ... >> Just about doing everything to eax is faster and shorter than the ... >> Including adds, subtracts, multiplies and divides... ... > and multiplies via eax too, which destroy edx ... > mov edx 30 ...
    (alt.lang.asm)
  • Re: imul vs mul
    ... "mov eax, 69609 ... edx:eax = edi * eax ... it seems "imul" can do both signed and unsigned correctly since on the low ...
    (alt.lang.asm)