[NASM x86] Convertire uint64 in double

[||ElChE||88]

Originariamente inviato da AnonimoVeneziano

La FPU x86 e' nativa a 80-bit.

Cercare di obbligarla a fare computazioni con precisione a 64-bit richiederebbe extra lavoro per assicurarsi che gli arrotondamenti siano conformanti con gli stessi arrotondamenti un hardware che lavora nativamente a 64-bit farebbe.

Eh? La precisione si può settare a 32/64/80 con fldcw e non richiede nessun lavoro extra.

[AnonimoVeneziano]

Originariamente inviato da ||ElChE||88

Eh? La precisione si può settare a 32/64/80 con fldcw e non richiede nessun lavoro extra.

E' vero, ho toppato

[fano]

Però effettivamente quello che dice la Microsoft è un po' fuorviante!
Forse si riferivano alla cosa di dover settare la FPU a double per calcoli con double e a float per calcoli con i float tutte le volte? Beh ma basta rimappare il tipo 'F' a double (o long double) e sei a cavallo no? Tanto io sinceramente nella mia carriera ho sempre usato double mai float quindi il fatto delle continue conversioni non lo accuserei.

C'è da dire comunque che SSE da questo punto di vista è meglio visto che ho la possibilità di fare operazioni direttamente su float e double sono anche molto più semplici da usare!
Unica pecca è che già che c'erano potevano aggiungere un hexfloat (Float128 o come volete chiamarlo) che avrebbe potuto prendere il posto del Float80 / long double per alcune applicazioni ha sicuramente senso avere un precisione così alta e la mia impressione - da profano - era che non gli sarebbe costato nulla farlo!

In realtà ora che in C hanno aggiunto il tipo decimal, non uso più nemmeno double! Io faccio calcoli monetari e voglio che i risultati siano corretti!

Comunque ho deciso a provare il mio codice su un altro OS perché ho il dubbio che qualcosa non sia inizializzato in maniera corretta in Cosmos quindi ho fatto partire l'orrenda Ubuntu e ho aperto un bel Gnome-terminal full screen (tanto la GUI a che serve su Linux? A niente ) e ho prodotto sta roba:

section .data
 hello:     db 'Hello world!',10    ; 'Hello world!' plus a linefeed character
 helloLen:  equ $-hello             ; Length of the 'Hello world!' string
                                    ; (I'll explain soon)
 __ulong2double_const4: dd 5F800000h
 __ulong2double_const3: db 0, 0, 95, 128
fmt:    db "%f", 10, 0 ;The printf format, "\n",'0'

section .text
 global _start
extern	printf		; the C function, to be called
 
_start:
 ; Let's put on ESP -1 (0xFFFFFFF) as Cosmos should do
 mov EAX, 0xFFFF
 push EAX
 mov EAX, 0xFFFF
 push EAX
 ; Let's try our code
 mov dword EAX, [ESP + 4]
 fild qword [ESP]
 test dword EAX, EAX
 JNS near LabelSign_Bit_Unset
 fadd qword [__ulong2double_const3]
 LabelSign_Bit_Unset:
 fstp dword [ESP]
; How to print what is in ESP now? Can I call printf()?
 push    dword fmt	; address of ctrl string
 call    printf		; Call C function
 mov eax,1            ; The system call for exit (sys_exit)
 mov ebx,0            ; Exit with return code of 0 (no error)
 int 80h

Purtroppo la printf() mi stampa 0.0! Eppure non credo di aver toppato alla fine della conversione il mio double dovrebbe essere in ESP, io "pusho" il formato visto che la C Calling convention è all'incontrario e chiamo la printf... o no?

[||ElChE||88]

Occhio che printf promuove i float a double, quindi devi fare spazio nello stack e salvare come qword ptr [esp].

[fano]

Mi sto incasinando con tutte ste prove! L'originale dentro Cosmos ha correttamente qword... dove è uscito sto dword?

Il valore non è più 0.0, ma 281470681808895.000000 che in hex è 0x001fffe0! Non è il valore atteso... (ma almeno è diverso da -1.0) così printf() sta leggengo garbage probabilmente...

Ho dovuto cambiarlo così perché oggi ld non era più capace di linkare il .o e ho dovuto usare GCC che vuole però il main...

section .data
 __ulong2double_const4: dd 5F800000h
 __ulong2double_const3: db 0, 0, 95, 128
fmt:    db "0x%08x", 10, 0 ;The printf format, "\n",'0'

extern	printf		; the C function, to be called
section .text
 global main
 
main:
 ; Let's put on ESP -1 (0xFFFFFFF) as Cosmos should do
 mov ECX, 0xFFFF
 push ECX
 mov ECX, 0xFFFF
 push ECX
 ; Let's try our code
 mov dword EAX, [ESP + 4]
 fild qword [ESP]
 test dword EAX, EAX
 JNS near LabelSign_Bit_Unset
 fadd qword [__ulong2double_const3]
 LabelSign_Bit_Unset:
 fstp qword [ESP]
; How to print what is in ESP now? Can I call printf()?
 push    dword fmt	; address of ctrl string
 call    printf		; Call C function
 mov eax,1            ; The system call for exit (sys_exit)
 mov ebx,0            ; Exit with return code of 0 (no error)
 int 80h

[||ElChE||88]

Il risultato è esatto, perché il tuo valore iniziale è 0x0000FFFF0000FFFF e non 0xFFFFFFFFFFFFFFFF come dovrebbe essere. Immagino tu intendessi

mov ecx, 0xFFFFFFFF

e non

mov ecx, 0xFFFF

[fano]

Sto lavorando a 32 bit quindi non dovrebbe essere possibile scrivere in un registro più di 4 Byte... è per questo che scrivevo il valore in ESP in 2 parti...

Comunque ha compilato scrivendo in ECX 0xFFFFFFFF (non avrebbe dovuto), ma il valore ottenuto non ha comunque senso: 0x5f000000 (-5235985954719662080.000000).

Non capisco...

P.S. Ah intendevi che dovevo scrivere FFFFFFFF 2 volte sullo stack! OK... almeno il risultato ha senso, ma anche su Linux NASM genera un'instruzione vuota invece di fadd:

fano@ubuntu:~/testAsm$ gcc long2double.o -o long2double
fano@ubuntu:~/testAsm$ ./long2double
-1.000000

Mi dichiaro sconfitto: la macchina ha vinto sull'uomo...

[GTKM]

Originariamente inviato da fano

Sto lavorando a 32 bit quindi non dovrebbe essere possibile scrivere in un registro più di 4 Byte... è per questo che scrivevo il valore in ESP in 2 parti...

Comunque ha compilato scrivendo in ECX 0xFFFFFFFF (non avrebbe dovuto), ma il valore ottenuto non ha comunque senso: 0x5f000000 (-5235985954719662080.000000).

Non capisco...

P.S. Ah intendevi che dovevo scrivere FFFFFFFF 2 volte sullo stack! OK... almeno il risultato ha senso, ma anche su Linux NASM genera un'instruzione vuota invece di fadd:

fano@ubuntu:~/testAsm$ gcc long2double.o -o long2double
fano@ubuntu:~/testAsm$ ./long2double
-1.000000

Mi dichiaro sconfitto: la macchina ha vinto sull'uomo...

Io sono sicuro che alla fine si scoprirà che c'è qualche stupida cazzatina che causa questi errori.

[cdimauro]

Concordo. L'FPU x87 la si usa da 30 anni e passa ormai: ci sarà qualche errore che sfugge al momento.

[||ElChE||88]

A me funziona cambiando

fadd qword [__ulong2double_const3]

in

fadd dword [__ulong2double_const4]

(la costante è un errore mio, nella versione db i 2 byte sono invertiti)

[fano]

Ma siamo sicuri della costante: 0x5F800000? Magari non dovrebbe essere di 8 byte pure lei per fare la cosa corretta?

[||ElChE||88]

La costante va bene così.

[fano]

Ci siamo ragazzi Cosmos sa fare un ridicolo cast di ulong in un double!

02:09:28.551348         Msg: Text from kernel: Assertion succeeded:
02:09:28.566356         Msg: Text from kernel: (double) from ulong operator doesn't work long is FF-FF-FF-FF-FF-FF-FF-FF value (as bytes) is
00-00 F0-43-00-00-00-00
Test completed

Che non è altro che il nostro amichetto 18446744073709551615!

Quindi 'd' al posto di una 'q' che ci ha fregati?

Mi piacerebbe capire che cosa succedeva, però...

avevamo scritto:
fadd qword[__ulong2double_const4]
ma __ulong2double_const4 era in realtà un intero a 32 bit (un double word come piace chiamarlo ad Intel ) quindi NASM faceva un cast maldestro facendolo diventare:
00 00 00 00 5F 80 00 00
ma poi solo i primi 4 byte erano in qualche modo sommati? Quindi un'addizione con 0x00000?

Boh!
Grazie a tutti dell'aiuto... ora committo - e poi come vi ha avevo promesso apro un post dedicato a Cosmos: partecipate numerosi!

[fano]

Ho aperto il thread ufficiale su Cosmos se avete quindi altre domande su Cosmos o meglio se volete partecipare al progetto scrivete qui

[||ElChE||88]

Originariamente inviato da fano

avevamo scritto:
fadd qword[__ulong2double_const4]
ma __ulong2double_const4 era in realtà un intero a 32 bit (un double word come piace chiamarlo ad Intel ) quindi NASM faceva un cast maldestro facendolo diventare:
00 00 00 00 5F 80 00 00
ma poi solo i primi 4 byte erano in qualche modo sommati? Quindi un'addizione con 0x00000?

Semplice: 0x5F800000 è la rappresentazione binaria di 18446744073709551616 in formato floating-point 32 bit, mentre 0x000000005F800000 non è la rappresentazione binaria di 18446744073709551616 in formato floating-point 64 bit.

Esempio:

unsigned int val1 = 0x5F800000UL;
unsigned long long val2 = 0x000000005F800000ULL;
unsigned long long val3 = 0x43F0000000000000ULL;

printf("%f\n%f\n%f\n", *(float *)&val1, *(double *)&val2, *(double *)&val3);

18446744073709551616.000000
0.000000
18446744073709551616.000000

[fano]

Originariamente inviato da ||ElChE||88

Esempio:

unsigned int val1 = 0x5F800000UL;
unsigned long long val2 = 0x000000005F800000ULL;
unsigned long long val3 = 0x43F0000000000000ULL;

printf("%f\n%f\n%f\n", *(float *)&val1, *(double *)&val2, *(double *)&val3);

18446744073709551616.000000
0.000000
18446744073709551616.000000

... ed ecco il nostro 0.0000 ed ecco perché la fadd non faceva "nulla" sommava con 0!

Ottimo... è sempre la solita cosa: i computer non mentono e i programmatori sbagliano una d con una q, riguardano il codice per 20 volte (!) e per loro è giusto non c'è verso: non funziona!

Forse perché non era giusto affatto?

Comunque trovo un fascino "segreto" nell'aver usato Linux per debuggare un problema nel SO che - in futuro - lo ucciderà

[cdimauro]

Hai visto che alla fine era una cosa banale?

Adesso mettevi sotto con la test suite.

[fano]

Guarda che la test suite c'è già! Bisogna aggiungere altri test certo...

Addirittura dopo aver committato abbiamo Appvoyer che automaticamente prova a compilare (dando errore se non compila / ti sei scordato dei file) e poi esegue tutti i test e si blocca al primo errore!
Strumento davvero utilissimo...

[cdimauro]

Sì, ma la test suite va rinforzata, con altri, tanti bei test.

[fano]

Assolutamente se arrivo vivo al fine settimana (sono praticamente solo in ufficio: i capi hanno deciso che era il momento buono per andarsene in ferie ) ho intenzione di aggiungere test per anche operazioni aritmetiche e conversioni (cast in C#) sugli interi visto che quando hanno deciso di passare a X# mentre ero distratto hanno cambiato tutto e magari ci sono stati degli errori che il testRunner deve beccare!

Anche perché ho intenzione di fare quella utilityClass per evitare le ripetizioni di codice e quindi dopo che avrò testato tutto ho intenzione di romperlo di nuovo