[NASM x86] Convertire uint64 in double

[fano]

Ciao a tutti,

come potete vedere nella mia firma sto scrivendo un sistema operativo: Cosmos!

E' scritto in C# e per certi versi è la versione Open Source dei progetti di ricerca Singularity e Midori.
La differenza rispetto a un sistema operativo classico è che il runtime .NET è integrato nel Sistema Operativo stesso e tutte le istruzioni IL devono essere convertite in assembler prima ancora di creare il kernel.

E' un po di tempo che sto impazzendo con l'instuzione conv.r.un che prende in input un uint32 o un uint64 e lo converte in double. Purtroppo non esiste né per la FPU x87 né SSE un'istruzione diretta per effettuare questa conversione quindi fa fatta "a mano".

Questo è quello che ho cercato di fare io:

  # in ESP c'è un ulong, prendiamo la parte alta e la mettiamo in EAX 
  mov EAX, [ESP + 32]
  # Convertiamo l'ulong in double e salviamo in ST0
  fild  qword ptr [ESP]
  # Shift a destra di EAX fino al byte 31
  shr EAX, 31
  # Confrontiamo EAX con 0
  cmp EAX, 0
  # Se è 0 abbiamo finito saltiamo in LabelSign_Bit_Unset
  jpe LabelSign_Bit_Unset
  # Se è 1 dobbiamo togliere il segno dal double
  fadd  dword ptr __ulong2double_const2
  # salviamo il risultato in ESP
  LabelSign_Bit_Unset:
  fstp ESP

L'idea di questo codice è convertiamo l'ulong con fild come se fosse un normale long e poi se c'era il segno (un 1 nel 31° bit) viene 'fixato' con fadd con un'opportuna costante... __ulong2double_const2.
Il problema è proprio che non trovo qual è questa constante per ora ho provato con 0x0000000000405BC0 (c'è una matematica complicatissima dietro, ma ve la evito ), ma non va una fava

Idee? Soluzioni? Insulti?

[||ElChE||88]

Non conosco NASM ma in MASM dovrebbe essere qualcosa del genere:

.386
.model flat
.data
uint64add dd 5F800000h
.code
mov eax, dword ptr [esp+4]
fild qword ptr [esp]
test eax, eax
jns short isuint32
fadd ds:uint64add
isuint32:
fstp qword ptr [esp]
end

[cdimauro]

Originariamente inviato da fano

E' un po di tempo che sto impazzendo con l'instuzione conv.r.un che prende in input un uint32 o un uint64 e lo converte in double. Purtroppo non esiste né per la FPU x87 né SSE un'istruzione diretta per effettuare questa conversione quindi fa fatta "a mano".
Idee? Soluzioni? Insulti?

Per x87 t'hanno già risposto, mentre per SSE dovresti aprire il manuale dell'architettura x86 e cercare fra le istruzioni di conversione, perché ne troverai due che sono utili per il tuo scopo:

CVTSI2SD xmm, r/m32   ; Da sint32 a double
CVTSI2SD xmm, r/m64   ; Da sint64 a double

Ovviamente sono con segno, per cui devi utilizzare degli accorgimenti visto che hai uint32 e uint64:
- se l'MSB del valore intero è zero, puoi convertirlo così com'è;
- altrimenti rimuovi l'MSB, lo converti in double, e poi gli aggiungi 2^31 o 2^63 (con opportune costanti double).

[||ElChE||88]

.386
.mmx
.xmm
.model flat
.data
align 16
xmm_sub dd 0, 43300000h, 0, 45300000h
align 16
xmm_interleave dd 43300000h, 45300000h, 0, 0
.code
movq xmm1, qword ptr [esp]
punpckldq xmm1, xmmword ptr [ds:xmm_interleave]
subpd xmm1, xmmword ptr [ds:xmm_sub]
pshufd xmm0, xmm1, 00011110b
addpd xmm0, xmm1
movq qword ptr [esp], xmm0
end

[fano]

Originariamente inviato da ||ElChE||88

Non conosco NASM ma in MASM dovrebbe essere qualcosa del genere:

.386
.model flat
.data
uint64add dd 5F800000h
.code
mov eax, dword ptr [esp+4]
fild qword ptr [esp]
test eax, eax
jns short isuint32
fadd ds:uint64add
isuint32:
fstp qword ptr [esp]
end

Questa è la tua versione (credo) tradotta in NASM / x86:

       mov dword EAX, [ESP + 4]
       fild qword [ESP]
       test dword EAX, EAX
       JNS near LabelSign_Bit_Unset
       fadd qword [0x5F800000]
       LabelSign_Bit_Unset:
       fstp dword [ESP]

purtroppo non funziona! Il valore ottenuto non ha proprio senso se debbo credere a Cosmos 0x0000FFFF?

@cdimauro
Attualmente il compilatore di Cosmos ha come target x86 a 32 Bit anch'io speravo di poter usare SSE per tutto, ma pare che quando si opera sui long non sia possibile, l'istruzione CVTSI2SD opera sempre su sint32, infatti quella che dovrei usare è CTVSQ2SD, ma esiste solo su IA64!
O almeno così questi signori mi hanno convinto:

http://forum.osdev.org/viewtopic.php?f=1&t=30324

La seconda versione che usa punpckldq mi spaventa un po' avevo visto una versione simile usata da Clang, ma sinceramente non so proprio come tradurla in NASM.

L'idea di usare NASM che mi pare non usi nessuno per creare l'assembler mi sembra una scelta proprio sbagliata! Lavoriamo su Windows con Visual Studio (quindi no per ora di creare Cosmos su Linux non ce ne frega nulla) perché non usare l'assembler della Microsoft MASM che sembra molto più avanzato? E soprattutto il cui assembler è molto più conosciuto? E che posso chiedere a Visual Studio di mostrarmi usando i breakpoint?

Comunque stiamo provando a scrivere il nostro High Level Assembler che sarà integrato con C# e che si chiama X# (X sta per X86, in futuro esisterà anche A# per ARM!), infatti io non scrivo NASM direttamente, ma questo:

      // 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);
      // Get its highest bit to check if the value was signed or unsigned
      //XS.ShiftRight(EAX, 31);
      //XS.Compare(EAX, 0x00);
      //XS.Jump(ConditionalTestEnum.Equal, LabelSign_Bit_Unset);
      XS.Test(EAX, EAX);
      XS.Jump(ConditionalTestEnum.NotSign, LabelSign_Bit_Unset);
      //XS.LiteralCode(@"fadd qword [__ulong2double_const3]");
      XS.LiteralCode(@"fadd qword [0x5F800000]");
      XS.Label(LabelSign_Bit_Unset);
      XS.FPU.FloatStoreAndPop(ESP, isIndirect: true, size:RegisterSize.Long64);

che viene poi trancompilato in NASM e "ibridato" con il kernel!

Ma il vero X# è ancora meglio:
https://en.wikipedia.org/wiki/X_Sharp
ma dobbiamo studiare come embeddarlo dentro a C#...

[||ElChE||88]

Originariamente inviato da fano

purtroppo non funziona! Il valore ottenuto non ha proprio senso se debbo credere a Cosmos 0x0000FFFF?

Strano, a me funziona. Nella tua versione NASM il fstp è sbagliato (dword invece di qword), però ho visto che nella versione X# è segnato giustamente come qword.

Originariamente inviato da fano

@cdimauro
Attualmente il compilatore di Cosmos ha come target x86 a 32 Bit anch'io speravo di poter usare SSE per tutto, ma pare che quando si opera sui long non sia possibile, l'istruzione CVTSI2SD opera sempre su sint32, infatti quella che dovrei usare è CTVSQ2SD, ma esiste solo su IA64!

L'alternativa è usarne 2:

.386
.mmx
.xmm
.model flat
.data
dq_add dq 0
dq_mul dq 41F0000000000000h
.code
mov eax, dword ptr [esp]
cvtsi2sd xmm0, eax
shr eax, 1Fh
addsd xmm0, qword ptr [ds:dq_add+eax*8]
mov eax, dword ptr [esp+4]
test eax, eax
jz short store
cvtsi2sd xmm1, eax
shr eax, 1Fh
addsd xmm1, qword ptr [ds:dq_add+eax*8]
mulsd xmm1, qword ptr [ds:dq_mul]
addsd xmm0, xmm1
store:
movq qword ptr [esp], xmm0
end

[fano]

Originariamente inviato da ||ElChE||88

Strano, a me funziona. Nella tua versione NASM il fstp è sbagliato (dword invece di qword), però ho visto che nella versione X# è segnato giustamente come qword.

Grazie! Sì c'era un errore in X#... il backend ignorava il parametro passato e credo dword sia messo di default, questo avrebbe dovuto risolvere tutto ed infatti ero tutto emozionato (erto ho pensato prendevo solo metà del double...
) ed invece no
Ho pensato che fosse il little endian a fregarmi e così ho invertito la tua constante che è diventata 0x00000805F, beh il risultato ottenuto è F0BF, ma dovrebbe essere F043.
Il valore da me usato è uno che sicuramente dovrebbe risultare segnato: -1 che visto come ulong è un numeraccio: 18446744073709551615 (in hex è ovviamente 8 volte F) eppure sembra che EAX sia non segnato visto che la fadd non ha effetto! Non capisco...

Originariamente inviato da ||ElChE||88

L'alternativa è usarne 2:

.386
.mmx
.xmm
.model flat
.data
dq_add dq 0
dq_mul dq 41F0000000000000h
.code
mov eax, dword ptr [esp]
cvtsi2sd xmm0, eax
shr eax, 1Fh
addsd xmm0, qword ptr [ds:dq_add+eax*8]
mov eax, dword ptr [esp+4]
test eax, eax
jz short store
cvtsi2sd xmm1, eax
shr eax, 1Fh
addsd xmm1, qword ptr [ds:dq_add+eax*8]
mulsd xmm1, qword ptr [ds:dq_mul]
addsd xmm0, xmm1
store:
movq qword ptr [esp], xmm0
end

A questo punto però la domanda sorge spontanea è davvero più veloce che usare la FPU x87? Sono molte più istruzioni, ci sono anche delle moltiplicazioni, c'è comunque un branch!

La vera soluzione sarebbe usare AVX, ma già abbiamo tagliato via tutto quello che c'è prima del PIII usando SSE2 per avere le istruzioni di conversione
int <--> double così funzioneremmo solo su PC dal 2007 in poi

[||ElChE||88]

Esattamente che valori hai in input e output?

[fano]

In input ho -1 che però espresso in ulong è 18446744073709551615 il risultato atteso è un double il cui valore in hex è F043 (ovviamente stampato come double è 18446744073709551615.0) invece ottengo F0BF (-1.0 come double). Ho pensato di usare -1 come "caso più semplice" ho un bit pattern con tutti 1 e invece il test dice che ho uno 0 in MSB... non ha senso!

Se potessi provare anche tu mi fai un piacere...

Sono ormai quasi convinto che è un bug o di NASM (che genera x86 errato) o di Bochs che non setta correttamente EAX!

[cdimauro]

Originariamente inviato da fano

@cdimauro
Attualmente il compilatore di Cosmos ha come target x86 a 32 Bit anch'io speravo di poter usare SSE per tutto, ma pare che quando si opera sui long non sia possibile, l'istruzione CVTSI2SD opera sempre su sint32, infatti quella che dovrei usare è CTVSQ2SD, ma esiste solo su IA64!

Originariamente inviato da fano

A questo punto però la domanda sorge spontanea è davvero più veloce che usare la FPU x87? Sono molte più istruzioni, ci sono anche delle moltiplicazioni, c'è comunque un branch!

La vera soluzione sarebbe usare AVX, ma già abbiamo tagliato via tutto quello che c'è prima del PIII usando SSE2 per avere le istruzioni di conversione
int <--> double così funzioneremmo solo su PC dal 2007 in poi

Perdonami per la critica, ma onestamente ritengo sia del tutto insensato avere come target x86 a 32-bit, quando è da 14 anni ormai che circolano macchine a 64 bit, e quelle strettamente a 32 bit ormai non so nemmeno se siano commercializzate.

Se volete sperimentare coi soli puntatori a 32-bit, allora utilizzate l'ABI x32, che gira sempre in modalità x64 e, quindi, ne consente di sfruttare tutti i benefici, ma mantiene soltanto i puntatori a 32 bit, per alleggerire la pressione su data cache et similia.

Comunque stiamo provando a scrivere il nostro High Level Assembler che sarà integrato con C# e che si chiama X# (X sta per X86, in futuro esisterà anche A# per ARM!), infatti io non scrivo NASM direttamente, ma questo:

      // 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);
      // Get its highest bit to check if the value was signed or unsigned
      //XS.ShiftRight(EAX, 31);
      //XS.Compare(EAX, 0x00);
      //XS.Jump(ConditionalTestEnum.Equal, LabelSign_Bit_Unset);
      XS.Test(EAX, EAX);
      XS.Jump(ConditionalTestEnum.NotSign, LabelSign_Bit_Unset);
      //XS.LiteralCode(@"fadd qword [__ulong2double_const3]");
      XS.LiteralCode(@"fadd qword [0x5F800000]");
      XS.Label(LabelSign_Bit_Unset);
      XS.FPU.FloatStoreAndPop(ESP, isIndirect: true, size:RegisterSize.Long64);

che viene poi trancompilato in NASM e "ibridato" con il kernel!

Ma il vero X# è ancora meglio:
https://en.wikipedia.org/wiki/X_Sharp
ma dobbiamo studiare come embeddarlo dentro a C#...

Un assembler di alto livello, insomma. Ne avevo realizzato uno con concetti simili una ventina d'anni fa, per 65C02 e successivamente per PIC Microchip.

[fano]

Originariamente inviato da cdimauro

Perdonami per la critica, ma onestamente ritengo sia del tutto insensato avere come target x86 a 32-bit, quando è da 14 anni ormai che circolano macchine a 64 bit, e quelle strettamente a 32 bit ormai non so nemmeno se siano commercializzate.

Anche Galileo e Edison sono a 64 Bit? Il target vero di Cosmos è il mercato embedded il concetto rispetto a Linux è inverso lì prendi un sistema pensato per fare da server e lo "violenti" togliendone il 90% fino ad ottenere un OS più o meno funzionante da mettere dentro un PC embedded (o uno smartphone che poi è lo stesso ormai!), Cosmos invece di suo è solo gestione memoria ed I/O e tu aggiungi il resto!

Originariamente inviato da cdimauro

Se volete sperimentare coi soli puntatori a 32-bit, allora utilizzate l'ABI x32, che gira sempre in modalità x64 e, quindi, ne consente di sfruttare tutti i benefici, ma mantiene soltanto i puntatori a 32 bit, per alleggerire la pressione su data cache et similia.

Comunque credo usino IA32 perché forse è quello più semplice per iniziare c'è poi - ovviamente - l'intenzione di fare una versione per IA64... e beh in futuro anche per ARM! Come tutti i sistemi operativi che si rispettano sarà portabile, ma questa volta le applicazioni una volta scritte gireranno su qualunque CPU.

Sì x32 è una strada che mi piacerebbe percorrere anche se non ho capito se in ambito .NET è la stessa cosa del flag /prefer32. Di certo "sprecare" memoria per i puntatori a 64 bit quando le applicazioni che hanno bisogno di più > 4 GB di memoria si contano sulle dita di una mano pare un po' un spreco. Sì un kernel a 64 (o 32x) che permette di far girare le applicazioni che lo richiedono a 32 Bit o 64 Bit sarebbe l'ideale!
Questo è quello che mi eccita di più di questo progetto non abbiamo 30 anni di retrocompatibilità tra le scatole e possiamo pensare a cose veramente nuove. Per esempio 32x che a me pare un'ottima idea su Linux non se lo è c*gato nessuno perché c'erano i 30 di x86 e visto che era incompatibile la gente si è chiesta qual è il senso?

Originariamente inviato da cdimauro

Un assembler di alto livello, insomma. Ne avevo realizzato uno con concetti simili una ventina d'anni fa, per 65C02 e successivamente per PIC Microchip.

Fico! Come si chiamava?

[cdimauro]

Originariamente inviato da fano

Anche Galileo e Edison sono a 64 Bit? Il target vero di Cosmos è il mercato embedded il concetto rispetto a Linux è inverso lì prendi un sistema pensato per fare da server e lo "violenti" togliendone il 90% fino ad ottenere un OS più o meno funzionante da mettere dentro un PC embedded (o uno smartphone che poi è lo stesso ormai!), Cosmos invece di suo è solo gestione memoria ed I/O e tu aggiungi il resto!

OK, in questo caso cambia tutto... ma anche per te.

Galileo supporta soltanto l'ISA Pentium, e dunque hai soltanto l'FPU e nessuna unità SIMD (nemmeno MMX).

Con Edison ti va molto meglio, perché l'ISA Silvermont, e dunque fino alle SSE4.2. Ma niente AVX, purtroppo. Solo che non so se specificamente per Edison sia disponibile anche la modalità a 64 bit.

Comunque credo usino IA32 perché forse è quello più semplice per iniziare c'è poi - ovviamente - l'intenzione di fare una versione per IA64... e beh in futuro anche per ARM! Come tutti i sistemi operativi che si rispettano sarà portabile, ma questa volta le applicazioni una volta scritte gireranno su qualunque CPU.

Chiaro. Quindi dovrà girare anche sul 6510 del Commodore64.

Sì x32 è una strada che mi piacerebbe percorrere anche se non ho capito se in ambito .NET è la stessa cosa del flag /prefer32.

Non credo che .NET la supporti. AFAIK è solo disponibile per Linux.

Ovviamente nessuno t'impedisce di realizzare un backend .NET per x32, magari partendo da quello x64.

Di certo "sprecare" memoria per i puntatori a 64 bit quando le applicazioni che hanno bisogno di più > 4 GB di memoria si contano sulle dita di una mano pare un po' un spreco. Sì un kernel a 64 (o 32x) che permette di far girare le applicazioni che lo richiedono a 32 Bit o 64 Bit sarebbe l'ideale!
Questo è quello che mi eccita di più di questo progetto non abbiamo 30 anni di retrocompatibilità tra le scatole e possiamo pensare a cose veramente nuove. Per esempio 32x che a me pare un'ottima idea su Linux non se lo è c*gato nessuno perché c'erano i 30 di x86 e visto che era incompatibile la gente si è chiesta qual è il senso?

Esattamente. Ma con un runtime .NET il discorso cambia completamente, e il supporto sarebbe trasparente.

Fico! Come si chiamava?

Galileo, ma non l'ho mai rilasciato in giro: l'ho creato per un paio di progetti a cui ho lavorato.

[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

[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

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?

Originariamente inviato da cdimauro

OK, in questo caso cambia tutto... ma anche per te.

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# ).

Originariamente inviato da cdimauro

Galileo supporta soltanto l'ISA Pentium, e dunque hai soltanto l'FPU e nessuna unità SIMD (nemmeno MMX).

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!

Originariamente inviato da cdimauro

Con Edison ti va molto meglio, perché l'ISA Silvermont, e dunque fino alle SSE4.2. Ma niente AVX, purtroppo. Solo che non so se specificamente per Edison sia disponibile anche la modalità a 64 bit.

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.
Abbiamo valutato che la compatibilità con i processori troppo vecchi non avesse alcun senso per un OS del 2016 inoltrato!

Originariamente inviato da cdimauro

Chiaro. Quindi dovrà girare anche sul 6510 del Commodore64.

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

Originariamente inviato da cdimauro

Non credo che .NET la supporti. AFAIK è solo disponibile per Linux.

Ovviamente nessuno t'impedisce di realizzare un backend .NET per x32, magari partendo da quello x64.

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. 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!

Originariamente inviato da cdimauro

Esattamente. Ma con un runtime .NET il discorso cambia completamente, e il supporto sarebbe trasparente.

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!

@GTKM
Magari! Saresti solo che il benvenuto.

[GTKM]

Originariamente inviato da fano

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?

Se la FADD viene eseguita ma nella destinazione il valore non cambia, allora sì, credo sia perché uno degli addendi è 0x0000.

Originariamente inviato da fano

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!

Forse non ho capito. Essendo tutto compilato, potete solo scegliere quale blocco di codice eseguire in base alle istruzioni supportate dalla CPU, no? Ma l'assembly deve già essere stato generato in fase di compilazione.

Originariamente inviato da fano

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.
Abbiamo valutato che la compatibilità con i processori troppo vecchi non avesse alcun senso per un OS del 2016 inoltrato!

Secondo me bisogna guardare semplicemente a quali sono le CPU più presenti nel mercato embedded oggi. Quindi credo che andare ancora più indietro nel tempo non abbia molto senso. Per il resto, essendo open source, se uno ha voglia...

Originariamente inviato da fano

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

Ma serve l'intero runtime, oppure qualcosa potrebbe essere tagliata via?

Originariamente inviato da fano

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!

Beh ovvio. Sicuramente dover mantenere la compatibilità ha avuto la sua influenza. D'altronde, un OS serve a far girare gli applicative degli utenti.

[fano]

Originariamente inviato da GTKM

Se la FADD viene eseguita ma nella destinazione il valore non cambia, allora sì, credo sia perché uno degli addendi è 0x0000.

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...).

Originariamente inviato da GTKM

Forse non ho capito. Essendo tutto compilato, potete solo scegliere quale blocco di codice eseguire in base alle istruzioni supportate dalla CPU, no? Ma l'assembly deve già essere stato generato in fase di compilazione.

Sì il fatto è che NON puoi basarti sul set d'istruzioni della CPU su cui stai compilando altrimenti otterresti un kernel che girerebbe solo sulla tua macchina.

GCC risolve il problema nel modo più banale di default compila per 486 (quindi solo FPU legacy, niente MMX, ...) e poi se uno lo richiede aggiungendo opportunamente dei flag nella linea di comando puoi usare mmx, sse1, see2, ...

Noi per fare in questo modo faremmo dei profili in Visual Studio tutti carucci però a me piacerebbe una soluzione più "automatica" la mia idea non sarebbe troppo lontana da avere un JIT solo per alcun istruzioni, ma non farlo tutte le volte che sono incontrate, ma solo alla partenza del Kernel interrogando la CPU stessa con CPUID.

Mi hanno che sarebbe possibile farlo usando indirect call, ma sarebbe molto più lento che avere l'assembler già pronto.

Per ora comunque il target è farlo girare su un normale x86 dal Pentium III in poi...

Originariamente inviato da GTKM

Secondo me bisogna guardare semplicemente a quali sono le CPU più presenti nel mercato embedded oggi. Quindi credo che andare ancora più indietro nel tempo non abbia molto senso. Per il resto, essendo open source, se uno ha voglia...

No credo anch'io non abbia molto senso andare indietro fino al 486 o al Geode.

Originariamente inviato da GTKM

Ma serve l'intero runtime, oppure qualcosa potrebbe essere tagliata via?

Se inizi a tagliare via dei pezzi dal runtime poi non funziona più il discorso "compile once, run everywhere". L'immagine ISO di un kernel Cosmos di test è di 16 MB e ti faccio notare che:

1. siamo in modalità debug quindi ci sono anche tutti i simboli di debug dentro l'immagine
2. Il compilatore, appunto perché siamo in fase di test non ottimizza l'assembler

Originariamente inviato da GTKM

Beh ovvio. Sicuramente dover mantenere la compatibilità ha avuto la sua influenza. D'altronde, un OS serve a far girare gli applicative degli utenti.

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[*].

* 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ò...

[GTKM]

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...).

Però, matematica alla mano...

Originariamente inviato da fano

Sì il fatto è che NON puoi basarti sul set d'istruzioni della CPU su cui stai compilando altrimenti otterresti un kernel che girerebbe solo sulla tua macchina.

GCC risolve il problema nel modo più banale di default compila per 486 (quindi solo FPU legacy, niente MMX, ...) e poi se uno lo richiede aggiungendo opportunamente dei flag nella linea di comando puoi usare mmx, sse1, see2, ...

Noi per fare in questo modo faremmo dei profili in Visual Studio tutti carucci però a me piacerebbe una soluzione più "automatica" la mia idea non sarebbe troppo lontana da avere un JIT solo per alcun istruzioni, ma non farlo tutte le volte che sono incontrate, ma solo alla partenza del Kernel interrogando la CPU stessa con CPUID.

Però questo significa che se io volessi un programma, dovrei prima installare Visual Studio e compilarlo "per Cosmos"?

Secondo me è poco elastica come soluzione, sinceramente.

Originariamente inviato da fano

Se inizi a tagliare via dei pezzi dal runtime poi non funziona più il discorso "compile once, run everywhere". L'immagine ISO di un kernel Cosmos di test è di 16 MB e ti faccio notare che:

1. siamo in modalità debug quindi ci sono anche tutti i simboli di debug dentro l'immagine
2. Il compilatore, appunto perché siamo in fase di test non ottimizza l'assembler

Intendevo un'altra cosa: il .NET è enorme. Se pensi ad un OS per il mercato embedded, serve davvero tutto? La mia è una vera curiosità, non una domanda retorica eh

Originariamente inviato da fano

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[*].

* 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ò...

Eh lo so, però un'azienda come Microsoft campa(va) su quello, quindi non è che potesse tagliare decennia di compatibilità Fosse stato possibile, sono sicuro che I loro dev sarebbero stati i primi ad esultare.

Riguardo il codice "nativo", beh, in un certo senso è come se il codice scritto in C# lo sia già, per Cosmos, no?

[fano]

Originariamente inviato da GTKM

Però, matematica alla mano...

Già, ma è impossibile però! Deve essere qualche errore stupido e banali di quelli che rileggi il codice mille volte e ti pare giusto poi arriva il collega che non centra una fava e bam...

Originariamente inviato da GTKM

Però questo significa che se io volessi un programma, dovrei prima installare Visual Studio e compilarlo "per Cosmos"?

Secondo me è poco elastica come soluzione, sinceramente.

Beh un'applicazione C# per compilarla devi sempre usare Visual Studio (o Mono Develop se vuoi fare l'esotico), comunque no a parte i driver o parti del kernel tu creerai un normale .exe che girerà su Windows, Linux e Cosmos.
Semplicemente su Cosmos durante l'installazione / prima esecuzione viene compilato in assembler un po' come fa NGEN. Credo sia addirittura possibile mettere il codice binario dentro l'eseguibile stesso. Le volte successive è il codice binario che verrà eseguito!

Originariamente inviato da GTKM

Intendevo un'altra cosa: il .NET è enorme. Se pensi ad un OS per il mercato embedded, serve davvero tutto? La mia è una vera curiosità, non una domanda retorica eh

Beh dai 16 MB non sono "enormi", OK per ora manca ancora qualcosa ma non credo crescerà poi molto di più!
Vedi in teoria è molto bello avere un OS che occupa pochi MB peccato che poi ti trovi busybox che fa schifo, scopri che la libinconv "ritagliata" non supporta la codepage che ti serve e quindi sei sempre a ricompilarla, che l'UTF-8 "ritagliato" in realtà da errore se vede multi byte characters...

Secondo me dentro .NET c'è il minimo necessario per avere un OS / runtime che ha senso.

Eh lo so, però un'azienda come Microsoft campa(va) su quello, quindi non è che potesse tagliare decennia di compatibilità Fosse stato possibile, sono sicuro che I loro dev sarebbero stati i primi ad esultare.

Originariamente inviato da GTKM

Riguardo il codice "nativo", beh, in un certo senso è come se il codice scritto in C# lo sia già, per Cosmos, no?

In realtà il codice "nativo" di Cosmos è IL non C#, infatti se ti piace puoi usare anche VB.NET o F#... anche C++/CLI se ti auto-limiti con /clr-pure.
C/C++ o assembler sono vietate perché:

1. Non sono portabili
2. Sono unsafe by design
3. X# stesso non sarà usabile a livello utente: non è verificabile

[GTKM]

Originariamente inviato da fano

Già, ma è impossibile però! Deve essere qualche errore stupido e banali di quelli che rileggi il codice mille volte e ti pare giusto poi arriva il collega che non centra una fava e bam...

Probabilmente...

Originariamente inviato da fano

Beh un'applicazione C# per compilarla devi sempre usare Visual Studio (o Mono Develop se vuoi fare l'esotico), comunque no a parte i driver o parti del kernel tu creerai un normale .exe che girerà su Windows, Linux e Cosmos.
Semplicemente su Cosmos durante l'installazione / prima esecuzione viene compilato in assembler un po' come fa NGEN. Credo sia addirittura possibile mettere il codice binario dentro l'eseguibile stesso. Le volte successive è il codice binario che verrà eseguito!

Quindi, durante l'installazione su Cosmos si avrà la fase di assembling? Scusami, è solo per avere le idee chiare.

Originariamente inviato da fano

Beh dai 16 MB non sono "enormi", OK per ora manca ancora qualcosa ma non credo crescerà poi molto di più!
Vedi in teoria è molto bello avere un OS che occupa pochi MB peccato che poi ti trovi busybox che fa schifo, scopri che la libinconv "ritagliata" non supporta la codepage che ti serve e quindi sei sempre a ricompilarla, che l'UTF-8 "ritagliato" in realtà da errore se vede multi byte characters...

Secondo me dentro .NET c'è il minimo necessario per avere un OS / runtime che ha senso.

Probabile, io intendevo chiedere appunto se fosse possibile "rimuovere" parti del .NET che non dovrebbero aver motivo di esistere in un OS per sistemi embedded. Ma credo che abbiate già ridotto tutto all'osso.

Originariamente inviato da fano

In realtà il codice "nativo" di Cosmos è IL non C#, infatti se ti piace puoi usare anche VB.NET o F#... anche C++/CLI se ti auto-limiti con /clr-pure.
C/C++ o assembler sono vietate perché:

1. Non sono portabili
2. Sono unsafe by design
3. X# stesso non sarà usabile a livello utente: non è verificabile

In teoria, in un sistema così pensato, un software scritto in C# su Cosmos avrebbe prestazioni paragonabili ad uno scritto in C/C++ su altri OS, giusto?

[fano]

Originariamente inviato da GTKM

Probabilmente...

Sono in chat con Matthijs ter Woord, il nostro Linus Torvald, solo che è molto più educato: non ha ancora mandato a fare in c*lo nessuno!

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?

Originariamente inviato da GTKM

Quindi, durante l'installazione su Cosmos si avrà la fase di assembling? Scusami, è solo per avere le idee chiare.

Qui parliamo del futuro, molto è ancora da decidere. Il Kernel è trasformato in assembler durante la compilazione, ma le altre applicazioni che NON sono integrate dentro al kernel dovranno essere compilate durante l'installazione.
Nota che per ora Cosmos è super monolitico non abbiamo ancora il supporto per i thread (processi in altri OS) quindi per ora le "applicazioni" sono chiamate a funzione dentro la shell!

Originariamente inviato da GTKM

Probabile, io intendevo chiedere appunto se fosse possibile "rimuovere" parti del .NET che non dovrebbero aver motivo di esistere in un OS per sistemi embedded. Ma credo che abbiate già ridotto tutto all'osso.

In realtà quello che manca è perché non l'abbiamo implementato! Ci sarà tutto probabilmente ma sarà più piccolo che il runtime installato su Windows lo stesso: io sono assolutamente convinto che sia Windows che Linux mettano "garbage" dentro gli eseguibili per giustificare HDD più grandi

Originariamente inviato da GTKM

In teoria, in un sistema così pensato, un software scritto in C# su Cosmos avrebbe prestazioni paragonabili ad uno scritto in C/C++ su altri OS, giusto?

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