[C# / X# ] Cosmos - C# Open Source Managed Operating System

[fano]

Originariamente inviato da cdimauro

Personalmente trovo l'inline di GCC molto più semplice di X#.

L'idea è di astrarre (nascondere se preferisci) le stranezze dell'architettura x86 il più possibile in modo che "venga" naturale scriverlo insieme a C#.
Per esempio per scrivere un valore in un registro non viene fatta una "move" (da dove?) ma viene usato l'operatore =, mentre nella versione XS si usa il metodo "Set" che oggettivamente ha più senso di Move. Però sì c'è ancora molto da lavorare su X# e - ovviamente - si accettano suggerimenti.

Originariamente inviato da cdimauro

Ma l'obiettivo di progetti come Singularity e Cosmos non è strettamente quello di evitare context switch e/o l'uso della modalità protetta.

Invocare velocemente un'API che è disponibile solo in kernel mode, o usare la modalità protetta, non ti mette al riparo da buffer overflow et similia, che possono succedere ugualmente.

Non ho ben capito questa parte, in un OS come Singularity o Cosmos essendo basati su .NET buffer overflow non possono succedere: c'è un vero tipo String (non un array di caratteri la cui lunghezza il linguaggio non persiste con un "pietoso" '\0' in fondo che le stesse funzione di libc non rispettano), gli array hanno sempre il bound checking ecc...

Certo puoi fare "casini" con unsafe e X# (in assembler puoi corrompere lo stack in un attimo e tanti saluti al kernel ), ma quello sarà codice - molto poco e specifico - relegato al livello 0.

Se qualcuno "osa" scrivere una libreria SSL in Cosmos e si mette a fare "truschi" con l'assembler perché deve essere veloce beh allora abbiamo fallito l'obbiettivo

Originariamente inviato da cdimauro

Comunque il link che hai postato è interessante, ma non mi è chiaro come abbiano fatto i test per la spedizione di messaggi.

Io rilancio con questo:
http://joeduffyblog.com/2015/11/19/a...us-everything/

in particolare quoto questo paragrafo:

It was pretty common to be running the Midori system at 100% CPU utilization, because it was doing useful stuff, which is pretty rare on PCs and traditional apps.

Cioè normalmente quando la CPU è al 100% siamo piene di rotelle / palle / clessidre, vero? In Midori, no! Era al 100%, ma il sistema era sempre responsivo... non esisteva alcun IDLE

Comunque oggi si continua con i lavori: Conv.U8!

[fano]

Mah mi chiedo, ma i float / double servono davvero a qualcosa?

double aDouble = 9223372036854775849d;
ulong value = (ulong)aDouble;
Print(value);
9223372036854775808

Cioè ma sta facendo casino anche a convertire un numero intero? E il C fa uguale quindi non è qualche casino nostro...

Chissà se usando le SSE su un sistema a 64 bit avrebbe funzionato meglio?
Vado a cercarmi un Linux a 64 bit...

[cdimauro]

Originariamente inviato da fano

L'idea è di astrarre (nascondere se preferisci) le stranezze dell'architettura x86 il più possibile in modo che "venga" naturale scriverlo insieme a C#.

Non devi mica portarti dietro tutte le istruzioni legacy: quelle al 99,999999% non le usa più nessun compilatore da non so quanti anni.

Ma il resto, sì. E presta particolare attenzione a certe istruzioni di stringa, perché sebbene sian da tempo considerate legacy, negli ultimi anni sono state notevolmente potenziate nei processori Intel, tanto da essere preferite alle equivalenti che fanno uso di istruzioni SIMD per riempire o copiare la memoria.

Per esempio per scrivere un valore in un registro non viene fatta una "move" (da dove?) ma viene usato l'operatore =, mentre nella versione XS si usa il metodo "Set" che oggettivamente ha più senso di Move. Però sì c'è ancora molto da lavorare su X# e - ovviamente - si accettano suggerimenti.

Preferisco l'operatore di uguaglianza (o al limite il := di pascaliana memoria) per la move, di qualunque genere essa sia (registri general purpose, di controllo, debug, ecc.).

IMO dovreste partire proprio da come funziona l'inline di GCC, ma cercate di semplificare al massimo il tutto. Ad esempio evitare di usare il # in

EDX = #constantForEDX

non ne vedo il motivo.

Non ho ben capito questa parte, in un OS come Singularity o Cosmos essendo basati su .NET buffer overflow non possono succedere: c'è un vero tipo String (non un array di caratteri la cui lunghezza il linguaggio non persiste con un "pietoso" '\0' in fondo che le stesse funzione di libc non rispettano), gli array hanno sempre il bound checking ecc...

Non mi riferivo a Singularity o Cosmos in quel contesto, ma al microkernel L4, che lascia la possibilità di buffer overflow, mentre i primi due no.

Certo puoi fare "casini" con unsafe e X# (in assembler puoi corrompere lo stack in un attimo e tanti saluti al kernel ), ma quello sarà codice - molto poco e specifico - relegato al livello 0.

Ecco, questa è una cosa che dovete chiarire, perché se lasciate tanta libertà lì, allora tutto il castello di "sicurezza" che avete costruito a livello utente può rischiare di crollare.

Se qualcuno "osa" scrivere una libreria SSL in Cosmos e si mette a fare "truschi" con l'assembler perché deve essere veloce beh allora abbiamo fallito l'obbiettivo

Se gli darete la possibilità, lo faranno.

Io rilancio con questo:
http://joeduffyblog.com/2015/11/19/a...us-everything/

in particolare quoto questo paragrafo:

It was pretty common to be running the Midori system at 100% CPU utilization, because it was doing useful stuff, which is pretty rare on PCs and traditional apps.

Cioè normalmente quando la CPU è al 100% siamo piene di rotelle / palle / clessidre, vero? In Midori, no! Era al 100%, ma il sistema era sempre responsivo... non esisteva alcun IDLE

Comunque oggi si continua con i lavori: Conv.U8!

Meglio, perché l'articolo è troppo lungo e non ho tempo di leggerlo.

Originariamente inviato da fano

Mah mi chiedo, ma i float / double servono davvero a qualcosa?

Certo che sì.

double aDouble = 9223372036854775849d;
ulong value = (ulong)aDouble;
Print(value);
9223372036854775808

Cioè ma sta facendo casino anche a convertire un numero intero? E il C fa uguale quindi non è qualche casino nostro...

I double non possono essere precisi, tranne per un sottoinsieme di valori interi.

Chissà se usando le SSE su un sistema a 64 bit avrebbe funzionato meglio?
Vado a cercarmi un Linux a 64 bit...

Non credo che le SSE c'entri qualcosa, e nemmeno i 64 bit.

[fano]

Originariamente inviato da cdimauro

Non devi mica portarti dietro tutte le istruzioni legacy: quelle al 99,999999% non le usa più nessun compilatore da non so quanti anni.

Ma il resto, sì. E presta particolare attenzione a certe istruzioni di stringa, perché sebbene sian da tempo considerate legacy, negli ultimi anni sono state notevolmente potenziate nei processori Intel, tanto da essere preferite alle equivalenti che fanno uso di istruzioni SIMD per riempire o copiare la memoria.

Preferisco l'operatore di uguaglianza (o al limite il := di pascaliana memoria) per la move, di qualunque genere essa sia (registri general purpose, di controllo, debug, ecc.).

IMO dovreste partire proprio da come funziona l'inline di GCC, ma cercate di semplificare al massimo il tutto. Ad esempio evitare di usare il # in

EDX = #constantForEDX

non ne vedo il motivo.

In effetti quel #value non lo capisco nemmeno io... ne chiederò il senso!
Certo che a tendere dovremo trovare un modo per usare "=" con X# embeddato in C#, il codice con XS.func() è un passo intermedio... dobbiamo riuscire a fare come LINQ scrivere codice in un altro linguaggio dentro C#!

Un altra cosa che va fatta ASAP è come dichiarare le variabili dentro assembler...
Per ora mi tocca fare così:

DataMembers.Add(new DataMember(@"__doublesignbit", 0x8000000000000000));

e poi per usarla:

XS.LiteralCode(@"pxor XMM0, [__floatsignbit]");

invece vorrei poter almeno fare:

XS.PXOR(XMM0, "__floatsignbit", destinationIsIndirect: true);

anche se il modo veramente "splendido" sarebbe:

XS.PXOR(XMM0, 0x80000000, destinationIsIndirect: true);

Originariamente inviato da cdimauro

Non mi riferivo a Singularity o Cosmos in quel contesto, ma al microkernel L4, che lascia la possibilità di buffer overflow, mentre i primi due no.

Ah OK! E' L4 che è scritto in C che fa buffer overflow ovviamente...

Originariamente inviato da cdimauro

Ecco, questa è una cosa che dovete chiarire, perché se lasciate tanta libertà lì, allora tutto il castello di "sicurezza" che avete costruito a livello utente può rischiare di crollare.

Se gli darete la possibilità, lo faranno.

Io credo che a livello utente (livello 4) solo codice managed deve poter girare infondo unsafe ha molto meno senso che in normale C# visto che non ci sarà mai la necessità di fare p/invoke visto che il kernel stesso è scritto in C# anche il discorso "velocità" dovrebbe decadere se riusciamo a fare un compilatore super-ottimizzante come quello di Midori...

X# / Assembler deve ovviamente esistere solo a livello 0 per quelle poche cose che ne necessitano (per esempio scrivere sulle porte hardware della VGA? Far spegnere la CPU con l'istruzione HLT?). E' chiaro che come accade con C# unsafe ci si costruisce tutta una classe intorno che rende usabile la cosa...

Originariamente inviato da cdimauro

Meglio, perché l'articolo è troppo lungo e non ho tempo di leggerlo.

Sì Joe Duffy non è parco di parole, ma l'articolo è davvero interessante (come tutto il resto del suo Blog). Da proprio l'impressione che gli piaccia il suo lavoro: beato lui

Originariamente inviato da cdimauro

Certo che sì.

I double non possono essere precisi, tranne per un sottoinsieme di valori interi.

Io sapevo che erano imprecisi sui valori con la virgola, ma speravo che almeno gli interi si salvassero...

Capisci il mio unit test ora non ha molto senso io metto in un double un valore intero "preciso" per me essere umano, lo converto in ulong ed ottengo un numero diverso?
La mia Assertion è false, ma dovrebbe essere true!

Hanno senso per disegnare grafica forse? Dove in fondo è meglio disegnare velocemente e se poi i punti non si toccano si spera nell'aliasing o nell'occhio umano difettoso?

Se io volessi fare una calcolatrice per esempio non potrei usarli (0.2 * 3 != 0.6?), per l'uso che ne faccio io sul lavoro non hanno senso per me rappresentano valori monetari e a volte devo calcolare il cambio e con i double vengono numeri "causali" dopo già la III cifra decimale, con _Decimal32 e il decimal di C# ho valori corretti!
(Lo stesso caso dell'unit test passa senza problemi usando il tipo decimal infatti).

A proposito Intel ha pensato di accelerare il tipo decimal con IBM ha fatto per i suoi sistemi con CPU Power? Questo è l'unico difetto i decimal sono molto più lenti dei double perché sono implementati in software...

Originariamente inviato da cdimauro

Non credo che le SSE c'entri qualcosa, e nemmeno i 64 bit.

Sì hai ragione anche usando SSE su un sistema a 64 bit non cambia nulla: ho provato per togliermi il dubbio con un'orrida Ubuntu a 64 Bit ed il risultato è lo stesso... un numero sbagliato

Altra cosa che ho notato come differenza tra SSE e x87: SSE non ha un'istruzione diretta per negare un float / double, mentre x87 aveva fchs. Nulla di complicato da "simulare" con SSE basta infatti fare uno XOR con -0.0 (ovvero 0x800....) e il segno "flippa", però perché non hanno implementato tutto in modo che potesse davvero sostituire x87?
Perché non c'è un modo diretto per operare sugli Int64 con SSE su x86, mentre con x87 sì? Perché non ci sono le funzioni trigonometriche in SSE?

[||ElChE||88]

Originariamente inviato da fano

Io sapevo che erano imprecisi sui valori con la virgola, ma speravo che almeno gli interi si salvassero...

Come fa un float a 32 bit a rappresentare tutti gli interi a 32 bit? Non resta più spazio per la parte frazionale.

Originariamente inviato da fano

Hanno senso per disegnare grafica forse? Dove in fondo è meglio disegnare velocemente e se poi i punti non si toccano si spera nell'aliasing o nell'occhio umano difettoso?

Molto, perché hanno ottime prestazioni ma soprattutto occupano poco spazio. La precisione limitata va presa in considerazione, ma è un compromesso accettabile; come per la CPU, anche per la GPU un collo di bottiglia molto comune è l'accesso alla memoria.

[cdimauro]

Originariamente inviato da fano

In effetti quel #value non lo capisco nemmeno io... ne chiederò il senso!
Certo che a tendere dovremo trovare un modo per usare "=" con X# embeddato in C#, il codice con XS.func() è un passo intermedio... dobbiamo riuscire a fare come LINQ scrivere codice in un altro linguaggio dentro C#!

Ma non potete introdurre niente di simile a GCC?

Un altra cosa che va fatta ASAP è come dichiarare le variabili dentro assembler...
Per ora mi tocca fare così:

DataMembers.Add(new DataMember(@"__doublesignbit", 0x8000000000000000));

e poi per usarla:

XS.LiteralCode(@"pxor XMM0, [__floatsignbit]");

invece vorrei poter almeno fare:

XS.PXOR(XMM0, "__floatsignbit", destinationIsIndirect: true);

anche se il modo veramente "splendido" sarebbe:

XS.PXOR(XMM0, 0x80000000, destinationIsIndirect: true);

Va bene che ormai sono arrugginito con l'assembly, ma se dovessi scrivere questi papiri ogni volta per una sola istruzione o dichiarazione, mi passerebbe la voglia di scrivere roba di X#.

Trovate un'altra soluzione/sintassi.

Io credo che a livello utente (livello 4) solo codice managed deve poter girare infondo unsafe ha molto meno senso che in normale C# visto che non ci sarà mai la necessità di fare p/invoke visto che il kernel stesso è scritto in C# anche il discorso "velocità" dovrebbe decadere se riusciamo a fare un compilatore super-ottimizzante come quello di Midori...

Personalmente non tendo a fidarmi molto delle promesse di realizzare compilatori super ottimizzanti. Basti vedere quello che è successo a Intel/HP con EPIC/Itanium.

X# / Assembler deve ovviamente esistere solo a livello 0 per quelle poche cose che ne necessitano (per esempio scrivere sulle porte hardware della VGA? Far spegnere la CPU con l'istruzione HLT?). E' chiaro che come accade con C# unsafe ci si costruisce tutta una classe intorno che rende usabile la cosa...

OK, questo è chiaro, ma... chi può scrivere questa roba? Perché lasciando una porta aperta sta tranquillo che qualcuno malizioso l'attraversa.

Per il resto, pensate di far girare qualunque cosa nel ring-0 del processore, visto che le applicazioni / codice utente dovrebbero essere del tutto "safe"?

Perché in linea teorica non vi servirebbe dividere il codice in kernel e user mode, per quanto hai detto finora, ed evitare un paio di context switch fra le due modalità fa sempre comodo in termini di velocità.

A proposito Intel ha pensato di accelerare il tipo decimal con IBM ha fatto per i suoi sistemi con CPU Power? Questo è l'unico difetto i decimal sono molto più lenti dei double perché sono implementati in software...

No. Tra l'altro ho visto che il decimal di .NET è a 128 bit: è troppo grande per poter esser gestito agevolmente. Normalmente i tipi decimal usati in ambito finanziario in engine SQL et similia usano valori interi a 64 bit, e hanno una parte fissa decimale (esempio: 4 cifre), per cui fanno uso di moltiplicazioni e divisioni con valori fissi, e sono abbastanza gestibili da un processore a 64 bit convenzionale.

Ma un decimal a 128 bit complica notevolmente le cose. Non capisco perché Microsoft non ne abbia fornito una versione "single"/64-bit e una "double"/128 bit.

Comunque non conosco l'implementazione di IBM, ma Intel ha introdotto alcune istruzioni per eseguire più agevolmente somme e moltiplicazioni a precisione elevata, che dovrebbero aiutare per i decimal a 128 bit. Ma rimarranno sempre molto più lenti da gestire.

Altra cosa che ho notato come differenza tra SSE e x87: SSE non ha un'istruzione diretta per negare un float / double, mentre x87 aveva fchs. Nulla di complicato da "simulare" con SSE basta infatti fare uno XOR con -0.0 (ovvero 0x800....) e il segno "flippa", però perché non hanno implementato tutto in modo che potesse davvero sostituire x87?
Perché non c'è un modo diretto per operare sugli Int64 con SSE su x86, mentre con x87 sì? Perché non ci sono le funzioni trigonometriche in SSE?

Perché x87 è un'FPU regolare & completa, mentre SSE è un'unità SIMD, per cui è orientata ad altro tipo di calcolo, e il focus è rappresentato dai single e double, mentre i tipi interi c'è molto meno spazio (in particolare per quelli a 64 bit).

Nel corso del tempo sono state introdotte nuove istruzioni che in parte colmano il gap, ma mancano ancora diverse corse, e... te le devi emulare.

Le nuove AVX-512 che arriveranno con Cannonlake (ma per settore server saranno disponibili già con Skylake) hanno delle estensioni (solo per i processori che le implementano) che ampliano le possibilità di manipolazione degli interi, ma adesso non ricordo quali migliorie siano state apportate.

In ogni caso non penso che abbiate voglia di scrivere già adesso il backend per AVX-512.

Purtroppo con le SSE dovete arrangiarvi in qualche modo.

[tomminno]

Originariamente inviato da fano

Codice macchina, puro e semplice!



I livelli (che sono un'implementazione software dei ring) non ti permetteranno di fare questo:

https://github.com/CosmosOS/Cosmos/b...rnel/Levels.md

un'applicazione sarà sempre a livello 3 e quindi non potrà chiamare nessuna istruzione privilegiata (non puoi scrivere codice assembler a livello 3 e nemmeno codice unsafe probabilmente).
Certo uno "monello" potrebbe scrivere un SO "malvagio" che è un virus, ma questo cosa ti garantisce che una distribuzione Linux non possa fare lo stesso?

Si parla sempre di controlli a monte della compilazione, ma una volta compilato se l'eseguibile viene modificato, chi lo controlla?
Quali controlli esegue l'OS e come, sulle istruzioni eseguite dai programmi? Non essendoci più le trap dovute ai ring hardware, mi chiedo come faccia l'OS ad intercettare chiamate privilegiate.
Mi pare assurdo fare un nuovo OS orientato alla sicurezza che poi cade come un castello di carte se qualcuno modifica a mano un eseguibile.

Perché dovresti gestirla "deterministicamente" c'è il garbage collector una nostra versione (non quello classico di .NET).

Il GC con cosa è scritto? Se parliamo di runtime scritto in C#, del runtime fa parte anche il GC.

Beh nei casi in cui sia necessario anche C# permette di allocare nello stack usando stackalloc.

Io parlavo proprio della gestione dell'heap. Lo stack comunque è molto limitato generalmente come dimensioni.
Infine stackalloc non è unsafe?

[fano]

Originariamente inviato da tomminno

Si parla sempre di controlli a monte della compilazione, ma una volta compilato se l'eseguibile viene modificato, chi lo controlla?

Cito dal documento postato sui livelli:

Since Cosmos can control execution and rebuild its compiler and recompile all code at any time, Cosmos can be much more flexible and most restrictions can be enforced at compile or installation time rather than the need to perform such CPU checks in live CPU code.

Quindi al momento dell'installazione quando - come ho già detto - il codice è ancora in formato IL viene verificato che l'applicazione che gira a livello utente non abbia al suo interno codice che non possa eseguire (per esempio codice unsafe, assembler o anche normale codice C#, ma che fa cosa che si è deciso di black listare...).
Una volta che ci si è assicurati di questo si crea la versione nativa che andrà scritta da qualche parte (dentro l'eseguibile stesso?) e non più scrivibile.

Originariamente inviato da tomminno

Quali controlli esegue l'OS e come, sulle istruzioni eseguite dai programmi? Non essendoci più le trap dovute ai ring hardware, mi chiedo come faccia l'OS ad intercettare chiamate privilegiate.
Mi pare assurdo fare un nuovo OS orientato alla sicurezza che poi cade come un castello di carte se qualcuno modifica a mano un eseguibile.

Potrebbe forse essere ideato un sistema di anti-tampering? Non lo so per esempio una volta create l'immagine binaria salvarsi l'MD5SUM / hashcode da qualche parte e prima di eseguire il programma verificare che corrisponda?

Tu cosa proponi?

Originariamente inviato da tomminno

Il GC con cosa è scritto? Se parliamo di runtime scritto in C#, del runtime fa parte anche il GC.

Il GC è scritto in C#, non so molto di quella parte, ma c'è un momento in cui Cosmos parte ed esegue la sequenza di istruzioni in assembler che tutti gli OS hanno sempre eseguito (modalità reale 16 Bit, 64 KB di RAM, ...) poi parte praticamente subito la "macchina virtuale" / "esecutore" C# e quindi il GC inizia a funzionare insieme a tutto il resto del runtime: il codice di Cosmos è normale codice C# dal punto di vista di chi lo scrive gli oggetti sono allocati sull'heap, c'è il garbage collector, ecc...

Originariamente inviato da tomminno

Io parlavo proprio della gestione dell'heap. Lo stack comunque è molto limitato generalmente come dimensioni.
Infine stackalloc non è unsafe?

Sì stackalloc è unsafe, ma a livello 0 (la parte core del Kernel) è ammesso che possa esistere codice unsafe questo è il codice che dovrebbe gestire l'heap io non ci capisco molto, ma come vedi è scritto in C# per quanto appunto unsafe:

https://github.com/CosmosOS/Cosmos/b...Memory/Heap.cs

[tomminno]

Originariamente inviato da fano

Cito dal documento postato sui livelli:

Since Cosmos can control execution and rebuild its compiler and recompile all code at any time, Cosmos can be much more flexible and most restrictions can be enforced at compile or installation time rather than the need to perform such CPU checks in live CPU code.

Quindi al momento dell'installazione quando - come ho già detto - il codice è ancora in formato IL viene verificato che l'applicazione che gira a livello utente non abbia al suo interno codice che non possa eseguire (per esempio codice unsafe, assembler o anche normale codice C#, ma che fa cosa che si è deciso di black listare...).
Una volta che ci si è assicurati di questo si crea la versione nativa che andrà scritta da qualche parte (dentro l'eseguibile stesso?) e non più scrivibile.

Quindi il codice è MSIL non codice macchina, il codice macchina lo crea l'OS.

Potrebbe forse essere ideato un sistema di anti-tampering? Non lo so per esempio una volta create l'immagine binaria salvarsi l'MD5SUM / hashcode da qualche parte e prima di eseguire il programma verificare che corrisponda?

Tu cosa proponi?

Beh immagino che un problema del genere se lo sarà posto l'architetto dell'OS prima di tirare su le mura no?
Se puoi modificare l'eseguibile, puoi anche modificare il checksum di conseguenza no?
Per un sistema di antitampering gli eseguibili andrebbero firmati. Ma anche in quel caso se sono in possesso di una chiave valida di cifratura (e tutti gli sviluppatori dovrebbero averne una) posso rimpacchettare il tutto e farlo digerire al sistema. Insomma si finisce in un sistema alla Apple dove puoi installare solo da un market place certificato in cui la chiave riconduce ad un ben preciso sviluppatore.

Il GC è scritto in C#, non so molto di quella parte, ma c'è un momento in cui Cosmos parte ed esegue la sequenza di istruzioni in assembler che tutti gli OS hanno sempre eseguito (modalità reale 16 Bit, 64 KB di RAM, ...) poi parte praticamente subito la "macchina virtuale" / "esecutore" C# e quindi il GC inizia a funzionare insieme a tutto il resto del runtime: il codice di Cosmos è normale codice C# dal punto di vista di chi lo scrive gli oggetti sono allocati sull'heap, c'è il garbage collector, ecc...

Per questo mi chiedevo come si fa a deallocare la memoria in C#
Il GC dealloca memoria, se è scritto in C# ci deve essere un meccanismo che consente di gestire direttamente la memoria, meccanismo non presente rimanendo in puro C# (e non citiamo il PInvoke che se l'OS è scritto in C# siamo punto e a capo )

Mi sapresti indicare dove sta il codice Cosmos relativo al GC?

Sì stackalloc è unsafe, ma a livello 0 (la parte core del Kernel) è ammesso che possa esistere codice unsafe questo è il codice che dovrebbe gestire l'heap io non ci capisco molto, ma come vedi è scritto in C# per quanto appunto unsafe:

https://github.com/CosmosOS/Cosmos/b...Memory/Heap.cs

[fano]

Allora ieri ho fatto una chiaccherata con Matthijs ter Woord (uno dei lead developer di Cosmos, ci sarebbe anche Chad Z. Hower (Kudzu), ma lo si deve molto raramente in chat!) riguardo X# beh la risposta sul perché il cancelletto davanti alle costanti mi ha lasciato un po' con l'amaro in bocca: "beh perché a noi piace così"
(no, nemmeno a me piace!).

Riguardo embeddare X# dentro C# c'è un problema facendo come fa GCC che dal punto di vista di Visual Studio sarebbe una stringa quindi:

1. Niente più syntax highliting / code completion
2. Nessun errore da parte del compilatore se scrivi codice errato. Questo è un grosso vantaggio di XS rispetto al sistema precedente (l'errore lo beccava NASM, ma ti mostrava l'assembler non il tuo codice e beh non è immediato associare le 2 cose!)

Io credo che C# potesse embeddare altri linguaggi dentro di sè come fatto con LINQ, ma sembra che fosse l'eccezione non la regola:

https://github.com/dotnet/roslyn/issues/1746

Si potrebbe fare modificando Roslyn, ma è un po' un casino!

Riguardo il discorso come facciamo ad essere sicuri che un programma utente non faccia cose illecite?

Beh intanto per iniziare i programmi utenti sono sempre in formato IL (e Matthijs ter Woord ha tenuto a stressare questo: in Cosmos i programmi sono sempre in formato IL, mai in formato nativo) e quindi prima di essere compilati per essere eseguiti possono e dovranno essere verificati. Il nostro compilatore avrà una black list delle istruzioni che sono "pericolose" e quindi mostrerà una gloriosa eccezzione e l'utente butterà nel cestino l'applicazione

Anche un subset di unsafe sarà accettato perché in realtà un subset di unsafe è safe ed infatti con C# 7 la stessa Microsoft sta esponendo cose parzialmente unsafe senza bisogno di taggare la classe come unsafe come per esempio: Span, Slice, Ref return.
Codice unsafe C# non può comunque fare gli stessi danni che può nelle mani di un hacker esperto fare codice C/C++: quello che è stato fatto per crackare la PS4 e fargli girare sopra Linux (poveretta ) accedendo a strutture del kernel da un programma utente non sarebbe possibile se l'OS di PS4 fosse basato su Cosmos.
(Sì un dispositivo blindato come PS4 è un possibile target di Cosmos: ricordate la licenza MIT? Sony potrebbe riscriverlo completamente e rendere il tutto closed source e il tutto sarebbe perfettamente legale).

Codice automodificante non può esistere usando C#, da vedere se anche Reflection per quanto sia comoda, possa essere accettabile (correggetemi se sbaglio, ma con Reflection io posso chiamare impunemente metodi privati di una classe vero?).

Forse un sistema di signature del binario potrebbe anche non essere necessario, ma ci penseremo nel momento in cui ci occuperemo di come gestire le applicazioni per ora:

"Cart before horses"

@tomminno questo è il codice (parziale ci stanno ancora lavorando) di RAT che è in realtà la classe che si occupa di allocare / deallocare memoria, il GC vero e proprio non c'è ancora (sì Cosmos leaka memoria ):
https://github.com/CosmosOS/Cosmos/b...ry.Test/RAT.cs

come vedi è codice C# è unsafe perché usa i puntatori anche il GC sarà ovviamente scritto in C# (dovrebbe essere un thread che gira insieme all'applicazione / applicazioni, e userà le funzioni di allocazione / deallocazione di RAT quindi il GC potrebbe essere scritto in safe C# e quindi girerà a un livello più alto visto che non dovrà accedere direttamente a una risorsa privelegiata come la RAM).

[cdimauro]

Originariamente inviato da fano

Allora ieri ho fatto una chiaccherata con Matthijs ter Woord (uno dei lead developer di Cosmos, ci sarebbe anche Chad Z. Hower (Kudzu), ma lo si deve molto raramente in chat!) riguardo X# beh la risposta sul perché il cancelletto davanti alle costanti mi ha lasciato un po' con l'amaro in bocca: "beh perché a noi piace così"
(no, nemmeno a me piace!).

No comment.

Riguardo embeddare X# dentro C# c'è un problema facendo come fa GCC che dal punto di vista di Visual Studio sarebbe una stringa quindi:

1. Niente più syntax highliting / code completion
2. Nessun errore da parte del compilatore se scrivi codice errato. Questo è un grosso vantaggio di XS rispetto al sistema precedente (l'errore lo beccava NASM, ma ti mostrava l'assembler non il tuo codice e beh non è immediato associare le 2 cose!)

Io credo che C# potesse embeddare altri linguaggi dentro di sè come fatto con LINQ, ma sembra che fosse l'eccezione non la regola:

https://github.com/dotnet/roslyn/issues/1746

Si potrebbe fare modificando Roslyn, ma è un po' un casino!

Sarebbe la soluzione migliore, perché trattare il codice X# come stringa è l'ultima cosa che dovreste fare.

Purtroppo C# ha capacità limitate per implementare roba così nuova. Non è un linguaggio che mette a disposizione funzionalità di tipo DSL.

Vi tocca estenderlo, se volete una soluzione elegante e robusta, oppure inventarvi un'altra soluzione: X# è troppo verboso così com'è.

Riguardo il discorso come facciamo ad essere sicuri che un programma utente non faccia cose illecite?

Beh intanto per iniziare i programmi utenti sono sempre in formato IL (e Matthijs ter Woord ha tenuto a stressare questo: in Cosmos i programmi sono sempre in formato IL, mai in formato nativo) e quindi prima di essere compilati per essere eseguiti possono e dovranno essere verificati. Il nostro compilatore avrà una black list delle istruzioni che sono "pericolose" e quindi mostrerà una gloriosa eccezzione e l'utente butterà nel cestino l'applicazione

Sempre che il meccanismo di black list sia ben congegnato e/o non abbia bug.

Anche un subset di unsafe sarà accettato perché in realtà un subset di unsafe è safe ed infatti con C# 7 la stessa Microsoft sta esponendo cose parzialmente unsafe senza bisogno di taggare la classe come unsafe come per esempio: Span, Slice, Ref return.
Codice unsafe C# non può comunque fare gli stessi danni che può nelle mani di un hacker esperto fare codice C/C++: quello che è stato fatto per crackare la PS4 e fargli girare sopra Linux (poveretta ) accedendo a strutture del kernel da un programma utente non sarebbe possibile se l'OS di PS4 fosse basato su Cosmos.
(Sì un dispositivo blindato come PS4 è un possibile target di Cosmos: ricordate la licenza MIT? Sony potrebbe riscriverlo completamente e rendere il tutto closed source e il tutto sarebbe perfettamente legale).

Esattamente.

Codice automodificante non può esistere usando C#, da vedere se anche Reflection per quanto sia comoda, possa essere accettabile (correggetemi se sbaglio, ma con Reflection io posso chiamare impunemente metodi privati di una classe vero?).

Dovrebbe essere così, ma non ne sono sicuro.

Forse un sistema di signature del binario potrebbe anche non essere necessario, ma ci penseremo nel momento in cui ci occuperemo di come gestire le applicazioni per ora:

"Cart before horses"

Già, ma cominciate a pensare già adesso a un sistema di firma dei binari, perché è necessario.

[fano]

Originariamente inviato da cdimauro

No comment.

Sì diciamo che come risposta non l'ho molto capita (sospetto che non abbia capito la domanda, in fondo lui è Olandese, io sono Italiano e ci parliamo in Inglese )

Originariamente inviato da cdimauro

Sarebbe la soluzione migliore, perché trattare il codice X# come stringa è l'ultima cosa che dovreste fare.

Beh adesso con XS.Func() non è trattato come stringa, Visual Studio è già in grado di trovare casi di uso errato avviene con i contracts con controlli sintattici veri e propri però è già molto meglio di prima in cui l'errore te lo beccavi da parte di NASM e ti diceva non la riga del tuo codice, ma quella dell'Assembler!

Originariamente inviato da cdimauro

Purtroppo C# ha capacità limitate per implementare roba così nuova. Non è un linguaggio che mette a disposizione funzionalità di tipo DSL.

Vi tocca estenderlo, se volete una soluzione elegante e robusta, oppure inventarvi un'altra soluzione: X# è troppo verboso così com'è.

Sai io ero convinto che appunto essendoci LINQ fosse già possibile invece pare che LINQ sia stata un'eccezione, fa strano vedere che VB.NET, invece, lo sa fare benissimo
Purtroppo la Microsoft non ne vuole sapere d'implementarlo e Roslyn non sembra molto semplice da modificare...

Non ho capito se quei file .xs in cui il vero X# vivo sono chiamabili da C# altrimenti uno potrebbe scrivere una funzione e poi chiamarla da C#, ma non è veramente codice .NET il '#' è solo pubblicità è più un "macro paster" X# che un vero è proprio linguaggio.

Originariamente inviato da cdimauro

Sempre che il meccanismo di black list sia ben congegnato e/o non abbia bug.

Beh uno a non avere bug ci prova, ma non è mica facile
La cosa migliore è fare come le grandi corporation avere in casa un hacker e metterlo a stressare l'OS finché non lo buca (e poi risolvere il bug)!

Originariamente inviato da cdimauro

Dovrebbe essere così, ma non ne sono sicuro.

Così almeno mi ha detto Matthijs, ma ha senso per quello per cui è stato pensato C#: questa cosa taglia fuori molti virus / malware....

Originariamente inviato da cdimauro

Già, ma cominciate a pensare già adesso a un sistema di firma dei binari, perché è necessario.

Prima di questo però i binari (nel senso di applicazioni) dobbiamo averli

Comunque non è che gli .EXE scaricati dovranno essere firmati (non sarebbe possibile visto che vogliamo essere compatibili il più possibile con normali applicazioni .NET): la firma avverrà all'interno di Cosmos al momento dell'installazione / prima avvio quando l'IL viene compilato e l'immagine nativa generata: è l'immagine nativa che dovrà essere firmata!

[fano]

Questo Domenica non ho potuto lavorare su Cosmos perché ho deciso finalmente di farmi coraggio e di aggiornare da Windows 8.1 a Windows 10 mica per altro, ma perché è l'ultima settimana che è gratis (e da buon genovese se una cosa è gratis ).

Vi aggiorno un po' su quello che stanno facendo gli altri:

• Si sta tentando di rendere configurabile il layout della tastiera Cosmos attualmente aveva hardcoded il layout US. La prima PR è stata rigettata perchè era stata fatta per mezzo di kludge: https://github.com/CosmosOS/Cosmos/pull/407. La cosa corretta è probabilmente "scardinare" l'hard coding fatto in HAL e spedire verso l'alto i raw scancodes e interpretarli in System secondo il layout selezionato.
• Si sta tentando di portare le Winforms di Mono su Cosmos. Io penso sia un po' prematuro...

Se gli impegni lavorativi (ultimamente torno a casa dopo le 21!) non mi stressano troppo voglio studiare in questa settimana un metodo migliore per dichiarare le variabili in X#, attualmente sono aggiunte nel posto sbagliato: dovrebbero essere vicino all'implementazione degli OpCode stessi invece sono all'inizio del kernel.

Comunque qualcuno di voi ha deciso di voler collaborare al progetto? Vi aspettiamo numerosi!

[71106]

Ma in tutto cio' la domanda e': perche' non l'avete chiamato AlphaWinUX?

[fano]

Perché questo è un progetto serio ecco perché!

[71106]

Si, ma se l'aveste chiamato AlphaWinUX avreste avuto un follower in piu'!

[fano]

Beh Cosmos è solo il nome del Kernel se uno volesse fare un OS "satanico" che mixa Windows con Linux e con una punta di Mac OSX e chiamarlo AlphaWinUX potrebbe pure farlo
(Magari si riesce ad avere qualcosa che funziona mischiandoli tutti!)

[||ElChE||88]

Si riferiva al leggendario AlphaWinUX.

[71106]

Originariamente inviato da fano

Beh Cosmos è solo il nome del Kernel se uno volesse fare un OS "satanico" che mixa Windows con Linux e con una punta di Mac OSX e chiamarlo AlphaWinUX potrebbe pure farlo
(Magari si riesce ad avere qualcosa che funziona mischiandoli tutti!)

Non essere eretico, il vero il vero AlphaWinUX non puo' essere basato su Cosmos perche' deve avere il motore kernel!

[fano]

Ieri mentre browsavo sono incappavo in un'antica (?) diatriba l'istruzione IDIV è lenta tanto che alcuni compilatori cercano di evitarla ad ogni costo! Per esempio quando la divisione è per un multiplo di 2 si preferisce fare uno shift piuttosto che chiamare IDIV, altri arrivano all'estremo di usare il reciproco e fare la moltiplicazione

Mi chiedo ma con le ultime CPU è ancora così o è solo una leggenda metropolitana?

Ho fatto un po' di prove con VC++ e questa semplice funzione:

static void DivideBy2(int val)
{
   	int result = val / 2;
}

viene convertita in assembler in una versione con gli shift:

00E616BE  mov         eax,dword ptr [val]  
00E616C1  cdq  
00E616C2  sub         eax,edx  
00E616C4  sar         eax,1
00E616C6  mov         dword ptr [result],eax

Analogo codice invece scritto in C# usa semplicemente DIV:

057EE8D8  mov         eax,dword ptr [ebp-3Ch]  
057EE8DB  mov         ecx,2  
057EE8E0  cdq  
057EE8E1  idiv          eax,ecx
057EE8E3  mov         dword ptr [ebp-40h],eax

Ora è possibile che l'assembler che ottengo da C# sia quello che usa il JIT che - per ovvie ragioni - non può fare tutti sta ragionamenti se il dividendo è multiplo di 2 o cosa... e forse questo ragionamento non può farlo nemmeno l'IL perché magari non è sempre detto per tutti i processori che ci sia differenza tra SAR e IDIV? Magari il JIT vede che ho un core I3 dove IDIV funziona correttamente mentre il VC++ ottimizza per il minimo comun denominatore (486? Pentium II?)?

Mi sto anche chiedendo, ma la CPU non potrebbe da sola cambiare IDIV con SAR quando appropriato?

Probabilmente sono cose che un AOT compiler come .NET Native, CoreRT e IL2CPU dovranno fare insieme ad altri "trucchetti" (eliminazioni di costanti, trasformazioni di divisioni con multipli di 2 in Right Shift, di moltiplicazioni in Left Shift, Loop Unrolling, Auto Vettorizzazione, ecc...) se si vuole arrivare vicini al livello di C/C++...

Un'idea che mi è venuta è un IL2IL compiler che trasforme l'IL della Microsoft in una nuova versione "Machine dependent" che IL2CPU a sua volta ri-mastica per trasformarlo in assembler:

1. Visual Studio genera il classico IL come farebbe per una normale applicazione
2. IL2IL interviene e applica varie ottimizzazioni in alcuni casi aggiungendo nuovi opcode per esempio per le operazioni con SSE (auto-vettorizzazione). L'IL generato a questo punto è valido solo per x86
3. IL2CPU trasforma l'IL ottenuto da IL2IL in assembler senza dover essere troppo cambiato (si dovrà aggiungere il trattamento degli opcode aggiunti ovviamente)

Questo è quanto avveniva in Midori e quanto viene fatto in .NET Native (il secondo IL è chiamato appunto MDIL Machine Dependent IL) peccato che non vogliano rendere Open Source quel compilatore

Comunque tornando al Cosmos di oggi non quelli di anni ed anni nel futuro mi faceva schifo come dovevo dichiarare le costanti per le operazione con i floating point (attualmente deve esser fatto in tutt'altro file rispetto a dove sono usati e finiscono in una sezione chiamata "kernel stack" ) così mi hanno suggerito che per adesso potremmo anche metterle nello stack così ho provato a cambiare il codice in questo modo:

        // There is no direct float negate instruction in SSE simply we do a XOR with 0x80000000 to flip the sign bit
       XS.SSE.MoveSS(XMM0, ESP, sourceIsIndirect: true);
       //XS.SSE.MoveSS(XMM1, "__floatsignbit", sourceIsIndirect: true);
       XS.Set(ESP, 0x80000000);
       XS.SSE.MoveSS(XMM1, ESP,  sourceIsIndirect: true);
                  
       XS.SSE.XorPS(XMM0, XMM1);
       XS.SSE.MoveSS(ESP, XMM0, destinationIsIndirect: true);

Ma la VM ci resta secca eseguendo il mio codice, manco posso debuggare perché il debugger stesso si blocca! Non vedo nessun errore fatale che ammazza la CPU, ma essa muore... che accade?