OSDev.org

fano1 wrote:The problem is that on X86 CVTSS2SI convert a double to an Int32 not for an Int64! They have extended it to work with Int64 for X64 apparently...

Online I've seen references to a CVTSS2SIQ but NASM refuses to create the assembly using it... I suppose this is for Int64 too.

fano1 wrote:So any idea to how do a double to Int64 conversion using SSE on X86 / 32 Bit architecture?

• extract the sign bit and store it somewhere, and make the double positive if it was negative
• extract the high 31 bits (divide by (1<<32), convert to 32-bit integer), then subtract the high 31-bits from your double (multiply the integer by (1 << 32) and subtract from the original double).
• extract the middle 31 bits, subtract the middle 31 bits from the double
• extract the remaining lowest 1 bit (unless you don't need that extra 1-bit of precision?)
• OR the 3 pieces together to get a "63-bit unsigned integer" (or a "64-bit positive signed integer")
• If the sign bit was originally set; negate the 64-bit signed integer.

• if you have SSE2, there's no good reason to bother with MMX, so you wouldn't be switching from FPU to MMX anyway
• FPU is able to work on 80-bit "extended double" format (which has 16 bits more precision than a crusty old "double") while SSE doesn't, and therefore FPU is better than SSE in cases where the extra precision matters more than performance (even when you're only working with "double" because internally the FPU can/will use the 80-bit format for intermediate values)
• SSE doesn't provide things like sine, cosine, tangent, square root (but FPU does); so without FPU you'd have to implement these using extremely slow algorithms (that do give precise results) and/or lookup tables (where the precision is bad because you can't afford to blow away several GiB of RAM for lookup tables that are able to give "as precise as FPU" results).

Brendan wrote:Hi,

fano1 wrote:The problem is that on X86 CVTSS2SI convert a double to an Int32 not for an Int64! They have extended it to work with Int64 for X64 apparently...

Online I've seen references to a CVTSS2SIQ but NASM refuses to create the assembly using it... I suppose this is for Int64 too.

For AT&T syntax they append a "size" letter to various instructions, like appending a "Q" to "CVTSS2SI" to get a "CVTSS2SIQ" instruction. For Intel syntax the assembler is smarter and figures it out from the operands, so "CVTSS2SI RAX, XMM0" is automatically 64-bit because RAX is a 64-bit register.

For "CVTSS2SI" the destination must be a general purpose register, so you can't do something like (e.g.) "CVTSS2SI XMM1, XMM0".

fano1 wrote:So any idea to how do a double to Int64 conversion using SSE on X86 / 32 Bit architecture?

Brendan wrote: To fix that you'd probably need to:

• extract the sign bit and store it somewhere, and make the double positive if it was negative
• extract the high 31 bits (divide by (1<<32), convert to 32-bit integer), then subtract the high 31-bits from your double (multiply the integer by (1 << 32) and subtract from the original double).
• extract the middle 31 bits, subtract the middle 31 bits from the double
• extract the remaining lowest 1 bit (unless you don't need that extra 1-bit of precision?)
• OR the 3 pieces together to get a "63-bit unsigned integer" (or a "64-bit positive signed integer")
• If the sign bit was originally set; negate the 64-bit signed integer.

Brendan wrote: Alternatively; if you know the double is in a "nice" range (magnitude not too large or too small, not zero, not NaN) it might be faster to store the double (as a double) in 2 memory locations, remove the exponent and sign from the first copy to get the significand bits and OR the implied bit into the significand, then obtain the exponent from the second copy and add the "exponent bias" and use that as a shift count to shift the significand into its correct place; then obtain the sign bit and negate if sign bit set.

Brendan wrote: Of course using the FPU (which does allow you to convert double to 64-bit integer in 32-bit code) is probably easier and faster than all the other options. Note that:

• if you have SSE2, there's no good reason to bother with MMX, so you wouldn't be switching from FPU to MMX anyway
• FPU is able to work on 80-bit "extended double" format (which has 16 bits more precision than a crusty old "double") while SSE doesn't, and therefore FPU is better than SSE in cases where the extra precision matters more than performance (even when you're only working with "double" because internally the FPU can/will use the 80-bit format for intermediate values)
• SSE doesn't provide things like sine, cosine, tangent, square root (but FPU does); so without FPU you'd have to implement these using extremely slow algorithms (that do give precise results) and/or lookup tables (where the precision is bad because you can't afford to blow away several GiB of RAM for lookup tables that are able to give "as precise as FPU" results).

Brendan wrote: In any case; I'd be looking for a way to avoid the need to convert double into a 64-bit integer. For a random example; if you know the value will be within a certain range and don't care about some precision loss; then you can do "K = max_magnitude / (1 << 31)", then divide the double by K, convert that to a 32-bit integer, then multiply the 32-bit integer by K to get a "less precise than possible 64-bit integer" version of the original value. Of course if you choose a "max_magnitude" that is a power of 2 (or round it up to the nearest power of 2) your K will be a power of 2 and you can replace the division and multiplication with shifts.

double = 42.42;
long a = (long) b; // a == 42

Brendan wrote: Cheers,

Brendan

fano1 wrote:FPU yes uses 80 bits but and this means that to obtain real double / float should do casting so any extra precision is always lost...

fano1 wrote:Regarding trigonometric function for now they are software implemented but in future we could use SSE for this for example this library:
http://gruntthepeon.free.fr/ssemath/sse_mathfun.h

jnc100 wrote: If you're in 64-bit mode then the instruction is cvtsd2si (rather than cvtss2si) as this utilises 64 bit floats rather than 32 bit ones. In 32-bit mode, there is no direct instruction to do what you want. Typically, you'd want to do it is some run-time library (gcc uses libgcc). There is a function called __fixdfdi that does what you want (see fixdfdi.c for the clang implementation and here for the typedefs used in that code).

jnc100 wrote: Note that you need to be careful if you use this directly as C code however, because the x86 32-bit ABI expects the floating point argument to be passed in in FPU registers, and I don't know what ABI 32-bit COSMOS uses for interfacing with external functions.

Regards,
John.

fano1 wrote:@Brendan
I had not noticed that the SSE version used 32 bit floating points well I think it should be ported to use double easily.
Regarding the precision of FPU sin() function:

https://randomascii.wordpress.com/2014/ ... intillion/

fano1 wrote:OK so CVTSS2SIQ was a pseudo-instruction the real instruction is CVTSS2SI

• The x86 and x86-64 instruction set designs, and the designs of the assembly languages for them by Intel (and AMD), have been touched by many hands, and aren't particularly consistent overall.
• While we usually say that an assembly mnemonic has a one-to-one correspondence to an opcode, this isn't actually true in many if not most cases. Many assemblers use a single mnemonic for several related opcodes, and conversely, different mnemonics, naming what are conceptually different operations, may represent the same opcode if the operations have the same actual affect; e.g., JZ and JE are the same test of the zero flag, and thus represent the same opcode. The real correspondence is with the instruction as a whole to the opcode plus its operands.
• An assembler is not required to represent the opcodes the same way that the manufacturer's documentation does; different assemblers can use very different syntax for the same opcodes. For example, to represent the opcode which sets RAX to a value on the stack pointed to by RBP with an offset of 8 bytes, an assembler might use

  Code: Select all

  mov rax, [rbp + 8]

  or

  Code: Select all

  movq 8(%rbp), %rax

  or

  Code: Select all

  rax <- rbp[8] 

  or

  Code: Select all

  (move-to rax (index rbp 8))

  As long as the correspondence from each instruction - not the mnemonic, but the instruction as a whole - is one-to-one to the opcode and set of operands it represents, it is still assembly language.

  mov EAX, ESP + 4 // did you mean [ESP + 4] ?
  fild  qword ptr [esp]
  shr EAX, 31 // why didn't you just do "test eax, eax ++ jns not_signed" ?
  cmp ESP, 0 // why do you compare ESP instead of EAX?
  jpe LabelSign_Bit_Unset // parity isn't about the least-significant bit, it's about the number of set bits
  LabelSign_Bit_Unset: // label is just after the jump, so compare + jump are doing effectively nothing
  fadd  dword ptr __ulong2double_const
  fstp ESP // did you mean "qword[esp]" or "qword ptr esp" ?

Simply doing a difference between F043 and F0BF gives this value

fano1 wrote:I don't understand these notes: "parity isn't about the least-significant bit, it's about the number of set bits" I don't check if the number is pair (?) but if it is signed or unsigned. A signed number has the last bit set as 1 or not?