flat assembler
Message board for the users of flat assembler.

 Index > Main > multiplying signed and unsigned integer
Author
vivik

Joined: 29 Oct 2016
Posts: 671
vivik
When you need to multiply two unsigned integers, you use mul.

When you need to multiply two signed integers, you use imul.

But to multiply a signed and an unsigned integer, which should you use?

Also, which kind of integer you use more often, signed or unsigned? Where do you use each?
21 Apr 2017, 19:24
bitRAKE

Joined: 21 Jul 2003
Posts: 3446
Location: vpcmipstrm
bitRAKE
vivik wrote:
But to multiply a signed and an unsigned integer, which should you use?
Do some range checking on the unsigned number and then use IMUL?
Quote:
Also, which kind of integer you use more often, signed or unsigned? Where do you use each?
I mostly use unsigned because I only use signed if required. Even when working with small ranges of numbers, I like to leave open the option of using negative numbers for something else in the future. Usually, some form of simple range checking. On rarer occasions I will also not use zero for the same reason. Really depends on the problem.

_________________
21 Apr 2017, 22:05
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 18731
revolution
vivik wrote:
But to multiply a signed and an unsigned integer, which should you use?
Convert the unsigned value to signed of the next size and use signed IMUL.
vivik wrote:
Also, which kind of integer you use more often, signed or unsigned?
Asking about the popularity is not the right question here. Use what makes sense in the application you are working on.
21 Apr 2017, 23:46
Furs

Joined: 04 Mar 2016
Posts: 1839
Furs
BTW you can use imul for unsigned multiplications unless you need the upper half.

The lower half (i.e. 32-bit x 32-bit -> 32-bit lower half result) are the same whether you use mul or imul. There's a difference only if you are interested in the upper half.
22 Apr 2017, 11:16
vivik

Joined: 29 Oct 2016
Posts: 671
vivik
I'm confused by the result of division. Any idea what happened here?

MOV EAX,-5
XOR EDX,EDX
MOV ECX,-2
; eax fffffffb
; ecx fffffffe

IDIV ECX
; eax 80000003 ;why?
; edx 1

MOV EAX,-5
XOR EDX,EDX
MOV ECX,-2
; eax fffffffb
; ecx fffffffe

DIV ECX
; eax 0 ;why?
; edx fffffffb
22 Apr 2017, 12:59
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 18731
revolution
IDIV:
EDX:EAX = 0x00000000fffffffb = +4294967291
ECX = 0xfffffffe = -2

Result = 0x80000003 = -2147483645

CPU is Correct

DIV:
EDX:EAX = 0x00000000fffffffb = +4294967291
ECX = 0xfffffffe = +4294967294

Result = 0x00000000 = 0

CPU is Correct

Explanation: I suspect you want to use cdq instead of xor edx,edx.
22 Apr 2017, 13:10
vivik

Joined: 29 Oct 2016
Posts: 671
vivik
Thanks!

Hope I don't annoy you too much.
22 Apr 2017, 13:44
vivik

Joined: 29 Oct 2016
Posts: 671
vivik
Never seen an integer overflow before, didn't knew this exception existed.
22 Apr 2017, 14:13
vivik

Joined: 29 Oct 2016
Posts: 671
vivik

I know it's possible to add or substract 64- 96- or 128-bit numbers on 32-bit processor with the use of flags. But is it possible to multiply or divide them? This is probably a math question.

After I learned that div can cause exception if you put something weird in edx, I probably never going to divide a 64-bit number(, unless I know that it's safe).

23 Apr 2017, 10:12
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 18731
revolution
vivik wrote:
I know it's possible to add or substract 64- 96- or 128-bit numbers on 32-bit processor with the use of flags. But is it possible to multiply or divide them?
You can't directly divide them. There are methods available that use DIV as the first approximation. Barrett and Montgomery are to most commonly used methods IME, but a bit of searching will reveal many other methods.

You also can't directly multiply them. But a basic long multiply (like you learned in school) can be used. And for larger numbers things like Karatsuba and FFT can be a win.
23 Apr 2017, 10:21
Furs

Joined: 04 Mar 2016
Posts: 1839
Furs
For multiplying/division of large 64-bit numbers on 32-bit mode (or for dynamic range) you should try and use the x87 FPU with the 80-bit precision if you can (unless you require even higher results). You can store any 64-bit integer exactly in one 80-bit FPU register and all operations can be done exact (in terms of 64-bit integer results) as long as you require only 64-bits of integer precision, and multiplying them is a matter of multiplying their significands (normal 64-bit x 64-bit multiply) and adding their exponents.

Make sure the FPU control word is set appropriately to use all 80-bits of precision because some stupid OS like Windows sets it to 64-bit only. (you can easily change it with asm)

Obviously I don't think it will work without precision loss if you need a number larger than 64 bits in the result (unless they have a certain multiple of a power-of-2 each, then you get extra precision bits due to increased dynamic range), but since it's floating point its dynamic range will be huge.
25 Apr 2017, 18:21
fasmnewbie

Joined: 01 Mar 2011
Posts: 555
fasmnewbie
Furs wrote:
For multiplying/division of large 64-bit numbers on 32-bit mode (or for dynamic range) you should try and use the x87 FPU with the 80-bit precision if you can (unless you require even higher results). You can store any 64-bit integer exactly in one 80-bit FPU register and all operations can be done exact (in terms of 64-bit integer results) as long as you require only 64-bits of integer precision, and multiplying them is a matter of multiplying their significands (normal 64-bit x 64-bit multiply) and adding their exponents.

No. F80 is good only for 18 significant digits. So representing max 0xffffffffffffffff (20 digits) with F80, will give you inexact result due to exponentiation.

Secondly, FPU and the general registers use different kind of overflow exceptions and flags. What may seem to be overflow in integers, may look fine in SFLAG register of the FPU.

Thirdly, signmess in FPU and general registers are interpreted quite differently. 0 and -0.0 may give you trouble.

Next, FPU involves other kind of exceptions such as NaN (QNaN and SNaN) which is not relevant to integer operations but do affect the results and the entire operations.

Finally, 80-bit precision is only good as far as 63 mantissa bits. In contrast to integers (2^64 - 1).

So either in 32-bit or 64-bit CPU, using FPU 80-bit precisions to represent a 64 integer is not smart in any way.
25 Apr 2017, 21:20
Furs

Joined: 04 Mar 2016
Posts: 1839
Furs
fasmnewbie wrote:
No. F80 is good only for 18 significant digits. So representing max 0xffffffffffffffff (20 digits) with F80, will give you inexact result due to exponentiation.
Sorry but that's bullshit, you speak in decimal which is an approximation and has nothing to do whatsoever with binary representation.

fasmnewbie wrote:
Secondly, FPU and the general registers use different kind of overflow exceptions and flags. What may seem to be overflow in integers, may look fine in SFLAG register of the FPU.
Yeah, this is valid, but I never spoke about overflow flags though; I mean, it's same as not using upper half of a wide integer multiplication, which is the more common case. If he needs proper overflow detection then you are right, of course.

fasmnewbie wrote:
Thirdly, signmess in FPU and general registers are interpreted quite differently. 0 and -0.0 may give you trouble.
Huh?

-0.0 converted back to integer is 0, no issue at all. What trouble are you even speaking of. Multiplication by -0 is also 0 result (or -0, but again, when you convert it back when done, it's not an issue).

fasmnewbie wrote:
Next, FPU involves other kind of exceptions such as NaN (QNaN and SNaN) which is not relevant to integer operations but do affect the results and the entire operations.
How are you going to get those things if you perform integer operations...? Other than dividing by 0, which is an exception in integer division anyway, and needs special care.

Obviously you can do weird floating point math and prove me wrong, but that's beside the point. You cannot do those with integer operations, so why even think about them? In these cases it's "wrong result" vs "impossible code" (with integers) so it's still better.

fasmnewbie wrote:
Finally, 80-bit precision is only good as far as 63 mantissa bits. In contrast to integers (2^64 - 1).
Wrong. There is an implied 1 bit (I think?) or full 64 bits at least. See https://en.wikipedia.org/wiki/Extended_precision

Think about it like this, people used to copy data with the FPU (using integer loads and stores, because otherwise NaNs would give you trouble if the data happened to have that pattern) 8 bytes at a time before SSE was mainstream. You understand this right? A data copy operation is not allowed to change even 1 bit and must preserve all 8 bytes perfectly.

Again, with integer loads and stores, because otherwise the FPU could mess the number up in certain cases (NaNs) but with integers no issue at all, since the significand itself is 64 bits wide. That's why they weren't copying 10 bytes at a time.

Most people think floating point math is unpredictable and random but that's nonsense.

You can do all operations with integer precision at least as wide as the significand is with absolutely no precision loss whatsoever (obviously, if you are looking for an integer result and truncate the fraction)
25 Apr 2017, 22:34
fasmnewbie

Joined: 01 Mar 2011
Posts: 555
fasmnewbie
Furs wrote:
fasmnewbie wrote:
No. F80 is good only for 18 significant digits. So representing max 0xffffffffffffffff (20 digits) with F80, will give you inexact result due to exponentiation.
Sorry but that's bullshit, you speak in decimal which is an approximation and has nothing to do whatsoever with binary representation.

fasmnewbie wrote:
Secondly, FPU and the general registers use different kind of overflow exceptions and flags. What may seem to be overflow in integers, may look fine in SFLAG register of the FPU.
Yeah, this is valid, but I never spoke about overflow flags though; I mean, it's same as not using upper half of a wide integer multiplication, which is the more common case. If he needs proper overflow detection then you are right, of course.

fasmnewbie wrote:
Thirdly, signmess in FPU and general registers are interpreted quite differently. 0 and -0.0 may give you trouble.
Huh?

-0.0 converted back to integer is 0, no issue at all. What trouble are you even speaking of. Multiplication by -0 is also 0 result (or -0, but again, when you convert it back when done, it's not an issue).

fasmnewbie wrote:
Next, FPU involves other kind of exceptions such as NaN (QNaN and SNaN) which is not relevant to integer operations but do affect the results and the entire operations.
How are you going to get those things if you perform integer operations...? Other than dividing by 0, which is an exception in integer division anyway, and needs special care.

Obviously you can do weird floating point math and prove me wrong, but that's beside the point. You cannot do those with integer operations, so why even think about them? In these cases it's "wrong result" vs "impossible code" (with integers) so it's still better.

fasmnewbie wrote:
Finally, 80-bit precision is only good as far as 63 mantissa bits. In contrast to integers (2^64 - 1).
Wrong. There is an implied 1 bit (I think?) or full 64 bits at least. See https://en.wikipedia.org/wiki/Extended_precision

Think about it like this, people used to copy data with the FPU (using integer loads and stores, because otherwise NaNs would give you trouble if the data happened to have that pattern) 8 bytes at a time before SSE was mainstream. You understand this right? A data copy operation is not allowed to change even 1 bit and must preserve all 8 bytes perfectly.

Again, with integer loads and stores, because otherwise the FPU could mess the number up in certain cases (NaNs) but with integers no issue at all, since the significand itself is 64 bits wide. That's why they weren't copying 10 bytes at a time.

Most people think floating point math is unpredictable and random but that's nonsense.

You can do all operations with integer precision at least as wide as the significand is with absolutely no precision loss whatsoever (obviously, if you are looking for an integer result and truncate the fraction)

Yeah genius.

f dt 18446744073709551615.0 ;(max 64-bit integer unsigned)
fld [f]

How do you think this may look like in the FPU register?

1.84467440737095516E+19

I wonder where the other 2 digits go...
25 Apr 2017, 23:47
revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 18731
revolution
fasmnewbie wrote:
f dt 18446744073709551615.0 ;(max 64-bit integer unsigned)
fld [f]

How do you think this may look like in the FPU register?

1.84467440737095516E+19

I wonder where the other 2 digits go...
Actually it stores inside the FPU just fine. There is no loss of precision. The FPU is binary in nature not decimal. But you can't store that as a normal qword with fistp due to integer overflow. Numbers in the normal 64-bit integer range (-2^63 to +2^63-1) can be manipulated with the FPU in extended precision mode just fine.
26 Apr 2017, 03:13
fasmnewbie

Joined: 01 Mar 2011
Posts: 555
fasmnewbie
revolution wrote:
fasmnewbie wrote:
f dt 18446744073709551615.0 ;(max 64-bit integer unsigned)
fld [f]

How do you think this may look like in the FPU register?

1.84467440737095516E+19

I wonder where the other 2 digits go...
Actually it stores inside the FPU just fine. There is no loss of precision. The FPU is binary in nature not decimal. But you can't store that as a normal qword with fistp due to integer overflow. Numbers in the normal 64-bit integer range (-2^63 to +2^63-1) can be manipulated with the FPU in extended precision mode just fine.

oh, ok then. I misread Furr's earlier comment. I thought he meant to use 80 bit precisions (DT) to represent an integer.
26 Apr 2017, 09:19
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First

 Jump to: Select a forum Official----------------AssemblyPeripheria General----------------MainTutorials and ExamplesDOSWindowsLinuxUnixMenuetOS Specific----------------MacroinstructionsOS ConstructionIDE DevelopmentProjects and IdeasNon-x86 architecturesHigh Level LanguagesProgramming Language DesignCompiler Internals Other----------------FeedbackHeapTest Area

Forum Rules:
 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum