64bit int to a double float with a SIMD instruction on a 32bit system.

[Siekmanski]

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]

maybe something like that:

Code Select Expand

.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

[jj2007]

You could use fild and fstp, too.

[Siekmanski]

Thanks qWord and jj2007,
Thought there was a single SIMD instruction to do this.

[jj2007]

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]

If the entire task isn't so time critical, I would prefer the old FPU solution, because it's more accurate.

Gunther

[Antariy]

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]

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]

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]

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]

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]

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:

[Yuri]

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]

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