Author Topic: 64bit int to a double float with a SIMD instruction on a 32bit system.  (Read 5229 times)

Siekmanski

  • Member
  • *****
  • Posts: 1089
How to convert a 64bit int to a double float with a SIMD instruction on a 32bit system ?

I've tried this:

    cvtsi2sd    xmm0,qword ptr[eax]

It seems it only takes a 32bit int.


qWord

  • Member
  • *****
  • Posts: 1454
  • The base type of a type is the type itself
    • SmplMath macros
maybe something like that:
Code: [Select]
.data
    qw QWORD -123456789123
.const
    align 16
    msk0 LABEL OWORD
         QWORD 1,0
    msk1 LABEL OWORD
         REAl8 1.0,65536.0
    msk2 LABEL OWORD
         REAL8 4294967296.0,281474976710656.0
    msk3 LABEL OWORD
         QWORD 8000000000000000h,0
.code
pcmpeqb xmm2,xmm2
mov eax,DWORD ptr qw[4]
movq xmm0,qw
.if SDWORD ptr eax < 0
    pandn xmm0,xmm2
    paddq xmm0,msk0
.endif
pxor xmm1,xmm1
punpcklwd xmm0,xmm1
pshufd xmm1,xmm0,1110y
cvtdq2pd xmm0,xmm0
cvtdq2pd xmm1,xmm1
mulpd xmm0,msk1
mulpd xmm1,msk2
addpd xmm1,xmm0
movapd xmm0,xmm1
shufpd xmm1,xmm0,1
addpd xmm0,xmm1
.if SDWORD ptr eax < 0
    xorpd xmm0,msk3
.endif
MREAL macros - when you need floating point arithmetic while assembling!

jj2007

  • Member
  • *****
  • Posts: 7542
  • Assembler is fun ;-)
    • MasmBasic
You could use fild and fstp, too.

Siekmanski

  • Member
  • *****
  • Posts: 1089
Thanks qWord and jj2007,
Thought there was a single SIMD instruction to do this.

jj2007

  • Member
  • *****
  • Posts: 7542
  • Assembler is fun ;-)
    • MasmBasic
afaik there is no simple SSE instruction. Both qWord's and my solution will do the job. Time it...

fild MyQwInt
fstp MyDouble

or:

push eax
push edx
movlps [esp], xmm0  ; source
fild QWORD PTR [esp]
fstp REAL8 PTR [esp]
movlps xmm0, [esp]  ; dest

Gunther

  • Member
  • *****
  • Posts: 3515
  • Forgive your enemies, but never forget their names
If the entire task isn't so time critical, I would prefer the old FPU solution, because it's more accurate.

Gunther
Get your facts first, and then you can distort them.

Antariy

  • Member
  • ****
  • Posts: 541
If the entire task isn't so time critical, I would prefer the old FPU solution, because it's more accurate.

Right, and I guess, FPU will be faster than multiple-instructions SSE solution :t

Yuri

  • Member
  • **
  • Posts: 154
Not all 64-bit integers can be converted to a double, because its mantissa has only 53 bits. It looks like nobody cares, or am I missing something? :icon_cool:

Siekmanski

  • Member
  • *****
  • Posts: 1089
I was just curious because it works with 64 bit assembly.

cvtsi2sd xmm0,rax                      ; convert qword to double
cvtsi2sd xmm0,dword ptr[mem] ; convert dword integer

dedndave

  • Member
  • *****
  • Posts: 8734
  • Still using Abacus 2.0
    • DednDave
Yuri
they can be converted, but you may lose some precision
i.e., some low-order bits will get thrown away for values larger than 53 bits
but, the max double is something like 1.8E+308

it would be easier if he wanted to convert to extended real - lol
that could be done very easily without SSE or FPU code

Yuri

  • Member
  • **
  • Posts: 154
Yuri
they can be converted, but you may lose some precision
i.e., some low-order bits will get thrown away for values larger than 53 bits
Yes, that's exactly what I meant. If you lose some bits, it's not the same number anymore. So I would not call it conversion.

qWord

  • Member
  • *****
  • Posts: 1454
  • The base type of a type is the type itself
    • SmplMath macros
So I would not call it conversion.
"conversion" is the correct terminology.
Also, you can safely assume that most people here aware of the precision problematic that comes along with FP calculations   :icon_cool:
MREAL macros - when you need floating point arithmetic while assembling!

Yuri

  • Member
  • **
  • Posts: 154
So I would not call it conversion.
"conversion" is the correct terminology.
Also, you can safely assume that most people here aware of the precision problematic that comes along with FP calculations   :icon_cool:
OK, maybe I misunderstood the term. After all, if the same bits were lost in the fractional part of a floating point number, I would not necessarily say the number had changed. It would depend on what precision I needed. Actually the difference between that case and losing bits in a large integer is in scale. For some reason it has never occured to me.  :icon_cool:

Gunther

  • Member
  • *****
  • Posts: 3515
  • Forgive your enemies, but never forget their names
Hi qWord,

"conversion" is the correct terminology.

that's right, but the term is a bit delusory in such circumstances.

Also, you can safely assume that most people here aware of the precision problematic that comes along with FP calculations   :icon_cool:

That's for sure.

Gunther
Get your facts first, and then you can distort them.