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?

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?

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?

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).

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)

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...

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.