Re: newbie: MUL product

On Thu, 29 Mar 2007 20:49:17 GMT, Frank Kotler <fbkotler@xxxxxxxxxxx>
wrote:

Brian wrote:
On Thu, 29 Mar 2007 19:16:31 +0200, Herbert Kleebauer <klee@xxxxxxxxx>
wrote:


Wolfgang Kern wrote:


or the immediate operand IMUL forms:

anyreg32=anyreg/mem32 * SXimm8/imm32

ie: IMUL eax,ebx,-09

(unfortunately no unsigned MUL in this forms)

Maybe you should use an other assembler which allows
you to define the alias MUL for this IMUL instruction.
Or directly code it in HEX, if you use uppercase letters,
the CPU does an unsigned multiply (try it and you will
see it works):

00000000: 69 c3 fffffff7 muls.l #-9,r3,r0
00000006: 69 C3 FFFFFFF7 mulu.l #4294967287,r3,r0


Thanks Herbert, but to switch to another assembler would seem
counter-productive for me at this point, as I'm a complete newbie, and
I mainly want to learn "one" assembler at this point.

Good plan!

I gather from a few of your posts that you feel all assembly
programmers should learn machine code?

The truth of the matter is that we've gotten ourselves into such a
fucking "Tower of Babel" situation that machine code is about the only
way we can communicate! Unlike C, which has "standards" to say what's C
and what's not, asm is less authoritarian and more flexible. This is
nice. I like Nasm - the syntax isn't quite the same as Masm/Tasm (almost
the same), but I *like* the changes. Herbert doesn't like Intel syntax -
feel's it's illogical, and his 68K-style syntax is more logical and more
regular. He may be right. He can do it that way, and does. Everybody can
have the syntax he/she wants. But there's a price to pay!!!

Interesting what you say about the caps. While I didn't code this in
Hex, I did take a look at the dissassembly, and mine appears to use
different opcodes for mul and imul. Maybe that's a Motorola's 68k
assembly implementation that works for you?

I don't know if Herbert's jokin' or tripin', but in this case you
shouldn't take his comment seriously. The CPU does not know what "case"
the bytes are in, I assure you! (normally, you *can* trust what Herbert
says - in spite of... maybe because of... his weird syntax, he knows his
stuff)

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! :)


Thanks Frank. I saw that you commented on the same post in CLAX
(sorry for the cross-post). 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?

If I understood the comment above correctly, you indicated that
writing ax to memory will write al then ah. 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?
--
thanks,
Brian
To the best of my knowledge, I have:
1) asked a question specifically related to this newsgroup
2) not used my email to request answers be sent there
3) not top-posted
4) not used bad grammar that would make me appear more stupider
.

Quantcast