[NASM x86] Convertire uint64 in double

[fano]

Dopo aver hexpumpato (?) il long double -1.0 dal C e aver ottenuto questo schifo:

sizeof(long double) 12
-1 as long double '0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0xff 0xbf 0x00 0x00 '
sizeof(double) 8
-1 as double '0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0xbf '

mentre BOCHS mi mostrava sta roba:

FP7 ST0(v): raw 0xbfff:8000000000000000 (-1,0000000000) (NORMAL)

I byte sono in posizioni diverse (endianess?) ma sembra il valore che vedo nel long double quindi l'FPU è a 80 Bit!

Quindi la costante è errata ed è per questo che non va una mazza?
E soprattutto è giusto avere l'FPU a 80 Bit o è meglio averla settata come 64 bit (così da evitare continue conversioni?).

Anche la Microsoft non sembra convinta:

Originariamente inviato da Microsoft

4.1.6 Floating-point types

Floating-point operations may be performed with higher precision than the result type of the operation. For example, some hardware architectures support an “extended” or “long double” floating-point type with greater range and precision than the double type, and implicitly perform all floating-point operations using this higher precision type. Only at excessive cost in performance can such hardware architectures be made to perform floating-point operations with less precision, and rather than require an implementation to forfeit both performance and precision, C# allows a higher precision type to be used for all floating-point operations. Other than delivering more precise results, this rarely has any measurable effects. However, in expressions of the form x * y / z, where the multiplication produces a result that is outside the double range, but the subsequent division brings the temporary result back into the double range, the fact that the expression is evaluated in a higher range format may cause a finite result to be produced instead of an infinity. To force a value of a floating point type to the exact precision of its type, an explicit cast can be used.

Perché questo? "Only at excessive cost in performance can such hardware architectures be made to perform floating-point operations with less precision"
non posso settare la FPU a 64 Bit alla partenza e dimenticarmene? Sarebbe più lenta? Padda gli altri 4 byte con 0 ogni volta?

A questo solo il nostro insider Intel può rispondere mi sa

[cdimauro]

Originariamente inviato da GTKM

Ma sapete che 'sto Cosmos mi sta intrippando? Quasi quasi, appena mi libero un po' con la tesi (Aaaaaah, le catene di Markov... ) mi unisco a voi

Fai bene: è un ottimo progetto, innovativo, estremamente intrigante, e formativo.

Originariamente inviato da fano

Ieri sera abbiamo messo Bochs in modalità debug e siamo andati a vedere step per step cosa c'era nei registri vi faccio un breve riassunto:

1. Nello stack c'era l'unlong FFF... diviso in 2 parti essendo - ovviamente - lo stack x86 composto da parti a 32 Bit
2. Dopo la mov in EAX c'era la parte alta del nosto ulong (0xFFFF)
3. Dentro il registo ST0 della CPU era inserito -1.0 ma in esadecimale non era il valore che mi aspettavo (0xBFFF invece di 0xF0BF) forse perchè la FPU era in extended precision? Gli strani floating point a 80 bit...
4. Il jump era correttamente non eseguito perchè EAX aveva il segno (!)
5. Ma la fadd non faceva assolutamente nulla e quindi dopo quell'istruzione in ST0 c'era ancora -1.0 / 0xBFFF!
6. fstp convertiva correttamente 0xBFFF in 0xF0BF e lo copiava nello stack

L'FPU x87 dovrebbe funzionare internamente sempre a 80 bit, garantendo la massima precisione, a prescindere da come vengano caricati i dati nei registri.

Adesso non ho tempo né testa (il post-partita è, diciamo, un po' traumatico ), ma se ti serve appena posso indagherò e ti farò sapere (non prima di domani sera, comunque).

Riguardo alla costante caricata nello stack e nel registro ST0, sei sicuro che Bochs ti mostri una rappresentazione corretta?

Quindi questa è la domanda da un milione di Euro: come può un'addizione non avere effetto? L'unico caso in matematica è quando l'addendo vale 0, ma qui valeva 0x5F800000!
Forse è perché la constante è un double mentre in FP0 c'è un long double? Vede solo gli ultimi 5 zeri?

No, come ti dicevo sopra, una volta caricato il dato, l'FPU lavora a precisione massima (non posso darti la sicurezza al 100% perché dovrei controllare come già detto, ma io ricordo così al momento).

La causa dev'essere un'altra.

Beh non è che ci lavoro solo io eh! Non sono nemmeno il capo del team io mi sono aggiunto solo di recente (volevo il cursore quadrato e blikante tipo C=64 e poi son finito a scrivere assembler in C# ).

Tranquillo: un giorno ci tornerai, e lo farai girare anche sul C64.

Sì abbiamo visto! Infatti è un "problema" che andrà in futuro affrontato probabilmente come tutti i compilatori dovremo usare dei profili per attivare diversi path d'istruzione a seconda della CPU / set di flags selezionati.
A me piacerebbe che Cosmos riuscisse a farlo in automatico magari interrogando alla partenza la CPU per vedere quale istruzioni supporta e poi con qualche symbol table chiamare una funzione piuttosto che un'altra, ma visto che l'assembler dobbiamo crearlo a compile time beh è un po' difficile farlo: andrebbero lasciati dei "buchi" nell'assembler stesso!

Ma non avete una gerarchia di classi per gestire il tutto? Istanzi le classi giuste all'inizio, che si occupano di generare codice binario adeguato all'architettura corrente, e siete a posto. L'OOP si presta bene per modellare questo tipo di problemi, eliminando buona parte degli odiosi (e poco performanti) if-then-else.

Tanto AVX per il momento non lo supportiamo non abbiamo ancora pensato a come risolvere il problema della FPU (e altre specifiche istruzioni che una CPU potrebbe avere, ma altre no), il nostro minimo comun denominatore è x86, 32 Bit con supporto a SSE2 quindi se ricordo bene si va indietro fino al Pentium III / 2000.

No, per le SSE2 devi avere almeno un Pentium 4. Le SSE sono arrivate col Pentium 3.

Comunque non vi fossilizzate con processore = versione minima per avere alcune estensioni, perché un processo moderno può benissimo implementare una vecchia ISA per particolari esigenze, come dimostra Galileo.

Abbiamo valutato che la compatibilità con i processori troppo vecchi non avesse alcun senso per un OS del 2016 inoltrato!

Vedi sopra: ci sono processi moderni che supportano vecchie ISA!

Non vi sbarazzerete così facilmente del legacy.

E comunque, dati i vostri obiettivi, è giusto che sia così.

Temo sia un po' difficile che l'intero runtime .NET possa stare in 64 KByte di RAM e che poi ci sia spazio per il kernel e le applicazione. Magari qualcuno per "gioco" farà il porting per Amiga o Atari ST

Ci sono delle schede acceleratrici nuove di pacca per Amiga che offrono 128MB di memoria DDR3, e prestazioni 200 volte superiori a un Amiga 600, per cui... si può fare. Ma non posso/voglio mettermici io.

E` sicuramente possibile! Per essere chiari dentro Cosmos non gira lo stesso .NET che gira su Windows, ma una versione nostra che viene compila in codice nativo un po' come .Net Native / Core Rt quindi noi per supportare x32 dovremmo "semplicemente" mettere il processore in long mode e quindi avremmo più registri, l'aritmetica coi long "ver", ma la dimensione di IntPtr / nativeInt sarebbe sempre di 32 bit.

Esattamente. L'unica "oddity" è rappresentata dai puntatori a 32-bit pur avendo gli interi a 64 bit "nativi", ma va bene così: tanto si usano per lo più gli interi a 32-bit, mentre i 64-bit si possono strategicamente usare per spostamenti/copie di memoria, azzeramento, ricerche, ecc.

In realtà buona parte di .NET è riutilizzato, ma ci sono parti in cui .NET chiama C++ o peggio assembler e quelle parti vanno riscritte in C# usando quellli che in Cosmos sono chiamati plug. Per esempio la classe Console è tutta "pluggata" visto che noi scriviamo direttamente sulla Console VGA!

Strano che ci sia tanta roba in C++ o assembly: pensavo che ci fosse soltanto una piccola parte, e il resto gestito dal backend che emette il codice binario specifico.

Infatti è questa la forza di .NET!
Non capisco perché la Microsoft non abbia fatto la mossa coraggiosa per Windows 10 e non sia ancora passata a .NET per tutto. Temo che il vero motivo sia il solito i 30 anni di compatibilità con X86!

Non credo. Probabilmente è perché con .NET non vai sempre meglio di C++ a livello di startup e/o prestazioni e/o dimensione del codice e/o consumo della memoria, e comunque non hai la flessibilità che ti offre C++ nel gestire a tuo assoluto piacimento la memoria.

Comunque C# è un gran, ottimo compromesso, e per quanto mi riguarda fate benissimo a portare avanti Cosmos

Originariamente inviato da fano

Eppure non lo è! Certo essendo passato come costante non lo vedo dentro alcun registro, ma l'istruzione fadd sembra corretta (beh in realtà ho qualche dubbio sul fatto che la costante sia tra parentesi quadre quindi vista come puntatore, ma per la versione con gli uint la Microsoft faceva così e funzionava quindi...).

Scusami, ma non avete una test suite da lanciare per verificare che quel che fate funzioni, senza dover tirar sù Bochs ogni volta?

Altrimenti così perdete troppo tempo andando a caccia di bug come questi.

Concordo! Però sarebbe bello dopo 30 anni avere qualcosa di nuovo, ma se viene rigettato solo perché non ci girano le applicazioni x86 (come nel caso di Itanium e Windows Rt) beh Midori resterà sempre e solo nei laboratori di ricerca Microsoft[*].

Potreste realizzare un JIT-er che esegue le vecchie applicazioni x86, convertendole però in IL, fino a mappare man mano tutto il codice in IL.

Dopodiché potreste ricompilare l'applicazione x86 in qualunque architettura.

* In un OS language based come Midori e Cosmos codice "nativo" non può / non deve girare se no cadrebbe lo scopo per cui è stato scritto. Solo applicazioni .NET che vengono trasformate in assembler ad installation time... quindi no niente Firefox (!), Python sì lo si potrà avere nella forma di Iron Python però...

Hai detto niente. Va bene così.

Originariamente inviato da fano

E mi chiedeva cosa ci fanno le [ ] davanti alla costante della fadd? In effetti non sono sicuro nemmeno io che abbia senso, ma il codice MASM originale la passava come puntatore 'ptr .label'... può essere questo il problema... magari Bochs è "educato" e anche se punto a RAM a caso mi trovo tutti 0?

E' possibile che punti a una zona di memoria che genera eccezioni, ma provoca i problemi di cui hai discusso finora.

Esatto:
joeduffyblog.com/2015/12/19/safe-native-code/

TL;Read Later.

Originariamente inviato da fano

Dopo aver hexpumpato (?) il long double -1.0 dal C e aver ottenuto questo schifo:

sizeof(long double) 12
-1 as long double '0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0xff 0xbf 0x00 0x00 '
sizeof(double) 8
-1 as double '0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0xbf '

Mi pare normale: il primo è un extended a 80 bit, e il secondo il classico double a 64 bit.

mentre BOCHS mi mostrava sta roba:

FP7 ST0(v): raw 0xbfff:8000000000000000 (-1,0000000000) (NORMAL)

Strano.

I byte sono in posizioni diverse (endianess?) ma sembra il valore che vedo nel long double quindi l'FPU è a 80 Bit!

Sì, certo. Dovrebbe essere sempre così, internamente (ma puoi anche memorizzare un extended a 80 bit in memoria).

Quindi la costante è errata ed è per questo che non va una mazza?
E soprattutto è giusto avere l'FPU a 80 Bit o è meglio averla settata come 64 bit (così da evitare continue conversioni?).

E' giusto così, ma al momento non capisco cos'è che non ti faccia funzionare il codice.

Anche la Microsoft non sembra convinta:

Perché questo? "Only at excessive cost in performance can such hardware architectures be made to perform floating-point operations with less precision"
non posso settare la FPU a 64 Bit alla partenza e dimenticarmene? Sarebbe più lenta? Padda gli altri 4 byte con 0 ogni volta?

L'FPU (x87) non è più lenta: funziona così.

Però mi pare che abbia delle istruzioni di FADD e FMUL che vengono eseguite a precisione inferiore a quella estesa, ma che sono più veloci. Solo che al momento non posso verificare.

A questo solo il nostro insider Intel può rispondere mi sa

Spero che ti sia stato utile. Io vado a smaltire adesso.

EDIT: per parlare in generale di Cosmos, ti consiglio di aprire un apposito thread.

[fano]

Originariamente inviato da cdimauro

Fai bene: è un ottimo progetto, innovativo, estremamente intrigante, e formativo.

La penso anch'io così anche se Cosmos non diventerà mai il Linux del futuro (ma accadrà ) non sarebbe comunque tempo perso!

Originariamente inviato da cdimauro

L'FPU x87 dovrebbe funzionare internamente sempre a 80 bit, garantendo la massima precisione, a prescindere da come vengano caricati i dati nei registri.

Ma non è possibile settarla a 64 Bit? Tutte queste conversioni tra double <--> long double anche se fatte in hardware un costo lo avranno, no?

Originariamente inviato da cdimauro

Adesso non ho tempo né testa (il post-partita è, diciamo, un po' traumatico ), ma se ti serve appena posso indagherò e ti farò sapere (non prima di domani sera, comunque).

Te ne sarei grato sta cosa dell'addizione che non addiziona mi sta facendo impazzire

Originariamente inviato da cdimauro

Riguardo alla costante caricata nello stack e nel registro ST0, sei sicuro che Bochs ti mostri una rappresentazione corretta?

Boh se mostra pure roba sbagliata siamo fritti! Già l'interfaccia fa alquanto schifo ci manca pure che mostri una rappresentazione errata

Originariamente inviato da cdimauro

No, come ti dicevo sopra, una volta caricato il dato, l'FPU lavora a precisione massima (non posso darti la sicurezza al 100% perché dovrei controllare come già detto, ma io ricordo così al momento).

La causa dev'essere un'altra.

Sicuramente è qualche errore stupido...

Originariamente inviato da cdimauro

Tranquillo: un giorno ci tornerai, e lo farai girare anche sul C64.

Beh il mio OS ha già la shell con lo sfondo blu e le scritte bianche, con "Ready" e il cursore che lampeggia quindi
Se in futuro saprà in di eseguire script in C# o meglio ancora VB.NET potrò dire di aver riprodotto l'esperienza quasi totalmente

Originariamente inviato da cdimauro

Ma non avete una gerarchia di classi per gestire il tutto? Istanzi le classi giuste all'inizio, che si occupano di generare codice binario adeguato all'architettura corrente, e siete a posto. L'OOP si presta bene per modellare questo tipo di problemi, eliminando buona parte degli odiosi (e poco performanti) if-then-else.

Beh abbiamo le classi questa per esempio è la classe Add.cs che converte l'IL in Assembler: https://github.com/fanoI/Cosmos/blob...2CPU/IL/Add.cs.
Come puoi vedere nel caso di float / double sono ora usate le istruzione SSE (prima venivano usate solo per i float e a me questo ha rotto l'armonia ), IL2CPU è letteralmente il nostro compilatore quindi non possiamo sapere quale sarà l'architettura sulla quale andremo a girare. Certo quando metteremo su questa idea dei profili non voglio che si riempa tutto di if (FPU.isX87), if (FPU.isSSE). I mie prossimi passi (dopo che conv.r.un funziona se no, non me lo merito ):

1. C'è ancora qualcosa da aggiustare nel backend X#: alcune istruzioni non sono generabile senza usa Xs.Literal() altre potrebbero essere fatte meglio
2. Pensavo di creare una classe astratta / interfaccia FPU in cui mettere funzioni tipo Init(), CVT2Int(), CVT2Long(), Add()... e uno deriva da quella classe l'implementazione per FPU e SSE.

Per esempio un ipotetica SSE.Add() diventerebbe:

static void Add()
      XS.SSE2.MoveSD(XMM0, ESP, sourceIsIndirect: true);
      // Move the stack of 8 bytes to get the second double
      XS.Add(ESP, 8);
      XS.SSE2.MoveSD(XMM1, ESP, sourceIsIndirect: true);
      XS.SSE2.AddSD(XMM1, XMM0);
      XS.SSE2.MoveSD(ESP, XMM1, destinationIsIndirect: true);{
}

Originariamente inviato da cdimauro

No, per le SSE2 devi avere almeno un Pentium 4. Le SSE sono arrivate col Pentium 3.

Comunque non vi fossilizzate con processore = versione minima per avere alcune estensioni, perché un processo moderno può benissimo implementare una vecchia ISA per particolari esigenze, come dimostra Galileo.

Vedi sopra: ci sono processi moderni che supportano vecchie ISA!

Non vi sbarazzerete così facilmente del legacy.

E comunque, dati i vostri obiettivi, è giusto che sia così.

Già!

Originariamente inviato da cdimauro

Ci sono delle schede acceleratrici nuove di pacca per Amiga che offrono 128MB di memoria DDR3, e prestazioni 200 volte superiori a un Amiga 600, per cui... si può fare. Ma non posso/voglio mettermici io.

Chissà qualche "matto" poi lo si trova che fa il porting per Amiga.

Originariamente inviato da cdimauro

Esattamente. L'unica "oddity" è rappresentata dai puntatori a 32-bit pur avendo gli interi a 64 bit "nativi", ma va bene così: tanto si usano per lo più gli interi a 32-bit, mentre i 64-bit si possono strategicamente usare per spostamenti/copie di memoria, azzeramento, ricerche, ecc.

Infatti! 32x avrebbe senso ma per ora è prematuro pensarci...

Originariamente inviato da cdimauro

Strano che ci sia tanta roba in C++ o assembly: pensavo che ci fosse soltanto una piccola parte, e il resto gestito dal backend che emette il codice binario specifico.

Guarda ha sorpreso anche me, ma è così C# almeno la versione standard per Windows fa chiamate a moltissime librerie di Windows che sono, ovviamente, scritte in C++.
Anche la classe String è piena di P/Invoke!

Cosmos è nato prima che la Microsoft iniziasse a mettere .NET su GitHub e pensasse seriamente a renderlo portabile, probabilmente usare Core.Rt semplificherebbe le cose, ma vorrebbe dire ricominciare da capo!

Originariamente inviato da cdimauro

Non credo. Probabilmente è perché con .NET non vai sempre meglio di C++ a livello di startup e/o prestazioni e/o dimensione del codice e/o consumo della memoria, e comunque non hai la flessibilità che ti offre C++ nel gestire a tuo assoluto piacimento la memoria.

Il C# usato per scrivere Midori questi problemi in realtà non li avrebbe avuti anche se alla fine mi chiedo quanto fosse "davvero" C#...

Originariamente inviato da cdimauro

Comunque C# è un gran, ottimo compromesso, e per quanto mi riguarda fate benissimo a portare avanti Cosmos

Sì la Microsoft nel copiare e migliorare Java ha fatto davvero un ottimo lavoro!

Originariamente inviato da cdimauro

Scusami, ma non avete una test suite da lanciare per verificare che quel che fate funzioni, senza dover tirar sù Bochs ogni volta?

Beh stiamo scrivendo un Kernel quindi il nostro test è lanciare un Sistema Operativo: l'IL viene compilato in assembler con IL2CPU, un'immagine ISO è creata e messa in bocca in Bochs!
Il boot è molto veloce (ed è integrato nel tasto "run" di Visual Studio) forse potrebbe aver senso scrivere il codice NASM e compilarlo "altrove", ma non sono poi come stampare il valore ottenuto

Originariamente inviato da cdimauro

Potreste realizzare un JIT-er che esegue le vecchie applicazioni x86, convertendole però in IL, fino a mappare man mano tutto il codice in IL.

Dopodiché potreste ricompilare l'applicazione x86 in qualunque architettura.

Temo sarebbe troppo lento, e poi incoraggerebbe la gente a NON scrivere codice "nativo" per Cosmos quindi...

Originariamente inviato da cdimauro

Hai detto niente. Va bene così.

Vedi io seguivo Haiku (clone di BeOS) ed era un bel progetto ben impostato, con un kernel scritto in C++ ecc...
Poi venne il "problema" di come portare applicazioni Open Source su Haiku la cui alberatura delle directory rispetto Unix / Linux aveva pure senso, prendendo ad esempio sempre Pyton vuole scrivere la configurazione in /etc mentre in Haiku andrebbe in /Sytem/cfg...
Beh invece di fare il porting "corretto" hanno creato un package manager (il diavolo!) con un filesystem virtuale in modo che Python creda di scrivere in /etc mentre invece scrive su una specie di "immagine". Follia pura!

Sono passati 3 anni e sono ancora lì a smenarsela col package manager e peggio ancora hanno perso la retro-compatibilità con BeOS: l'obiettivo per cui Haiku fu fatto.

Per me meglio riscriversi tutto che farsi "imporre" le scelte di GNU...

Originariamente inviato da cdimauro

Però mi pare che abbia delle istruzioni di FADD e FMUL che vengono eseguite a precisione inferiore a quella estesa, ma che sono più veloci. Solo che al momento non posso verificare.

Spero che ti sia stato utile. Io vado a smaltire adesso.

Grazie se le trovi mi fai un piacere!

Originariamente inviato da cdimauro

EDIT: per parlare in generale di Cosmos, ti consiglio di aprire un apposito thread.

Sì sono solo in dubbio se aprirlo in sezione Sistemi Operativi o qui in programmazione...

[cdimauro]

Originariamente inviato da fano

La penso anch'io così anche se Cosmos non diventerà mai il Linux del futuro (ma accadrà ) non sarebbe comunque tempo perso!

Mai dire mai: se il progetto e buono, e visto che è basato su .NET & compagnia, potrebbe anche ritagliarsi un futuro.

Ma non è possibile settarla a 64 Bit?

Sì:

"The precision-control (PC) field (bits 8 and 9 of the x87 FPU control word) determines the precision (64, 53, or 24 bits) of floating-point calculations made by the x87 FPU (see Table 8-2). The default precision is double extended precision, which uses the full 64-bit significand available with the double extended-precision floating-point format of the x87 FPU data registers. This setting is best suited for most applications, because it allows applications to take full advantage of the maximum precision available with the x87 FPU data registers.

The double precision and single precision settings reduce the size of the significand to 53 bits and 24 bits, respectively. These settings are provided to support IEEE Standard 754 and to provide compatibility with the specifications of certain existing programming languages. Using these settings nullifies the advantages of the double extended-precision floating-point format's 64-bit significand length. When reduced precision is specified, the rounding of the significand value clears the unused bits on the right to zeros."

Quindi butti soltanto via una cosa che è utilissima: lavorare a precisione più elevata di quanto fanno le altre FPU.

Tutte queste conversioni tra double <--> long double anche se fatte in hardware un costo lo avranno, no?

No, l'FPU impiega sempre le stesse risorse per elaborare le operazioni a qualunque precisione venga impostata. Si parla soltanto di troncamento dei risultati, e mai di prestazioni, com'è ovvio che sia.

Te ne sarei grato sta cosa dell'addizione che non addiziona mi sta facendo impazzire

Purtroppo anche rileggendo non mi pare ci sia nulla di sbagliato. Anche il dump esadecimale dei valori in extended e double mi sembrano corretti, perché usano un esponente diverso (più grande nel primo caso, ovviamente), da cui si spiegano 0xbfff80 (c'è un bit in più, quello che porta a 0x80 il terz'ultimo byte) per extended e 0xbff0 per il double.

Boh se mostra pure roba sbagliata siamo fritti! Già l'interfaccia fa alquanto schifo ci manca pure che mostri una rappresentazione errata

I dump sembrano corretti.

Sicuramente è qualche errore stupido...

Ma hai provato a eseguire passo passo il codice generato e vedere quali valori vengono referenziati, e i risultati prodotti?

Beh abbiamo le classi questa per esempio è la classe Add.cs che converte l'IL in Assembler: https://github.com/fanoI/Cosmos/blob...2CPU/IL/Add.cs.
Come puoi vedere nel caso di float / double sono ora usate le istruzione SSE (prima venivano usate solo per i float e a me questo ha rotto l'armonia ), IL2CPU è letteralmente il nostro compilatore quindi non possiamo sapere quale sarà l'architettura sulla quale andremo a girare. Certo quando metteremo su questa idea dei profili non voglio che si riempa tutto di if (FPU.isX87), if (FPU.isSSE). I mie prossimi passi (dopo che conv.r.un funziona se no, non me lo merito ):

Bene, perché si sta generando troppo spaghetti code con tutti questi if e #if.

Vedrai quanto sarà elegante quando userete il polimorfismo per gestire i backend.

1. C'è ancora qualcosa da aggiustare nel backend X#: alcune istruzioni non sono generabile senza usa Xs.Literal() altre potrebbero essere fatte meglio
2. Pensavo di creare una classe astratta / interfaccia FPU in cui mettere funzioni tipo Init(), CVT2Int(), CVT2Long(), Add()... e uno deriva da quella classe l'implementazione per FPU e SSE.

Per esempio un ipotetica SSE.Add() diventerebbe:

static void Add()
      XS.SSE2.MoveSD(XMM0, ESP, sourceIsIndirect: true);
      // Move the stack of 8 bytes to get the second double
      XS.Add(ESP, 8);
      XS.SSE2.MoveSD(XMM1, ESP, sourceIsIndirect: true);
      XS.SSE2.AddSD(XMM1, XMM0);
      XS.SSE2.MoveSD(ESP, XMM1, destinationIsIndirect: true);{
}

Esattamente, ma immagino che non abbiate nessun ottimizzatore al momento, perché il codice è abbastanza "gonfiato" da istruzioni che riproducono quello che farebbe un emulatore.

Chissà qualche "matto" poi lo si trova che fa il porting per Amiga.

Ormai ci sono pochi sviluppatori, e la comunità è pure spaccata in 4, giusto per sprecare ancora di più le poche risorse.

Guarda ha sorpreso anche me, ma è così C# almeno la versione standard per Windows fa chiamate a moltissime librerie di Windows che sono, ovviamente, scritte in C++.
Anche la classe String è piena di P/Invoke!

Cosmos è nato prima che la Microsoft iniziasse a mettere .NET su GitHub e pensasse seriamente a renderlo portabile, probabilmente usare Core.Rt semplificherebbe le cose, ma vorrebbe dire ricominciare da capo!

Quindi riscrivere tutto il C# non se ne parla. Peccato. In questo modo rimane una grossa dipendenza.

Il C# usato per scrivere Midori questi problemi in realtà non li avrebbe avuti anche se alla fine mi chiedo quanto fosse "davvero" C#...

Quindi non è C# "puro"?

Beh stiamo scrivendo un Kernel quindi il nostro test è lanciare un Sistema Operativo: l'IL viene compilato in assembler con IL2CPU, un'immagine ISO è creata e messa in bocca in Bochs!
Il boot è molto veloce (ed è integrato nel tasto "run" di Visual Studio) forse potrebbe aver senso scrivere il codice NASM e compilarlo "altrove", ma non sono poi come stampare il valore ottenuto

Io parlavo di qualcosa di diverso: unit testing. Con tanti test che vengono esercitati sul codice che avete scritto.

Niente NASM dunque, visto che rimarrebbe tutto in C#, e con la possibilità di eseguire il codice generato dal vostro IL in una sandbox e leggerne i risultati.

Temo sarebbe troppo lento, e poi incoraggerebbe la gente a NON scrivere codice "nativo" per Cosmos quindi...

Lenta sarebbe soltanto la parte di mappatura del codice x86/x64, per generare l'IL finale.

Comunque, sì: non avreste codice nativo Cosmos, ma d'altra parte Cosmos è basato su IL, e quest'ultimo potrebbe provenire da qualunque fonte.

Vedi io seguivo Haiku (clone di BeOS) ed era un bel progetto ben impostato, con un kernel scritto in C++ ecc...
Poi venne il "problema" di come portare applicazioni Open Source su Haiku la cui alberatura delle directory rispetto Unix / Linux aveva pure senso, prendendo ad esempio sempre Pyton vuole scrivere la configurazione in /etc mentre in Haiku andrebbe in /Sytem/cfg...
Beh invece di fare il porting "corretto" hanno creato un package manager (il diavolo!) con un filesystem virtuale in modo che Python creda di scrivere in /etc mentre invece scrive su una specie di "immagine". Follia pura!

Sono passati 3 anni e sono ancora lì a smenarsela col package manager e peggio ancora hanno perso la retro-compatibilità con BeOS: l'obiettivo per cui Haiku fu fatto.

Per me meglio riscriversi tutto che farsi "imporre" le scelte di GNU...

Capisco e concordo, ma più che altro quelli di Haiku avrebbero potuto dare un'occhiata all'implementazione di Windows, che di certo non ha /etc., e fare qualcosa di simile per preservare la loro identità.

Grazie se le trovi mi fai un piacere!

Vedi sopra. Inoltre ti confermo che tutte le operazioni di load comportano la conversione in extended.

Sì sono solo in dubbio se aprirlo in sezione Sistemi Operativi o qui in programmazione...

Visto che state programmando, questa sarebbe la sezione giusta.

Al più in s.o. aprite thread su discorsi generici, sulle caratteristiche che dovrebbe avere un s.o. a livello più astratto.

[fano]

Originariamente inviato da cdimauro

Mai dire mai: se il progetto e buono, e visto che è basato su .NET & compagnia, potrebbe anche ritagliarsi un futuro.

Io lo spero davvero: sono stufo di usare Linux! Windows non se ne parla perché bisogna pagare la licenza e Linux è gratis.... si peccato che se poi contiamo le giornate perse, le brutte figure con i clienti (uno l'abbiamo perso quando ha visto l'architettura accrocchiata che volevamo usare, un altro lo perderemo tra qualche mese!): i costi nascosti di Linux appunto...

Originariamente inviato da cdimauro

Sì:

"The precision-control (PC) field (bits 8 and 9 of the x87 FPU control word) determines the precision (64, 53, or 24 bits) of floating-point calculations made by the x87 FPU (see Table 8-2). The default precision is double extended precision, which uses the full 64-bit significand available with the double extended-precision floating-point format of the x87 FPU data registers. This setting is best suited for most applications, because it allows applications to take full advantage of the maximum precision available with the x87 FPU data registers.

The double precision and single precision settings reduce the size of the significand to 53 bits and 24 bits, respectively. These settings are provided to support IEEE Standard 754 and to provide compatibility with the specifications of certain existing programming languages. Using these settings nullifies the advantages of the double extended-precision floating-point format's 64-bit significand length. When reduced precision is specified, the rounding of the significand value clears the unused bits on the right to zeros."

Quindi butti soltanto via una cosa che è utilissima: lavorare a precisione più elevata di quanto fanno le altre FPU.

OK, ma d'altro canto così non rischi di ottenere risultati diversi che eseguendo lo stesso codice su ARM? O su un x64 che usa solo le istruzioni SSE? D'altro canto anche la Microsoft sembra rassegnata: aspettarsi che operazioni con FP diano li stessi risultati (anche tra versioni diverse del compilatore stesso) è impossibile!

Comunque il problema è che .NET essendo nato su x86 e forse per essere il più generici possibile internamente non opera con double, ma con un tipo chiamato F che può usere double, long double o anche (che sarebbe meglio) quad (128 bit floating point) quindi dovremmo creare un tipo F nel nostro compilatore (attualmente trattiamo double come fossero long / int64) e qual punto cadrebbe un po' il senso di aver usato SSE visto che SSE non accetta in input i FP a 80 bit saremmo sempre a fare:

1. Carica da ESP il FP di 80 bit
2. Convertilo in double e rimettilo su ESP
3. Ora fai le operazioni con SSE

Uno a questo punto potrebbe dire giustamente la FPU sarà più lenta delle SSE, ma fare tutti sti "giri" si mangia il vantaggio! Usiamo la FPU per fare tutto e via...

Originariamente inviato da cdimauro

No, l'FPU impiega sempre le stesse risorse per elaborare le operazioni a qualunque precisione venga impostata. Si parla soltanto di troncamento dei risultati, e mai di prestazioni, com'è ovvio che sia.

Ah bene mi hai tolto un dubbio...

Originariamente inviato da cdimauro

Purtroppo anche rileggendo non mi pare ci sia nulla di sbagliato. Anche il dump esadecimale dei valori in extended e double mi sembrano corretti, perché usano un esponente diverso (più grande nel primo caso, ovviamente), da cui si spiegano 0xbfff80 (c'è un bit in più, quello che porta a 0x80 il terz'ultimo byte) per extended e 0xbff0 per il double.

I dump sembrano corretti.

Questo mi consola, peccato che l'addizione non addiziona!
Altra prova che ho fatto ieri invece di passargli direttamente [valore] ho creato una label e ho fatto [valore] beh alla fine delle operazioni in ST0 c'era [valore] non la somma tra -1.0 e [valore]. Sto letteralmente impazzendo

Originariamente inviato da cdimauro

Ma hai provato a eseguire passo passo il codice generato e vedere quali valori vengono referenziati, e i risultati prodotti?

Sì abbiamo fatto partire BOCHS con il debugger e visualizzato il contenuto dei registri in tutti gli step: non c'è verso! Dopo la fadd dentro altro al registro c'è sempre la stessa bratta...

Una cosa che volevo tentare era di scrivere la costante dentro st1 e fare la somma tra st0 e st1 così anche la constante sarebbe stata in un registro, ma anche non è possibile NASM non accetta l'istruzione:

fild st1, qword [costante]
dice che gli operandi sono sbagliati!

Originariamente inviato da cdimauro

Bene, perché si sta generando troppo spaghetti code con tutti questi if e #if.

Beh gli #if false li ho messi io, per "preservare" il codice per la FPU ora che ho avuto questa idea della classe FPU metterò quel codice lì dentro.
Gli if soprattutto con i sotto if per i float non mi piacciono nemmeno a me, io avrei fatto uno switch sui tipi, tanto C# non è come il C dove lo switch non funziona quasi mai... fosse per me if / else if / else if /else non dovrebbero nemmeno esistere.

Originariamente inviato da cdimauro

Vedrai quanto sarà elegante quando userete il polimorfismo per gestire i backend.

Sì su queste cose un linguaggio ad oggetti darà il meglio!

Originariamente inviato da cdimauro

Esattamente, ma immagino che non abbiate nessun ottimizzatore al momento, perché il codice è abbastanza "gonfiato" da istruzioni che riproducono quello che farebbe un emulatore.

Sì al momento non è ottimizzato nulla appunto perché dobbiamo essere sicuri che l'assembler generato corrisponda 1 a 1 con X# poi quando saremo certi ottimizzeremo l'assembler almeno in modalità release.

Originariamente inviato da cdimauro

Ormai ci sono pochi sviluppatori, e la comunità è pure spaccata in 4, giusto per sprecare ancora di più le poche risorse.

Già davvero un peccato che la comunità Amiga abbia fatto sta fine! Il fallimento di Commodore è stata una vera catastrofe

Originariamente inviato da cdimauro

Quindi riscrivere tutto il C# non se ne parla. Peccato. In questo modo rimane una grossa dipendenza.

Non è che vorrebbe dire riscrivere tutto C#, ma magari alcuni plug sarebbe da togliere (in CoreRT stanno cercando di scrivere il più possibile C# in... C#) e altri magari da aggiungere. CoreRt essendo pensato per essere multi piattaforma ci permetterebbe di certo un'implementazione più pulita visto che sarebbe chiaro dove il codice nativo per la piattaforma va scritto: sarebbe lì dove dovremmo pluggare.
Forse in futuro lo faremo, chi lo sa... tanto prima bisogna che la Microsoft renda pronto per la produzione lo stesso CoreRt, quindi...

Ci sono classi comunque che andranno sempre pluggate per esempio Console scrive direttamente sulla porta della VGA i caratteri (sì non c'è nessun context switch tra user mode e kernel mode: non esiste l'user mode ), è totalmente diversa dalla classe Console di .NET: è uguale solo l'interfaccia!

Originariamente inviato da cdimauro

Quindi non è C# "puro"?

Non proprio leggi il blog di Joe Duffy su Midori: tanto per iniziare il compilatore faceva stack escape analisys e si permetteva di allocare oggetti nello stack cosa che nemmeno C++/CLI ha mai osato fare (finge soltanto usa l'heap come fosse uno stack)!
Poi hanno esteso la sintassi per passare oggetti come rifermento (non ho ben capito quella parte), introdussero async con una sintassi diverso dal C# normale (ma Midori l'aveva prima, C# l'ha fatta dopo ed è pure più inefficiente!)...

Originariamente inviato da cdimauro

Io parlavo di qualcosa di diverso: unit testing. Con tanti test che vengono esercitati sul codice che avete scritto.

Niente NASM dunque, visto che rimarrebbe tutto in C#, e con la possibilità di eseguire il codice generato dal vostro IL in una sandbox e leggerne i risultati.

Beh abbiamo una unit test:
https://github.com/CosmosOS/Cosmos/t...iler.Tests.Bcl

dentro double.cs ci sono le operazioni sui double se usassimo il .NET runtime beh testeremmo quello: è ovvio che il vero C# sa convertire un ulong in double

Comunque venendo da Linux lavorare su questo progetto è per me qualcosa di rivoluzionario! Cose che per voi magari saranno banali a me mi fanno rizzare i peli sulle braccia: Visual Studio che prevede il codice prima che abbia finito di scriverlo, che capisce che NON compilerà senza manco compilarlo (X# non so come sia possibile ma ha iniziato ad indicarmi che stavo sbagliando! "Volevi dire <destinationIndirect>? Non può essere <sourceIndirect> perché...), le unit test e soprattutto AppVoyer!

Originariamente inviato da cdimauro

Lenta sarebbe soltanto la parte di mappatura del codice x86/x64, per generare l'IL finale.

Comunque, sì: non avreste codice nativo Cosmos, ma d'altra parte Cosmos è basato su IL, e quest'ultimo potrebbe provenire da qualunque fonte.

Quindi sarebbe una sorta di Wine.net? Perché tutto Windows andrebbe emulato o pensi a un target Cosmos / x86?
Certo come dovremo per esempio quando faremo il browser convertire javascript in IL a runtime potremmo farlo anche per x86, ma non lo so credo non lo faremo per motivi "politici".

Originariamente inviato da cdimauro

Capisco e concordo, ma più che altro quelli di Haiku avrebbero potuto dare un'occhiata all'implementazione di Windows, che di certo non ha /etc., e fare qualcosa di simile per preservare la loro identità.

Python era ovviamente solo un esempio, tutte le applicazioni GNU hanno quelle orride directory hardcoded per Windows il porting l'hanno fatto (anche se io ricordo anni fa di aver installato un qualcosa di GNU su Windows e di essermi trovato un C:/etc pieno di bratta), loro hanno deciso di usare questo scorciatoia: hanno perso la loro strada!
E dire che c'era una soluzione migliore da cui prendere esempio i bundle di Apple e invece cosa vanno a copiare? Il package manager di Linux!

Che poi - sarò strano io - ma cosa c'è di male a scaricare un installer dal sito del produttore e installarlo? Boh mai capito...

Originariamente inviato da cdimauro

Vedi sopra. Inoltre ti confermo che tutte le operazioni di load comportano la conversione in extended.

Visto che state programmando, questa sarebbe la sezione giusta.

Al più in s.o. aprite thread su discorsi generici, sulle caratteristiche che dovrebbe avere un s.o. a livello più astratto.

OK vedo se riesco ad aprire un bel thread nel week end conta sulla vostra partecipazione!

[cdimauro]

Originariamente inviato da fano

OK, ma d'altro canto così non rischi di ottenere risultati diversi che eseguendo lo stesso codice su ARM? O su un x64 che usa solo le istruzioni SSE? D'altro canto anche la Microsoft sembra rassegnata: aspettarsi che operazioni con FP diano li stessi risultati (anche tra versioni diverse del compilatore stesso) è impossibile!

Mi pare normale che ci sia un margine di tolleranza, visto che parliamo di numeri in virgola mobile.

Non ti preoccupare di questo, ma se puoi usare la precisione massima senza intaccare le prestazioni, approfittane.

Comunque il problema è che .NET essendo nato su x86 e forse per essere il più generici possibile internamente non opera con double, ma con un tipo chiamato F che può usere double, long double o anche (che sarebbe meglio) quad (128 bit floating point) quindi dovremmo creare un tipo F nel nostro compilatore (attualmente trattiamo double come fossero long / int64) e qual punto cadrebbe un po' il senso di aver usato SSE visto che SSE non accetta in input i FP a 80 bit saremmo sempre a fare:

1. Carica da ESP il FP di 80 bit
2. Convertilo in double e rimettilo su ESP
3. Ora fai le operazioni con SSE

Uno a questo punto potrebbe dire giustamente la FPU sarà più lenta delle SSE, ma fare tutti sti "giri" si mangia il vantaggio! Usiamo la FPU per fare tutto e via...

Al momento sì, ma mi aspetto che l'uso di un tipo anziché un altro derivi dalla scelta fatta dal programmatore: se uso un single, non mi aspetto che venga poi internamente generato codice binario che usi double o addirittura extended.

extended dovrebbe essere usato soltanto se il programmatore l'ha appositamente selezionato, oppure implicitamente & internamente nel caso in cui fosse disponibile soltanto l'FPU x87.

Questo mi consola, peccato che l'addizione non addiziona!
Altra prova che ho fatto ieri invece di passargli direttamente [valore] ho creato una label e ho fatto [valore] beh alla fine delle operazioni in ST0 c'era [valore] non la somma tra -1.0 e [valore]. Sto letteralmente impazzendo

Sì abbiamo fatto partire BOCHS con il debugger e visualizzato il contenuto dei registri in tutti gli step: non c'è verso! Dopo la fadd dentro altro al registro c'è sempre la stessa bratta...

Una cosa che volevo tentare era di scrivere la costante dentro st1 e fare la somma tra st0 e st1 così anche la constante sarebbe stata in un registro, ma anche non è possibile NASM non accetta l'istruzione:

fild st1, qword [costante]
dice che gli operandi sono sbagliati!

Onestamente non so cos'altro pensare. Ci dev'essere per forza qualche errore che al momento sfugge, perché non è che siete i primi a generare codice per x87: lo fa persino WinUAE di recente, e pure in modalità x64!

Beh gli #if false li ho messi io, per "preservare" il codice per la FPU ora che ho avuto questa idea della classe FPU metterò quel codice lì dentro.
Gli if soprattutto con i sotto if per i float non mi piacciono nemmeno a me, io avrei fatto uno switch sui tipi, tanto C# non è come il C dove lo switch non funziona quasi mai... fosse per me if / else if / else if /else non dovrebbero nemmeno esistere.

Non mi piacciono nemmeno gli switch: sono if mascherati.

Non proprio leggi il blog di Joe Duffy su Midori: tanto per iniziare il compilatore faceva stack escape analisys e si permetteva di allocare oggetti nello stack cosa che nemmeno C++/CLI ha mai osato fare (finge soltanto usa l'heap come fosse uno stack)!
Poi hanno esteso la sintassi per passare oggetti come rifermento (non ho ben capito quella parte), introdussero async con una sintassi diverso dal C# normale (ma Midori l'aveva prima, C# l'ha fatta dopo ed è pure più inefficiente!)...

Capito. Mi sa che devo buttarci un occhio, ma sono quasi sempre a corto di tempo.

Beh abbiamo una unit test:
https://github.com/CosmosOS/Cosmos/t...iler.Tests.Bcl

Allora usatela anche e soprattutto per il JITter, altrimenti diventerete matti.

Comunque venendo da Linux lavorare su questo progetto è per me qualcosa di rivoluzionario! Cose che per voi magari saranno banali a me mi fanno rizzare i peli sulle braccia: Visual Studio che prevede il codice prima che abbia finito di scriverlo, che capisce che NON compilerà senza manco compilarlo (X# non so come sia possibile ma ha iniziato ad indicarmi che stavo sbagliando! "Volevi dire <destinationIndirect>? Non può essere <sourceIndirect> perché...), le unit test e soprattutto AppVoyer!

Già. Siamo ben abituati. Ma AppVoyer non lo conosco, anche se il nome è tutto un "programma".

Quindi sarebbe una sorta di Wine.net?

Non esattamente. Wine mappa le API di Windows su quelle Linux, mentre la mia idea è di mappare gli opcode x86/x64 in opcode IL. In questo modo non è necessario ogni volta decodificare queste istruzioni per i blocchi di codice: si prende l'IL conosciuto e si genera direttamente e immediatamente codice binario per la specifica piattaforma.

Il tutto fino a mappare l'intero codice in IL, e a questo punto si potrebbe anche andare di compilazione AoT in un colpo solo, togliendo di mezzo il runtime/JITter.

Perché tutto Windows andrebbe emulato o pensi a un target Cosmos / x86?

Beh, le chiamate alle API Windows andrebbero ovviamente rimappate in chiamate alle API Cosmos.

L'architettura al momento lasciala perdere, perché riguarda il JITter.

Certo come dovremo per esempio quando faremo il browser convertire javascript in IL a runtime potremmo farlo anche per x86, ma non lo so credo non lo faremo per motivi "politici".

Per Javascript è abbastanza diverso, visto che non ha bytecode di default, ma solo il sorgente.

OK vedo se riesco ad aprire un bel thread nel week end conta sulla vostra partecipazione!

Metti il link.

[GTKM]

Ma ancora la FADD non "FADDa"?

Deve esserci qualcosa che non quadra: un'istruzione che viene eseguita dalla CPU ma che, contemporaneamente, non viene eseguita. Questa è una rivoluzione

[fano]

Ho fatto un'ulteriore prova:

          // Save the high part of the ulong in EAX (we cannot move all of ESP as it has 64 bit size)
          XS.Set(EAX, ESP, sourceIsIndirect: true, sourceDisplacement: 4);
          XS.FPU.IntLoad(ESP, isIndirect: true, size: RegisterSize.Long64);
          XS.Test(EAX, EAX);
          XS.Jump(ConditionalTestEnum.NotSign, LabelSign_Bit_Unset);
          XS.Set(ECX, 0x5F800000);
          XS.FPU.IntLoad(ECX, isIndirect: true, size: RegisterSize.Long64);
          XS.LiteralCode(@"fadd st1");
          XS.Label(LabelSign_Bit_Unset);
          XS.FPU.FloatStoreAndPop(ESP, isIndirect: true, size: RegisterSize.Long64);

L'idea è di provare a mettere la "constante" in un altro registro della FPU e fare la somma tra quelli peccato che:

1. 'fild' non accetta un valore come sorgente, ma solo memoria ecco perché scrivo su ECX e poi da lì sulla FPU
2. 'fild' non accetta un 'destinatario' è sempre implicitamente ST0, il valore che c'era prima non viene sovrascritto, ma spostato su ST1...

...almeno questo in teoria quello che fa a me - a sto punto perché gli sono antipatico - è di ri-copiare ST0 su ST1 (corretto), ma in ST0 non viene messo il nuovo valore.
La fadd poi funziona, ma ovviamente il valore è -2 e ci faccio le uova con -2 io volevo 18 miliardi e passa

[||ElChE||88]

Ma sbaglio o stai settando il valore di ecx a quella costante e poi usandolo come se fosse un indirizzo di memoria (isIndirect: true)?

fild((QWORD *)0x5F800000)

[fano]

Originariamente inviato da ||ElChE||88

Ma sbaglio o stai settando il valore di ecx a quella costante e poi usandolo come se fosse un indirizzo di memoria (isIndirect: true)?

fild((QWORD *)0x5F800000)

Sì perché fild accetta solo "memoria" in input, avevo il dubbio che andasse messo nello stack (quindi in ESP) e poi copiato da lì, ma in quel caso ottenevo la corruzione dello stack. D'altra parte se lo metto in ECX non è "memoria" e mi pare che me lo facesse fare solo come ptr...

Purtroppo NASM è molto meno avanzato di MASM per esempio io non ho ancora capito come tradurre questa istruzione in NASM correttamente ed è lì che sbaglio di certo!

fadd ds:uint64add

io ho fatto così perché NASM non accetta un valore come operando (un bug?):

fadd qword [0x5F800000]

Qualche idea?
Grazie!

P.S. No, non è un baco di NASM, ma un'estensione di MASM:
http://www.felixcloutier.com/x86/FADD:FADDP:FIADD.html
http://www.ray.masmcode.com/tutorial/fpuchap8.htm#fadd
come la emulo con NASM?

[||ElChE||88]

Perché un estensione? È questo:

DC /0	FADD m64fp	Valid	Valid	Add m64fp to ST(0) and store result in ST(0).

Io sarei curioso di vedere l'assembly generato da X#.

[fano]

Ma 'm64fp' non vuol dire 'm'[emory] quindi un puntatore?

Stasera posto il NASM generato a partire da X#...

[GTKM]

Originariamente inviato da fano

Ma 'm64fp' non vuol dire 'm'[emory] quindi un puntatore?

Stasera posto il NASM generato a partire da X#...

m64fp credo indichi un indirizzo di memoria a 64 bit, sì.

[fano]

Originariamente inviato da ||ElChE||88

Io sarei curioso di vedere l'assembly generato da X#.

Eccolo:

; Conv_R_Un
SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.0B: ;Asm
			mov dword EAX, [ESP + 4]

SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.0C: ;Asm
			fild qword [ESP]

SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.0D: ;Asm
			test dword EAX, EAX

SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.0E: ;Asm
			JNS near SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.LabelSign_Bit_Unset

SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.0F: ;Asm
			mov dword ECX, 0x5F800000
		SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.10: ;Asm
			fild qword [ECX]

SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.11: ;Asm
			fadd st1

SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.LabelSign_Bit_Unset:

SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.12: ;Asm
			fstp qword [ESP]

[||ElChE||88]

È sbagliato, sta usando 0x5F800000 come se fosse un puntatore.

Originariamente inviato da fano

Ma 'm64fp' non vuol dire 'm'[emory] quindi un puntatore?

Si, e infatti ds:uint64add è un puntatore ad una valore nel segmento dati. Ci sara un modo per definire un valore nel genere in NASM, no? Se non c'è (molto improbabile) usa lo stack e mov o push.

[fano]

E' praticamente la prima versione l'istruzione fadd viene ignorata!

	
SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.00: ;Asm
          mov dword EAX, [ESP + 4]

SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.01: ;Asm
	  fild qword [ESP]

SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.02: ;Asm
          test dword EAX, EAX

SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.03: ;Asm
          JNS near SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.LabelSign_Bit_Unset
	
SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.04: ;Asm
         fadd dword [__ulong2double_const4]

SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.LabelSign_Bit_Unset:

SystemVoidCosmosCompilerTestsBclSystemDoubleTestExecute.IL_0208.05: ;Asm
         fstp qword [ESP]

la costante è definita così:
__ulong2double_const4 db 95, 128, 0, 0, 0, 0, 0, 0

avevo provato a definirla come intero quindi così, ma non cambiava nulla era come se ci fosse 0:
__ulong2double_const4 db 0x5F800000

[||ElChE||88]

Sono entrambe sbagliate.
O usi

__ulong2double_const4 db 0, 0, 95, 128

o

__ulong2double_const4 dd 5F800000h

[fano]

Nulla da fare l'fadd è ignorata!

C'è qualche trusco da fare per forzare sta FPU a fare le addizioni? Noi la inizializziamo semplicemente con finit bisogna fare altro?

[cdimauro]

Sì, basta la finit.

Puoi provare a mettere una costante con byte completamente casuali (e cambiati a ogni generazione), e vedere cosa ottieni?

A parte questo, sarebbe utile vedere il disassembly del binario generato. Quindi non quello di X#, ma proprio i byte generati e poi disassemblati con qualche tool.

[AnonimoVeneziano]

Originariamente inviato da fano

Dopo aver hexpumpato (?) il long double -1.0 dal C e aver ottenuto questo schifo:

sizeof(long double) 12
-1 as long double '0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0xff 0xbf 0x00 0x00 '
sizeof(double) 8
-1 as double '0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0xbf '

mentre BOCHS mi mostrava sta roba:

FP7 ST0(v): raw 0xbfff:8000000000000000 (-1,0000000000) (NORMAL)

I byte sono in posizioni diverse (endianess?) ma sembra il valore che vedo nel long double quindi l'FPU è a 80 Bit!

Quindi la costante è errata ed è per questo che non va una mazza?
E soprattutto è giusto avere l'FPU a 80 Bit o è meglio averla settata come 64 bit (così da evitare continue conversioni?).

Anche la Microsoft non sembra convinta:



Perché questo? "Only at excessive cost in performance can such hardware architectures be made to perform floating-point operations with less precision"
non posso settare la FPU a 64 Bit alla partenza e dimenticarmene? Sarebbe più lenta? Padda gli altri 4 byte con 0 ogni volta?

A questo solo il nostro insider Intel può rispondere mi sa

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.