multiplication differences in HLA and gnu as
in [ASM]
|
Prev: Directly Reading/Writing to Disk
Next: remplace Ascii
From: Evenbit on 1 Apr 2008 20:37 On Apr 1, 2:55 am, Frank Kotler <fbkot...(a)verizon.net> wrote: > chno...(a)gmail.com wrote: > > On Mar 31, 11:03 pm, Frank Kotler <fbkot...(a)verizon.net> wrote: > > >>chno...(a)gmail.com wrote: > > >>>Hello :) > >>>I was using gas for a while with a syntax like that > >>>imull $5, %edx > >>>However, HLA does not accept the second operand > >>>imul (5, edx) > > >>Try "intmul (5, edx);" > > >>Alien syntax, y'know... > > >>Best, > >>Frank > > > Thank you very much! It works! > > If anyone has a clue why imul in hla is different from normal imul, > > please, let me know :) > > Well... "mul" does a 32-bit * 32-bit multiplication for a 64-bit result > (edx:eax). (Smaller sizes are available, too.) The one-operand form of > "imul" does the same thing, only signed. (HLA uses "imul" for this, > AFAIK) The three-operand form of "imul" does a 32-bit * 32-bit multiply, > and stores the result in 32-bits - any "overflow" is lost. The > two-operand form is just a special case of the three-operand form. So > there really *are* two different operations... > No matter how one wishes to classify things (syntax, operation, or encoding), I believe that "two" might be too low of a count. This is from the MASM v6.0 Reference book ( Microsoft Legal can bite a big one :) -- IMUL -- Signed Multiply Multiplies an implied destination operand by a specified source operand. Both operands are treated as signed numbers. If a single 16- bit operand is given, the implied destination is AX and the product goes into the DX:AX register pair. If a single 8-bit operand is given, the implied destination is AL and the product goes into AX. On the 80386/486, if the operand is EAX, the product goes into the EDX:EAX register pair. The carry and overflow flags are set if the product is sign-extended into DX for 16-bit operands, into AH for 8- bit operands, or into EDX for 32-bit operands. Two additional syntaxes are available on the 80186-80486 processors. In the two-operand form, a 16-bit register gives one of the factors and serves as the destination for the result; a source constant specifies the other factor. In the three-operand form, the first operand is a 16-bit register where the result will be stored, the second is a 16-bit register or memory operand containing one of the factors, and the third is a constant representing the other factor. With both variations, the overflow and carry flags are set if the result is too large to fit into the 16-bit destination register. Since the low 16 bits of the product are the same for both signed and unsigned multiplication, these syntaxes can be used for either signed or unsigned numbers. On the 80386/486, the operands can be either 16 or 32 bits wide. A fourth syntax is available on the 80386/486. Both the source and destination operands can be given specifically. The source can be any 16- or 32-bit memory operand or general-purpose register. The destination can be any general-purpose register of the same size. The overflow and carry flags are set if the porduct does not fit in the destination. ---- ENCODING 1111011w mod, 101, r/m disp (0, 1, or 2) IMUL reg (ex. imul dx) IMUL mem (ex. imul factor) ---- ENCODING 011010s1 mod, reg, r/m disp (0, 1, or 2) data (1 or 2) IMUL reg16, immed (ex. imul cx, 25) IMUL reg32, immed IMUL reg16, reg16, immed (ex. imul dx, ax, 18) IMUL reg32, reg32, immed IMUL reg16, mem16, immed (ex. imul bx, [si], 60) IMUL reg32, mem32, immed ---- ENCODING 00001111 10101111 mod, reg, r/m disp (0, 1, or 2) IMUL reg16, reg16 (ex. imul cx, ax) IMUL reg32, reg32 IMUL reg16, mem16 (ex. imul dx, [si]) IMUL reg32, mem32 Nathan.
From: Frank Kotler on 2 Apr 2008 04:59 Evenbit wrote: > On Apr 1, 2:55 am, Frank Kotler <fbkot...(a)verizon.net> wrote: > >>chno...(a)gmail.com wrote: >> >>>On Mar 31, 11:03 pm, Frank Kotler <fbkot...(a)verizon.net> wrote: >> >>>>chno...(a)gmail.com wrote: >> >>>>>Hello :) >>>>>I was using gas for a while with a syntax like that >>>>>imull $5, %edx >>>>>However, HLA does not accept the second operand >>>>>imul (5, edx) >> >>>>Try "intmul (5, edx);" >> >>>>Alien syntax, y'know... >> >>>>Best, >>>>Frank >> >>>Thank you very much! It works! >>>If anyone has a clue why imul in hla is different from normal imul, >>>please, let me know :) >> >>Well... "mul" does a 32-bit * 32-bit multiplication for a 64-bit result >>(edx:eax). (Smaller sizes are available, too.) The one-operand form of >>"imul" does the same thing, only signed. (HLA uses "imul" for this, >>AFAIK) The three-operand form of "imul" does a 32-bit * 32-bit multiply, >>and stores the result in 32-bits - any "overflow" is lost. The >>two-operand form is just a special case of the three-operand form. So >>there really *are* two different operations... >> > > > No matter how one wishes to classify things (syntax, operation, or > encoding), I believe that "two" might be too low of a count. Quite right! I *did* mention "smaller sizes are available"... should have said "other sizes", since we've got 64-bit ops to deal with, these days. Also "signed byte" forms, in the case of an immediate... Trying to make it "as simple as possible, but no simpler". I may have aimed low. I was just "making excuses" for HLA calling "imul" and "intmul" by different names. It *does* make sense, in a way. It makes sense, in a way, to "do it like the Intel doc says", too (despite Herbert's legitimate observations that it isn't "logical"). I may have mentioned that I think HLA syntax is a mistake from "begin" to "end"... inclusive. I find it "weird" that Randy was disappointed that Nasm wasn't "true Intel syntax" (which it isn't)... and then he writes *this* thing! But that's the nice part of being a programmer - you can do it any damn way you want to! Just a "freak accident" that I knew the "intmul" secret. I understand there *is* a manual... Best, Frank
From: Betov on 3 Apr 2008 11:33 Frank Kotler <fbkotler(a)verizon.net> �crivait news:1WHIj.3710$yd2.1182 @trndny04: > I may have mentioned that I think HLA syntax is a mistake from "begin" > to "end"... inclusive. I find it "weird" that Randy was disappointed > that Nasm wasn't "true Intel syntax" (which it isn't)... and then he > writes *this* thing! No problem: For an HLL, one is allowed to do what he wants with the syntax. :) Betov. < http://rosasm.org >
From: Herbert Kleebauer on 3 Apr 2008 17:37 Betov wrote: > > I may have mentioned that I think HLA syntax is a mistake from "begin" > > to "end"... inclusive. I find it "weird" that Randy was disappointed > > that Nasm wasn't "true Intel syntax" (which it isn't)... and then he > > writes *this* thing! > > No problem: For an HLL, one is allowed to do what he wants > with the syntax. What has this to do with HLL? The CPU defines the machine language and the assembler defines the assembler syntax. And any modification of the "Intel syntax" can only mean an improvement.
From: Wolfgang Kern on 4 Apr 2008 12:45
Nathan "Evenbit" mentioned: [about syntax issue of the several forms ...] Yeah, it seems to be hard for most tools to distinguish between f6.. IMUL byte r/m ;AX=Al*r/m f7.. IMUL r/m ;(e)dx:(e)ax = (e)ax * r/m16(32) ;the two above can't overflow and the more rare seen: 0f af .. IMUL r,r/m16(32) ;overflow ignored! beside the three operand variant: 69/6b .. IMUL r,r/m,SXimm8/s16(s32) ;overflow ignored! so it needs any kind of syntax-decision, and I'd go for the NASM/FASM-way, and just decide by stated operands single operand: F6/F7 .. IMUL .. two operands: 0F AF .. IMUL ..,.. three operands: 69/6B .. IMUL ..,..,.. and fast forget about any additional terms which may be more confusing than telling, as already seen in macro-names like INTMUL/IMULREG/INTMULRRM_IMM ... __ wolfgang |