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

[GTKM]

Originariamente inviato da cdimauro

Sulla carta sembra molto fico, ma finché sul lato prestazionale non si passerà ai risultati concreti, dubito che si potrà prendere sul serio ciò che dice il main developer.

Non prenderlo come una critica distruttiva, ma sparare che si possa andare 20 volte più velocemente di C++ (se non ricordo male la frase) e poi affermare che attualmente Cosmos è troppo lento perché ancora in fase di debug, non fa certo una buona impressione.

Per cui consiglierei di lasciar perdere certi slogan. Almeno finché non ci sarà qualche risultato a supporto.

Altra cosa, francamente togliete di mezzo completamente X#. E' eccessivamente complesso e farraginoso rispetto a usare direttamente il ben più conosciuto, classico, semplice linguaggio assembly (con sintassi Intel e NON AT&T!).

D'altra parte lo dice anche lo sviluppatore che si usa per pochissime righe di codice. Inutile reinventarsi la ruota con uno strumento così astruso, per così poco: usate l'assembly e metteteci una pietra sopra.

Per il resto promette molto bene. Ma, come ti dicevo anche tempo, se non rilasciate velocemente qualcosa di funzionante, non verrà mai preso seriamente in considerazione. E visto che siete pochi e cercate sviluppatori, sarebbe sicuramente di stimolo vederlo già all'opera.

Più che altro, X# sembra un po' troppo prolisso.

Ma siamo sicuri che sia davvero conveniente rispetto all'assembly? In fondo, nel computo totale del progetto, la parte interessata è davvero piccola.

[cdimauro]

Appunto per questo è meglio evitare di reinventarsi la ruota, e sfruttare pari pari il caro, vecchio, semplice assembly.

[fano]

Un po' di aggiornamenti su Cosmos...

Cosmos Graphic Subsystem

Visto che come si dice un'immagine parla più di 1'000 parole:



C'è pure un pixel accesso in alto, ma mi sa che la compressione jpg se lo ho è "pappato".

Questo è stato il mio "lavoro" durante le vacanza di Natale, per ora funziona solo con Bochs / VBE perché il driver VGA e quello di VmWare attualmente non sono funzionanti (il secondo forse funziona pure bisognerebbe provarlo), 32 bit / 16'000'000 di colori e risoluzione fino a 1920 * 1200

Peccato che per iniziare a disegnare qualche cosa passavano ben 33 secondi, OK che usiamo C#, OK che il compilatore non è ottimizzato, però era davvero strano perché passati i 33 secondi in cui lo schermo era ripulito (lo sfondo blu che vedete), il pixel, le righe ed i rettangoli apparivano tutti contemporaneamente in un tempo non umanamente misurabile (no, non è come dicevano gli utenti che si vedevano i pixel disegnarsi uno per uno!).

Dopo molte false partenze il problema era questo, la classe IOMemoryBlock deve essere inizializzata con quanta memoria video si vuole utilizzare che per ora è dato dalla semplice formula:
H * V * (colorDepth) / 8

essendo però questo nel ring core dove non so più quale risoluzione è utilizzata sono costretto al momento ad inizializzarlo a 1920*1200*4 ( 9'216'000 Byte circa 9 MB) e il metodo Fill() era la cosa più semplice che si possa immaginare:

        [DebugStub(Off = true)]
        public unsafe void Fill(UInt32 aStart, UInt32 aCount, UInt32 aData)
        {
            //TODO: before next step can at least check bounds here and do the addition just once to 
            //start the loop.
            //TODO - When asm can check count against size just one time and use a native fill asm op
            UInt32* xDest = (UInt32*)(this.Base + aStart);
            for (UInt32 i = 0; i < aCount; i++)
            {
                *xDest = aData;
                xDest++;
            }
        }

Avete intuito il problema? Sono circa 2'000'000 di iterazioni (visto che copiamo a blocchi di interi) e inoltre quando si richiedeva una risoluzione più bassa tipo 1280*1024 Bochs puliva lo schermo e apparentemente finiva, ma poi passavano decine e decine di secondi perché stava riempendo memoria che non era visibile con il colore blu!

Ho provato a combattere contro la realtà dei fatti (Fill() va scritta in assembler) e ho provato orridi truschi con array con blocchi da 1024 ricopiati con Array.BlockCopy(), ma:

1. ArrayBlockCopy() ti filla l'Array tutto con 0 (ovvero è bacata!)
2. C# non è C (!) e pensa che non sia "bello" assegnare un puntatore ad un array ("The Pit of Success") e mi ha impedito di farlo con tutte le sue forze

Così mi sono rassegnato a fare la cosa in Assembler, ma in realtà l'approccio che ho usato è ibrido fino ad un certo threshold può essere fatto in C# (unsafe ovviamente) e solo una piccola parte avviene in ASM / X#.

1. Se il buffer è minore di 15, la Fill() avviene con tipi primitivi (per esempio se il buffer è di 4 byte viene "rivalutato" come un int e si fa una semplice assegnazione, se è 7 byte si assegna un int, uno short e un byte)
2. Con il metodo Math.ModDivRem() si divide per 16 e si ottiene anche il resto
3. Per "definizione" il resto è minore di 16 quindi si fa un bel for() in C# valutando il buffer come array di byte
4. A questo punto per fare una copia a blocchi di 16 si usa assembler scrivendo il valore dentro ad un registro XMM

Questo è più o meno quello che fa la memset() implementata dentro GCC [1]

Purtroppo ho perduto un po' di tempo perché volevo far prima facendo le cose su Windows e poi solo quando avevo una Fill() funzionante portarla su Cosmos (anche se è più veloce che far partire Windows o Linux caricare un intero Sistema Operativo solo per chiamare una funzione è un po' una menata ), visto che Cosmos è a 32 bit e che credevo usasse la CDECL ho pensato astuto come un procione di mettere CDECL negli attributi della P/Invoke della mia DLL scritta in assembler con NASM... e SEGFAULT

Pare che Visual Studio quando il SO è a 64 Bit (come nel mio caso) ignori completamente l'attributo CDECL anche se tu richiedi specificatamente di compilare per x86 / 32 Bit gli argomenti invece che essere passati attraverso lo stack sono passati nei registri! Così la mia bellissima Fill16Asm "poppava" chissà che cosa

Così soffrendo come una bestia ho usato una Ubuntu a 32 bit con MonoDevelop e finalmente funzionava come un cavallo...

Ho testato tutti i casi possibili e quello di nostro interesse un buffer di quasi 9 MB viene riempito in 7 ms

Tutto ingorillato lo provo su Cosmos sicuro al 100% che sarebbe andato alla prima e invece Stack Overflow

De' "La Cosmos Calling Convention"

No, Cosmos non usa CDECL manco un po' (gli argomenti passati sullo stack e il valore di ritorno in EAX):

1. Gli argomenti sono sì sullo stack, ma all'incontrario (il primo argomento è l'ultimo)
2. Il valore di ritorno è scritto al posto dell'ultimo argomento (ovvero l'ultimo ) se la funzione non aveva argomenti o per esempio aveva un int e si deve ritornare un long (8 byte) lo spazio nello stack si "crea"

Ah povero me usavo pure l'istruzione "ret" pensando - ingenuotto - che fosse la stessa cosa di "return" in C... invece manipolava lo stack come se si usasse chissà quale degli 50 calling convention di x86... e questo faceva a pugni con il nostro metodo per detectare lo stack overflow!

In realtà il punto "2" avviene automaticamente, ma il fatto che gli argomenti andavano messi all'incontrario mi ha lasciato perplesso...

Faccio notare prima che vi emozionate tutti che siamo perfettamente consapevoli che questo non è il modo più veloce per passare parametri / valori di ritorno, questa è solo una versione temporanea poi quando saremo alla versione 1.0 di Cosmos e sarà il momento di ottimizzare per arrivare a essere 20 volte più veloci del C++ (slogan? Probabile ) ci penseremo in seguito alla giusta stragegia di "bilanciamento" traad registri e stack...

Al momento questa calling convention (CCC) usata è la più vicina alla VM di .Net e questo - di fatto - ci semplifica la vita.

Comunque alla fine ha funzionato come un cavallo tempo su Cosmos: 430 ms!
Beh rispetto a 33 secondi è un ENORME miglioramento, ma perché non ottengo un valore simile a 7 ms?

Ricordatevi che Bochs è una "vera" macchina virtuale e simula anche la CPU... io ho un Core I5, ma lui sta attualmente simulando un Pentium IV quindi in conclusione è tutto OK!

Ora - finalmente - anche la Clear() è quasi istantanea si vede ancora un pochino "designare", ma è accettabile.

Fill() / Memset(), Memcmp(), Memcpy() ovvero la classe MemoryOperations

Prima di tutto qual è la differenza tra Fill() e Memset()? TL;RD la prima fa quello che ti aspetti la seconda no!

La Memset() del C ha questo "grazioso" prototipo:

void *memset(void *s, int c, size_t n);

'int c' è una trappola! Perché viene castato a byte mentre siete distratti quindi se avessi dovuto farlo in C avrei in ogni caso dovuto scrivermela in assembler o chissà quali truschi fare: il Colore blu è un "vero" intero (0x0000FF)
In C++ sarebbe stato effettivamente meglio visto che la funzione Fill() è fatta con i template e quindi se hai un buffer di interi e 'c' è un intero fa quello che ti aspetti... in C# esiste (esisterà?) Fill() con questo prototipo:

void Fill<T>(T[] buffer, T value)

ma la versione dentro .NET Core usa il for() che ti frega se buffer è troppo grande!

La mia Fill() usando un linguaggio ad oggetti esiste in tante forme questa è quella base che "assomiglia" alla memset():

unsafe public static void Fill(byte* dest, int value, int size)

ci sono overload unsafe sia per puntatori a tipi primitivi che per array di tipi primitivi, il prototipo non usa i tipi "insensati" del C (void *, size_t, int che sono unsigned char ) e - ovviamente - non ritorna nulla al massimo andrà in eccezione invece che andare in SEGFAULT.

Oltre che nel mio caso c'è pieno di posti dentro il runtime C# dove Fill() sarebbe utile per esempio:

1. La Fill dell'Array di cui sopra
2. Il nuovo tipo Span<T> di C#7 ha anche lui un metodo Fill
3. L'istruzione IL initblk non è altro che una fill() con value sempre a 0
4. C'è una ZeroFill() dentro ai sorgenti di Cosmos che non so per cosa sia usata

Il punto 3 è forse il punto "dolente" il modo corretto sarebbe infatti di fare correttamente initblk e molti di quei metodi si ridurrebbero a una chiamata initblk forse è un po' una sorpresa, ma anche le versioni dentro il .Net Framework NON chiamano la initblk, ma si ri-implementato "Fill" spesso più volte.
(spiegazione? La initblk è inefficiente! Perché non riscrivono quella? Boh...)

Le altre due che probabilmente finiranno per chiamarsi Memory.Cmp() e Memory.Copy() servono sicuramente per CGS perché per avere un po' di velocità non ha senso ridisegnare lo schermo tutte le volte, ma devi implementare il double buffering e quindi ti serve un modo veloce per confrontare 2 buffer anche molto grandi e per copiarli!

Memory.Copy() è usata anche nel runtime per esempio ogni volta che si passa un ValueType ad una funzione questo viene copiato (come in C++), il boxing non è altro che la creazione dal "nulla" dell'header dell'oggetto con la copia della parte dati...

Memory.Cmp() forse solo quando si fa l'uguaglianza tra stringhe.

Un punto aperto che devo capire è come dove mettere questa classe (anche il nome mica mi piace molto, ma Memory era già usato) per ora l'ho messo in Core, ma probabilmente dovrebbe essere metodi "intrisechi" di IL2CPU così che possano essere usati un po' ovunque.

Interessante come da pulire lo schermo di blu sia uscito tutto questo casino

Net Core

Siamo veramente vicini ad avere un Cosmos che usa Net Core invece di "Net Framework" purtroppo il numero dei plug credo non sia poi molto diminuito, ma per fare bene i plug abbiamo bisogno di uno strumento di analisi esterno per capire davvero quanto lavoro ci sia da fare (IL2CPU ti dice "native method encountered", ma non hai modo per capire quanto tu debba ancora "pluggare" e che magari se lo facevi a basso livello avresti fatto prima!).

Comunque tutti i test passano di nuovo, l'unico problema che stanno avendo è sui template che ti permettono di creare un nuovo kernel che in Net Core sono completamente diversi (la Microsoft ha buttato via il formato XML di VisualStudio per passare ad uno in json), superato questo ostacolo tutto può essere mergiato!

Avere Net Core ci farà procedere molto più speditamente rispetto a Net Framework anche solo la possibilità di vedere i sorgenti liberamente dell'implementazione (compresa quella in C++ / codice nativo) ci semplificherà enormemente la vita.

... mentre Net Core viene portato dentro Net Core tutti gli altri che fanno?

Visto che abbiamo più di 228 potenziali "sviluppatori" (!) dovevamo trovare il modo di "distrarli" mentre Net Core veniva portato dentro Cosmos, ma allo stesso tempo non dovevano esserci attività che si sovrapponevo con Net Core (per esempio non ha senso pluggare Dictionary<T>, magari in Net Core funziona già!) quindi ho identificato 4 attività che potevano essere fatte in parallelo:

https://github.com/CosmosOS/Cosmos/issues/546 (libera)
https://github.com/CosmosOS/Cosmos/issues/545 (in sviluppo)
https://github.com/CosmosOS/Cosmos/issues/544 (libera)
https://github.com/CosmosOS/Cosmos/issues/543 (libera, c'è stato un tentativo di farla, ma ci siamo persi in un loop di "native code encountered" )
https://github.com/CosmosOS/Cosmos/issues/542 (in sviluppo)

La più degna di nota è che ho seguito più a lungo è 545 ovvero come fare ad avere le informazioni sulla CPU? L'obiettivo finale è avere una classe "ripiena" di proprietà che permetta di implementare su un Cosmos a linea di comando il comando CpuInfo (o se uno è pazzo e vuole fare un sistema POSIX like il "file" /proc/cpuinfo) mentre su una GUI qualcosa di simile a quello che appare premendo il tasto destro su "Il Mio PC" in Windows.

Questo introduce un altro capitolo... un incubo:

SMBIOS ovvero "The Worst is better"

In Cosmos esiste già una classe in Core che non è altro che un wrapper dell'istruzione assembler cpuinfo, non è bellissima forse, ma bastava creare una facade in HAL (o meglio forse dividere in 2 il "motore" in assembler in Core e il codice vero e proprio in HAL) e una in System e via!

Invece no... il ragazzetto ha trovato SMBIOS che ci ha fatto promesse mirabolanti:

1. Sono "semplici" strutture quindi niente assembler: il codice può essere tutto scritto in HAL tutto in C#!
2. Sembra la cosa "giusta" visto che funziona anche su ARM, PowerPC ed Itanium (RIP)
3. Ci da la possibilità di avere un "framework" per avere un sacco di altre informazioni: tipo di BIOS, marca della motherboard, marca della Memoria...

Il primo punto si è rilevato falso le strutture non sono affatto "semplici" intanto non c'è un punto fisso per l'entry point ma bisogna cercare in un range di memoria di 1024 caratteri la stringa "DFI" () poi invece di fare come tutte le strutture che ho visto in vita mia in C in cui le "stringhe" sono array di caratteri con un dimensione schiantata in questo caso hanno deciso di fare una cosa "esotica" invece della stringa mettono un byte che è l'indice di una area di memoria che segue la struttura che loro chiamano "non formattata" che non è altro con un bugliolo di byte / caratteri ASCII separati tra di loro dal classico '\0'... il bugliolo di caratteri termina - a sua volta - con un altro '\0'! Fico vero?

Il ragazzo che lo stava sviluppando si lamenta subito contro dei non ben precisati "ingegneri" mandandoli a c*gare direttamente dentro il commit che per computare una lunghezza si deve inventare una nuova "matematica"... dopo mesi scopro il suo errore Bochs come molti progetti Open Source segue la filosofia "The Worst is better" e quindi benché dichiarino di usare la versione X.X e nelle specifiche c'è la parte dati è 21 byte, in realtà implementano la versione vecchia e quindi da leggere ci sono 18 byte... le specifiche comunque sono chiare la versione l'abbiamo messa come "padding" e si deve usare il campo len...
(io che lavoro da anni con queste cose non ci sarei cascato il ragazzo faceva come molti inesperti alcuni anche di ditte a noi "avversarie" leggeva 21 + header in un unico buffer e poi si aspettava di trovare le cose agli offset attesi)

Tutto OK direte voi? Manco per nulla su VmWare si leggono valori sensati su Bochs tutte le stringe sono null / vuote e i valori numeri graziosissimi 0... io speravo che il ragazzo avesse fatto casino o che magari esistesse qualche Kludge per Bochs (magari come molte applicazioni OpenSource ha i default sbagliati e va configurato correttamente), ma purtroppo Ubuntu conferma che è tutto giusto e che SMBIOS non serve ad una mazza:



perché non solo Bochs fa schifo, ma pare che sia una cosa normale / possa capitare che SMBIOS dica putt*nate per esempio con BIOS cinesi:

http://www.linux-mag.com/id/7768/

Bah io non so che dire davvero... Intel, ARM, IBM, Microsoft... un manuale bello corposo di 350 pagine e poi "Family Other", "Frequency Not Specified", ...!

Quindi? Quindi consideriamoci fortunati: era una "trappola" e meno male che Bochs fa schifo e ce l'ha mostrata prima che prendessimo una "dipendenza" da sto SMBRATTA... certo è un po' brutto dover buttare quasi un mese di lavoro e mica sono sicuro che il povero ragazzo non ha completamente capito che deve cacciare via tutto

[1] C'è ancora spazio di ottimizzazione, il for() potrei farlo a blocchi di int (se il resto è divisibile per 4), poi di short e solo alla fine di byte, ma soprattutto nella versione in assembler potrei copiare a blocchi di 64 o 32 facendo "loop unrolling".

[cdimauro]

Permettimi un'osservazione: non devi essere tu a stravolgere quel loop cercando di velocizzare la Fill e le altre funzioni di memoria. Questa dev'essere roba affidata al compilatore.

Sì, è presto per parlare di ottimizzazioni, lo so, ma voglio dire che non devi perdere prezioso tempo per una cosa che, se tutto ciò che ho letto sarà in buona parte vero, verrà fuori automaticamente / autonomamente grazie ai miglioramenti del backend.

Comunque è importante che tu abbia risolto i problemi che avevi con la definizione e uso dello schermo. E' un grosso passo avanti. Ma sei in grado di selezionare / cambiare al volo una qualunque modalità VESA? Questo è anche molto importante.

[fano]

Originariamente inviato da cdimauro

Permettimi un'osservazione: non devi essere tu a stravolgere quel loop cercando di velocizzare la Fill e le altre funzioni di memoria. Questa dev'essere roba affidata al compilatore.

Infatti come ho scritto poi nel capitolo che ho aggiunto ora "Fill() / Memset(), Memcmp(), Memcpy() ovvero la classe MemoryOperations" queste operazioni sono così "generiche" che letteralmente non sapevo dove metterle per ora sono in Core, ma avevo intuito che il posto giusto era dentro "IL2CPU"...

O intendi dire che il compilatore dovrebbe essere così furbo da "intuire" che quel for() era la memset() GCC lo fa anche con risultati un po' comici quando beh uno vuole implementare la... memset():

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888

(no non l'hanno risolto è ancora lì pronto a inlooparsi in eterno hanno solo aggiunto un'altro flag ai migliaia già esistenti, il default ovviamente è sbagliato)

Originariamente inviato da cdimauro

Sì, è presto per parlare di ottimizzazioni, lo so, ma voglio dire che non devi perdere prezioso tempo per una cosa che, se tutto ciò che ho letto sarà in buona parte vero, verrà fuori automaticamente / autonomamente grazie ai miglioramenti del backend.

E' probabile sì il fatto è che a parte il colore blu che a me piace perché ricorda il C=64 la Fill() è necessaria perché Bochs lascia lo schermo "sporco" quando si passa in modalità grafica come se cercasse di interpretare il testo precedente come pixel... e far attendere 33 secondi non è bello!

Comunque anche se Fill() finirà un giorno dentro al compilatore il codice l'ho già scritto sarà compito delle ottimizzazioni far sparire lo switch se non serve (magari nel caso fortunato trasformando il tutto in un'assegnazione tra interi), facendo fuori il for se il resto è 0... e lasciando solo l'assembler magari ricopiandolo alla fine in linea come fanno GCC e Clang.

L'implementazione che ho fatto è volutamente "incompleta" visto che come ho detto potevo fare blocchi da 64 e da 32, ma era mio interesse avere qualcosa che funzionasse il prima possibile.

Originariamente inviato da cdimauro

Comunque è importante che tu abbia risolto i problemi che avevi con la definizione e uso dello schermo. E' un grosso passo avanti. Ma sei in grado di selezionare / cambiare al volo una qualunque modalità VESA? Questo è anche molto importante.

In realtà per ora questo funziona solo con Bochs e con gli emulatori che condividono la stessa GPU virtuale (QEMU e VirtualBox) è una versione semplificata di VESA visto che ti permette di fare tutto usando una normale porta di I/O comunque sì posso cambiare risoluzione anche mentre sono in modalità grafica e grazie "al trucco" che alloco più memoria del necessario se lo schermo è più grande il blu c'è sempre! E ti dico di più se disegno un altro oggetto dopo aver cambiato risoluzione questo appare persino (temevo che facesse casino magari con le coordinate).
E Bochs arriva davvero a 1920x1200... semplicemente perché non controlla una fava se fosse per lui anche 0x0 è OK... alcuni risoluzioni pare lo facciano andare pure in SEGFAULT
Purtroppo ModeInfo non la espongono quindi io ho "hardcodato" tra i modi accettati quelli che hanno più senso (con tanto di schermi 4:3, 5:4, 16:9 e 16:10).

Resto dell'idea che invece la vera perdita di tempo è il driver della VGA legacy cosa serve nel 2017 inoltrato 320x200 a 256 colori o che fa ancora più ridire 640*480 a 16 colori? Il mio schermo va a 1920x1080 e fa 16'000'000 di colori

Il mio piano è questo convincere gli utenti a:

1. Completare CGS mancano ancora dei metodi DrawImage e DrawString
2. Portare alla "luce" il driver di VmWare che abbiamo pure tra i sorgenti... chissà se funziona: https://github.com/CosmosOS/Cosmos/b...MWareSVGAII.cs
   è di particolare interesse perché validerebbe la "genericità" di CGS e ha già alcune funzionalità accelerate
3. Un'altra VM interessante da supportare è HiperV anche se sembra complessa se davvero usa solo UEFI
4. Se davvero la "velocità" è così importante possono provare ad implementare un double buffer, ma dentro al driver non a livello utente come ho visto in alcuni kernel Cosmos
5. A quel punto uno potrebbe creare un "modalità testuale" più bella evitando gli incubi delle codepage usando direttamente UTF-16... l'Arabo che si scrive all'incontrario e con le legature resta un incubo! Infatti Linux mica è capace...
   Potresti pure aprire un ImageViewer "grezzo" cosa che con Linux in modalità testuale ti scordi perché hai bisogno di X per mostrare "finestre"
6. Cosmos Widget Toolkit magari?
7. Il vero VESA con tanto di emulatore 8086 di cui ben sai (a proposito a che punto sei?)

Tutto questo ha senso "relativo" visto che Cosmos manco ha il garbage collector quindi primo o poi la macchina Virtuale se ne accorge e andrà in Core immagino

Riguardo a SMBIOS invece? Perché è una "trappola"? Non c'è proprio altra possibilità che usare l'assembler a questo punto vero?

Ah ho visto che parlavate di X# il fatto che è verboso è dovuto in realtà al fatto che manca in Visual Studio / Roslyn il modo di "embeddare" un altro linguaggio dentro C# sarebbe utile non solo nel nostro caso, ma uno potrebbe volere embeddare per esempio F# o VB.NET dentro C# o IL in linea (l'equivalente nel mondo .NET di quando in GCC si butta assembler dentro un sorgente C), il vero X# è molto più coinciso:

https://github.com/CosmosOS/Cosmos/b...b/Screen.xs#L9

ma appunto non può essere embeddato dentro C#!
(ma forse un giorno lo faranno c'è un issue aperta alla Microsoft speriamo che ci pensino seriamente)

Abbiamo bisogno della nostra "versione" di assembler anche per un altro motivo attualmente X# è "transpilato" in assembler NASM, ma questo è temporaneo dovremo un giorno scrivere il nostro assembler per quando avremo le applicazioni dentro Cosmos (che prima di essere eseguite andranno compilate ovviamente).

[cdimauro]

Originariamente inviato da fano

Infatti come ho scritto poi nel capitolo che ho aggiunto ora "Fill() / Memset(), Memcmp(), Memcpy() ovvero la classe MemoryOperations" queste operazioni sono così "generiche" che letteralmente non sapevo dove metterle per ora sono in Core, ma avevo intuito che il posto giusto era dentro "IL2CPU"...

O intendi dire che il compilatore dovrebbe essere così furbo da "intuire" che quel for() era la memset() GCC lo fa anche con risultati un po' comici quando beh uno vuole implementare la... memset():

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888

(no non l'hanno risolto è ancora lì pronto a inlooparsi in eterno hanno solo aggiunto un'altro flag ai migliaia già esistenti, il default ovviamente è sbagliato)

Con la differenza che lì era la memset che tentava di richiamare se stessa, mentre per le tue funzioni sarebbe il backend del compilatore che si accorge del loop semplice, ed emette codice apposito, che non ne necessariamente sia una chiamata a funzione specializzata.

Da Haswell in poi le istruzioni "di stringa" (quelle complesse / legacy introdotte con l'8086 ) sono state notevolmente velocizzate, e bastano 2-3 byte in totale per usarle: meno di una call.

E' probabile sì il fatto è che a parte il colore blu che a me piace perché ricorda il C=64 la Fill() è necessaria perché Bochs lascia lo schermo "sporco" quando si passa in modalità grafica come se cercasse di interpretare il testo precedente come pixel... e far attendere 33 secondi non è bello!

Comunque anche se Fill() finirà un giorno dentro al compilatore il codice l'ho già scritto sarà compito delle ottimizzazioni far sparire lo switch se non serve (magari nel caso fortunato trasformando il tutto in un'assegnazione tra interi), facendo fuori il for se il resto è 0... e lasciando solo l'assembler magari ricopiandolo alla fine in linea come fanno GCC e Clang.

L'implementazione che ho fatto è volutamente "incompleta" visto che come ho detto potevo fare blocchi da 64 e da 32, ma era mio interesse avere qualcosa che funzionasse il prima possibile.

OK, se l'hai scritto, lascialo. Ma non ci perdere altro tempo.

In realtà per ora questo funziona solo con Bochs e con gli emulatori che condividono la stessa GPU virtuale (QEMU e VirtualBox) è una versione semplificata di VESA visto che ti permette di fare tutto usando una normale porta di I/O comunque sì posso cambiare risoluzione anche mentre sono in modalità grafica e grazie "al trucco" che alloco più memoria del necessario se lo schermo è più grande il blu c'è sempre! E ti dico di più se disegno un altro oggetto dopo aver cambiato risoluzione questo appare persino (temevo che facesse casino magari con le coordinate).
E Bochs arriva davvero a 1920x1200... semplicemente perché non controlla una fava se fosse per lui anche 0x0 è OK... alcuni risoluzioni pare lo facciano andare pure in SEGFAULT
Purtroppo ModeInfo non la espongono quindi io ho "hardcodato" tra i modi accettati quelli che hanno più senso (con tanto di schermi 4:3, 5:4, 16:9 e 16:10).

So come funziona Bochs. Ma se non espone nemmeno il ModeInfo è una vera ciofeca. Considerato tutto il tempo che c'ha perso, perché non passi direttamente a VMWare, che ha un'emulazione MOLTO più accurata?

Resto dell'idea che invece la vera perdita di tempo è il driver della VGA legacy cosa serve nel 2017 inoltrato 320x200 a 256 colori o che fa ancora più ridire 640*480 a 16 colori? Il mio schermo va a 1920x1080 e fa 16'000'000 di colori

Lascia perdere anche questo: vai di VESA e basta. Non ha alcun senso buttare tempo per supportare la VGA (classe 1987!!!).

Il mio piano è questo convincere gli utenti a:

1. Completare CGS mancano ancora dei metodi DrawImage e DrawString
2. Portare alla "luce" il driver di VmWare che abbiamo pure tra i sorgenti... chissà se funziona: https://github.com/CosmosOS/Cosmos/b...MWareSVGAII.cs
   è di particolare interesse perché validerebbe la "genericità" di CGS e ha già alcune funzionalità accelerate
3. Un'altra VM interessante da supportare è HiperV anche se sembra complessa se davvero usa solo UEFI
4. Se davvero la "velocità" è così importante possono provare ad implementare un double buffer, ma dentro al driver non a livello utente come ho visto in alcuni kernel Cosmos
5. A quel punto uno potrebbe creare un "modalità testuale" più bella evitando gli incubi delle codepage usando direttamente UTF-16... l'Arabo che si scrive all'incontrario e con le legature resta un incubo! Infatti Linux mica è capace...
   Potresti pure aprire un ImageViewer "grezzo" cosa che con Linux in modalità testuale ti scordi perché hai bisogno di X per mostrare "finestre"
6. Cosmos Widget Toolkit magari?
7. Il vero VESA con tanto di emulatore 8086 di cui ben sai (a proposito a che punto sei?)

Ho cambiato lavoro e arrivo a casa abbastanza stanco in questo periodo: l'ultima cosa che m'interessa è buttarmi sui miei progetti. Ma la situazione va migliorando, mi sto integrando, un sacco di cose le ho imparate, e quindi prevedo di rimettermi a smanettare fra qualche tempo.

Delle cose che hai detto lascerei perdere completamente il supporto all'Hyper-V. E i idem il double buffer, visto che ormai ti funziona tutto sufficientemente.

Mentre al momento lascerei perdere anche l'UTF-16: l'ASCII / Latin-1 va benissimo per un s.o. ancora in sviluppo.

Tutto questo ha senso "relativo" visto che Cosmos manco ha il garbage collector quindi primo o poi la macchina Virtuale se ne accorge e andrà in Core immagino

Riguardo a SMBIOS invece? Perché è una "trappola"? Non c'è proprio altra possibilità che usare l'assembler a questo punto vero?

Non lo conosco, e non so come si usa, per cui non ti saprei dire.

Ah ho visto che parlavate di X# il fatto che è verboso è dovuto in realtà al fatto che manca in Visual Studio / Roslyn il modo di "embeddare" un altro linguaggio dentro C# sarebbe utile non solo nel nostro caso, ma uno potrebbe volere embeddare per esempio F# o VB.NET dentro C# o IL in linea (l'equivalente nel mondo .NET di quando in GCC si butta assembler dentro un sorgente C), il vero X# è molto più coinciso:

https://github.com/CosmosOS/Cosmos/b...b/Screen.xs#L9

ma appunto non può essere embeddato dentro C#!
(ma forse un giorno lo faranno c'è un issue aperta alla Microsoft speriamo che ci pensino seriamente)

Abbiamo bisogno della nostra "versione" di assembler anche per un altro motivo attualmente X# è "transpilato" in assembler NASM, ma questo è temporaneo dovremo un giorno scrivere il nostro assembler per quando avremo le applicazioni dentro Cosmos (che prima di essere eseguite andranno compilate ovviamente).

Se fosse possibile, al momento userei direttamente l'assembly con NASM, da linkare poi col vostro codice. Davvero, con X# non ci lavorerei mai: troppo, troppo prolisso.

[fano]

Originariamente inviato da cdimauro

Con la differenza che lì era la memset che tentava di richiamare se stessa, mentre per le tue funzioni sarebbe il backend del compilatore che si accorge del loop semplice, ed emette codice apposito, che non ne necessariamente sia una chiamata a funzione specializzata.

Ma in che senso "emette" codice? Cioè GCC / Clang hanno un'implemtazione interna di memset()/memcmp()/memcpy() giusto?

Io credevo che effettivamente usassero quelle ed il fatto che poi nell'assembler generato ne vedessi solo un pezzetto fosse dovuto ai passi di ottimizzazione invece come fanno ad arrivare a questo?

https://godbolt.org/g/RuS5Bd

Originariamente inviato da cdimauro

Da Haswell in poi le istruzioni "di stringa" (quelle complesse / legacy introdotte con l'8086 ) sono state notevolmente velocizzate, e bastano 2-3 byte in totale per usarle: meno di una call.

Ma le istruzioni stringa non copiano comunque a blocchi d'interi (byte, word, doubleword o su x64 quadword)? Quindi usare comunque i registri XMM e copiare a botte di 16 Byte o meglio ancora di 32 o 64 non è in ogni caso più veloce?
Il fatto che il compilatore Intel non le usi, ma usi il mio metodo mi fa pensare che sia meglio...

Originariamente inviato da cdimauro

OK, se l'hai scritto, lascialo. Ma non ci perdere altro tempo.

No dal mio punto di vista il lavoro su CGS è per ora finito lo diamo "in bocca" ai famelici users e vediamo cosa ne combinano

Originariamente inviato da cdimauro

So come funziona Bochs. Ma se non espone nemmeno il ModeInfo è una vera ciofeca. Considerato tutto il tempo che c'ha perso, perché non passi direttamente a VMWare, che ha un'emulazione MOLTO più accurata?

Sì tra le "funzioni" esposte con la IOPort c'è ben poco cambio modo (che manco da la possibilità di ritornare in modalità testuale ), disegna un pixel e poco altro...

Vedi l'utilità di Bochs io la vedo in due cose:

1. Il fatto che possa emulare praticamente ogni CPU x86 esistente e anche via configurazione "inventarmi" CPU particolari tipo un 486 con AVX
2. Il debugger integrato che mi permette di vedere quali valori sono dentro ai registri, utile soprattutto se uno è ancora inesperto di Assembler come me e scrive codice "a caso". VmWare in quei casi si stronca brutalmente

Poi visto che il target principale di Cosmos - almeno per adesso sono le VM - è chiaro che vanno supportate tutte e in particolare VmWare (in fondo è quella più usata) che - infatti - a parte la grafica è perfettamente supportato da Cosmos e i nostri Unit Test sono già predisposti per testare ambedue le VM.

Poi il tempo che ci ho perso è più dovuto alla mia voglia di "smanettare" e all'immaturità del runtime che altro il driver (quello di basso livello) Bochs / VBE esisteva già e funzionava pure!

Originariamente inviato da cdimauro

Lascia perdere anche questo: vai di VESA e basta. Non ha alcun senso buttare tempo per supportare la VGA (classe 1987!!!).

Mi fa piacere che sto ragionando nella maniera corretta... non ha più senso supportarlo è troppo "antico", meglio concentrarci su VESA

Originariamente inviato da cdimauro

Ho cambiato lavoro e arrivo a casa abbastanza stanco in questo periodo: l'ultima cosa che m'interessa è buttarmi sui miei progetti. Ma la situazione va migliorando, mi sto integrando, un sacco di cose le ho imparate, e quindi prevedo di rimettermi a smanettare fra qualche tempo.

OK, nel frattempo ho cercato emulatori x86 che - teoricamente - dovrebbero essere stati creati per lo stesso scopo (cioè emulare 8086 per far funzionare VESA) ed ho trovato quello che dovrebbe essere usato da X:

https://github.com/wfeldt/libx86emu

la licenza è pure BSD quindi compatibile con Cosmos, ma - purtroppo - il codice fa alquanto schifo un bel filone (non di pane, ma un grosso "file") da un milione di righe fatto a botte di copia & incolla:
https://github.com/wfeldt/libx86emu/blob/master/ops.c

perché il codice scritto in C ha la tendenza a fare sempre così schifo? Io un po' al C la colpa la do non "forzando" la struttura ad uno viene naturale fare ste porcate... ciò non toglie che - sforzandosi - un pochino anche in C le cose possono esser fatte meglio!
Le funzioni - almeno quelle - in C le hanno fatte

Mi chiedo, ma serve tutta quella roba o per parlare con VESA si può implementare un sub-set? Il tuo sarà un emulatore completo di 8086 come questo oppure qualcosa di più semplice?

Ci sono altri casi in cui ha senso emulare 8086 in un sistema operativo? Esiste qualche altro layer "sfigato" come VESA che funziona solo in "Real Mode" a 16 Bit?

Originariamente inviato da cdimauro

Delle cose che hai detto lascerei perdere completamente il supporto all'Hyper-V. E i idem il double buffer, visto che ormai ti funziona tutto sufficientemente.

Delle elenco che ho postato io mi occuperei solo della coordinazione, l'intenzione è che io torni ad occuparmi delle cose a basso livello... la cosa più ungente è avere questo "Plug Inspector" io vorrei riuscire entro la fine del 2017 (l'anno di Cosmos ) ad avere almeno tutte le classi della BCL funzionanti altrimenti molto spesso ti trovi a scrivere quasi in C++ / Java il che non è bello (potremmo chiamarlo C# 0 ).

Il lavoro su HiperV è in realtà già iniziato, il problema sembra essere nel modo diverso in cui ti danno a disposizione la debug console e che sta creando qualche problema:

https://github.com/CosmosOS/Cosmos/pull/550

Originariamente inviato da cdimauro

Mentre al momento lascerei perdere anche l'UTF-16: l'ASCII / Latin-1 va benissimo per un s.o. ancora in sviluppo.

Per ora sulla Console in modalità testuale in realtà viene supportato solo ASCII a me da un po' noia avere la possibilità di settare la tastiera con la keymap italiana e poi ottenere caratteri strani invece che 'è'... mi ricorda troppo Linux questo

La modifiche da fare sono poca roba in realtà la stringa C# viene trasformata in un array di Char e ogni singolo Char viene "violentemente" castato a Byte ovviamente in questo modo solo i caratteri ASCII sopravvivono si devono semplicemente chiamare le funzioni di encode / decode di C# e tutto dovrebbe funzionare.

Il discorso di avere il Terminale come "Terminale Virtuale" (cioè fatto in modalità grafica) richiede di sicuro più tempo però visto che ora abbiamo 228 potenziali sviluppatori e fare "grafica" è una cosa che di sicuro potrebbe invogliarli di più a collaborare è "il primo blocco" per avere un sistema operativo "Desktop" (che a me interessa relativamente... a me interessa avere più gli Widget visto che le mie GUI sono sempre kioscate).

Originariamente inviato da cdimauro

Non lo conosco, e non so come si usa, per cui non ti saprei dire.

Peccato speravo potessi darci qualche "dritta"! Non sai se esistono modi alternativi per avere informazioni sulla CPU a parte usare l'istruzione cpuinfo?

Originariamente inviato da cdimauro

Se fosse possibile, al momento userei direttamente l'assembly con NASM, da linkare poi col vostro codice. Davvero, con X# non ci lavorerei mai: troppo, troppo prolisso.

Dai la funzione Cls() nel file che ti ho mostrato non puoi dire che è verbosa è più o meno simile a quello che faresti in C (se potessi farlo)...

Se usassimo direttamente il "dialetto" di Assembler usato da NASM quando Cosmos dovrà diventare "self hosting" dovremmo o fare una versione di NASM in C# (brr...) o riscrivere tutto l'Assembler usando X#.

Provo a fare un po' di "mobbing" per convincere la Microsoft a dare la possibilità di embeddare altri linguaggi dentro C#, devo solo ritrovare l'issue

[fano]

Vediamo se si riesce ad aver questo in C# 7.x / 8.0:

https://github.com/dotnet/csharplang/issues/226

[fano]

Ciao a tutti!

Questa domenica ho cercato di organizzare un po' i lavori futuri e mi è uscita questa lista di cose da aggiungere a CGS: https://github.com/CosmosOS/Cosmos/issues/601.

Però continuo a rimuginarci sopra e non sono sicuro in particolare di alcuni elementi:

1. Disegnare un'immagine è parte di CGS? O potrebbe essere una cosa già di alto livello che dovrebbe essere fatto da uno widget toolkit (che con molta fantasia potrebbe chiamarsi CWTK - Cosmos Widget Tool Kit )?
2. Disegnare testo è parte di CGS? Questo sembra davvero un casino se si pensa di usare il prototipo di System.Drawing: ti porti dietro il concetto di Font (banalmente come faccio a sapere dove nel OS sono i file dei font?) e si vuoi usare lo standard de facto TrueType scopri che dentro ai font c'è una macchina virtuale...

Ho bisogna anche del vostro aiuto riguardo questa issue: https://github.com/CosmosOS/Cosmos/issues/604

[fano]

Salve a tutti!

Finalmente ci siamo:

Il "Core" di Cosmos

Dopo tanto soffrire il porting di Cosmos su Net Core è fatto!
https://github.com/CosmosOS/Cosmos/r...erkit_20170620

Io non ho partecipato direttamente ai lavori, ma il grosso dei problemi non stati tanto per il "porting", ma per il fatto che .Net Core usa un nuovo sistema per i progetti che è stato cambiato in corso d'opera 2 - 3 volte da Microsoft (prima volevano usare file .json, poi ci hanno ripensato e sono tornati all'xml quasi uguale a quello "legacy", ma sempre incompatibile) costringendoci a ricominciare da capo!
Un'altra grossa difficoltà che abbiamo avuto è l'integrazione con Visual Studio che è una fi*ata pazzesca quando funziona debuggare un SO con Visual Studio non ha davvero prezzo, però il problema è che per fare questo bisogna lanciare durante l'installazione uno script .bat che genera i template, le extensions per VS, ecc...
Infatti noterete che ne abbiamo rilasciato 2 di UserKit: il primo non era mica venuto

The Wikipedia conspiracy

Era un 29 Aprile ed ero bello paciarotto che sonnecchiavo pensando al glorioso futuro in cui Cosmos avrebbe fatto funzionare lavatrici, frigoriferi, astronavi quando leggo questo:

https://github.com/CosmosOS/Cosmos/issues/629

Le motivazioni di Wiki sono beh "peurili" a dir poco si riassume nella seguente frase "X# non esiste".
Il mio tentativo di portare prove che X# effettivamente esiste è tacciato di Canvassing:
https://en.wikipedia.org/wiki/Wikipe...letion/X_Sharp
cosa diavole è?
Boh... alla fine non vogliono sentir ragioni e chiudono l'articolo!
Perché mai vi chiederete? Per questo:
https://en.wikipedia.org/wiki/XSharp

questi non solo ci hanno fregato il nome (!), ma pure la pagina su Wiki!
Secondo me - alla fine - Wiki non è "libera" quanto vuol far credere.

Ma non tutto il male vien per nuocere vero?
Due cose positive sono nate da questo:

1. X# può essere utile anche da altri è "high level assembler" e non ha realmente alcun legame con Cosmos! Un giorno X# diventerà un progetto separato e ritornerà su Wiki con fulgore: promesso
2. Dobbiamo avere il nostro sito funzionante

Go Cosmos Go!
... ed infatti eccolo qua in tutta la sua gloria:
http://www.gocosmos.org/

ovviamente c'è la documentazione di X# che Wiki ha scancellato:
http://www.gocosmos.org/docs/xsharp/

ma come vedete c'è anche molto altro in parte travasato da GitHub visto che - in fondo - non è che possiamo fidarci molto nemmeno di loro, magari si svegliano e "falliscono" / "chiudono" e siamo nella bratta...

In futuro credo che dovremo anche aggiungere un forum per certo (la chat di Git è spesso troppo dispersiva) avete altri suggerimenti?

CGS fa progressi

In questo caso un immagine è meglio di mille parole giusto?
Eccovela:



Quel triangolo mi sa che l'avrei disegnato meglio io a mano (e no non sono Giotto, son più sul genere Schifani)... credo manchi un controllo sui vertici per capire se possano davvero creare un triangolo
Sicuramente c'è qualche formula matematica per questo...

DrawImage() e DrawString() sono invece ancora ferme "con le quattro frecce" il fatto è che Canvas è pensato per i metodi che possono essere accelerati in hardware e probabilmente disegnare un'immagine avviene sempre in software o no? Per immagine io intendo non una JPEG o PNG ovviamente, ma la rappresentazione non compressa quindi una semplice BMP! Ma non sono ancora convinto di questo sinceramente... cosa ne pensate?

Scrivere il testo "seriamente" non è una cosa da "signorine" quindi su questo sono convinto che ci vorrà un altra libreria di più alto livello che si smanazza i font truetype, fa tutte le cose "folli" tipografiche per "disegnare" la stringa ecc...

Le 89 "soluzioni" di Cosmos

Il "proprietario" di Cosmos è tornato (!) e non ha gradito molto che Visual Studio facesse passare ben 15 minuti a caricare la soluzione gigantesca che è Cosmos così ha deciso che andava letteralmente fatta a pezzi!
Non so davvero il numero finale ottenuto è 89, ma almeno 8 soluzioni mi sa che son venute.
Direi che era pure l'ora di farlo sto lavoro... di sicuro non era un buon biglietto da visita come era prima la situazione.

L'Ispettore dei Plug
Visto che ora la situazione è stabile (Cosmos compila di nuovo!) ho deciso di riprendere il lavoro sul "Plug Inpector" cito dalla nostra road map:

Plug Tool

IL2CPU should fail if it encounters a plug that isn’t matched/used
Some code exists already as a ilspy plugin, start there
Select an item, generate plug shell to clipboard. Later on to plug source project.
Scan a project, show all existing plugs
Scan a project, show all things that NEED plugged

Abbiamo deciso che il punto di partenza è avere una libreria che genera un file XML l'attuale "Plug Inspector" (non quello integrato in ILSPY) è una normale applicazione Winform che non solo si occupa della presentazione dei dati, ma anche di estrarli questo è poco pratico visto che Cosmos anche se va considerato "future" sarà sicuramente compilabile anche su Mac OS e se uno è masochista pure su Linux... forse proprio usando Visual Studio Code e quindi potremo usare anche altri sistemi per mostrare le informazioni per esempio una form ASP.Net o Avalonia (una versione portabile di WPF).

Per adesso è tutto aspetto i vostri commenti

[GTKM]

"Abbiamo deciso che il punto di partenza è avere una libreria che genera un file XML l'attuale "Plug Inspector" (non quello integrato in ILSPY) è una normale applicazione Winform che non solo si occupa della presentazione dei dati, ma anche di estrarli questo è poco pratico visto che Cosmos anche se va considerato "future" sarà sicuramente compilabile anche su Mac OS e se uno è masochista pure su Linux... forse proprio usando Visual Studio Code e quindi potremo usare anche altri sistemi per mostrare le informazioni per esempio una form ASP.Net o Avalonia (una versione portabile di WPF)."

Ma non si può proprio estirpare XML dalla faccia della Terra, nei secoli dei secoli?

Comunque, bene il sito, ci voleva proprio! 'sto Visual Studio Community si può usare per CosmOS o no? Qua ci volete tutti con Vim mi sa!

[cdimauro]

Mi spiace ma, causa scarsissimo tempo rimasto, ho sostanzialmente abbandonato il forum. Ogni tanto mi arrivano le notifiche ai thread a cui sono sottoscritto, e quando posso guardo i nuovi messaggi, ma finisce lì.

In bocca al lupo per il progetto.

[fano]

Originariamente inviato da GTKM

"Abbiamo deciso che il punto di partenza è avere una libreria che genera un file XML l'attuale "Plug Inspector" (non quello integrato in ILSPY) è una normale applicazione Winform che non solo si occupa della presentazione dei dati, ma anche di estrarli questo è poco pratico visto che Cosmos anche se va considerato "future" sarà sicuramente compilabile anche su Mac OS e se uno è masochista pure su Linux... forse proprio usando Visual Studio Code e quindi potremo usare anche altri sistemi per mostrare le informazioni per esempio una form ASP.Net o Avalonia (una versione portabile di WPF)."

Ma non si può proprio estirpare XML dalla faccia della Terra, nei secoli dei secoli?

Beh ormai XML si è affermato come mezzo di "intercomunicazione" tra processi... l'alternativa sarebbe json, ma non è così ben "integrato" con C#...
Mi ha piacevolmente sorpreso come sia "banale" serializzare una classe in C# e fare l'inverso se penso a come ho sofferto a fare le stesse cose in C con la brattosa libXML2

Originariamente inviato da GTKM

Comunque, bene il sito, ci voleva proprio! 'sto Visual Studio Community si può usare per CosmOS o no? Qua ci volete tutti con Vim mi sa!

Certo che si può usare: io la uso regolarmente
Mi raccomando la versione 2017, il 2015 non è più supportato da Cosmos!

La questione di Visual Studio Code io ho cercato di "bloccarla" quello sì che sembra quasi GVIM (beh dai un po' meglio lo è!).

[GTKM]

Originariamente inviato da fano

Beh ormai XML si è affermato come mezzo di "intercomunicazione" tra processi... l'alternativa sarebbe json, ma non è così ben "integrato" con C#...
Mi ha piacevolmente sorpreso come sia "banale" serializzare una classe in C# e fare l'inverso se penso a come ho sofferto a fare le stesse cose in C con la brattosa libXML2

Da quel po' che ho letto di sfuggita, mi pare che libxml2 sia una roba un filino buggata.
Per il resto, beh, speriamo che un giorno si riesca ad eliminare XML.

Originariamente inviato da fano

Certo che si può usare: io la uso regolarmente
Mi raccomando la versione 2017, il 2015 non è più supportato da Cosmos!

La questione di Visual Studio Code io ho cercato di "bloccarla" quello sì che sembra quasi GVIM (beh dai un po' meglio lo è!).

Beh, l'unico motivo per usare Vim è la possibilità di farci tutto con shortcuts da tastiera. Quale sia l'utilità di GVIM non mi è ben chiaro.

Visual Studio Code è un editor di testo sotto steriodi. Non so perché l'abbiano fatto, ma tant'è.

Comunque tempo fa mi pare mi avessi detto che la versione Community di VS non fosse supportata, per quello ho chiesto, ma forse avevo capito male io.

[fano]

L'unico vantaggio di GVIM rispetto a VIM è che essendo con GUI posso tenere aperto più di un file contemporaneamente insomma il "multitasking" roba da far tremare le ginocchia!
Io a volte visto che trovo "disordinato & incomprensibile" come si dovrebbe lavorare su Linux ne ho aperte 89 copie... a volte con file aperti anche più volte
e quell'aborto inizia a creare quegli inutile file .swp... che schifo di modo di lavorare!

Capisci che il fatto che dopo 15 anni che esiste XML, libxml2 sia "ancora un po' bacata" è preoccupante dai... ma poi lasciamo stare bacata o non bacata con C# creo le classi e gli dico "serialize" e via ho il mio XML bello e fatto con libxml2 devo farmelo direttamente a mano...

Addirittura avendo l'XSD c'è un tool che ti crea le classi direttamente: https://docs.microsoft.com/en-us/dot...n-tool-xsd-exe

Mah poi io ho colleghi che preferiscono farsi l'XML a botte di sprintf()... ma quelli sono pazzi lasciamo perdere

Io vorrei eliminare il C non XML, comunque non so se si era... intuito

Comunque se vuoi / volete collaborare al progetto:
http://www.gocosmos.org/download/

[GTKM]

Originariamente inviato da fano

L'unico vantaggio di GVIM rispetto a VIM è che essendo con GUI posso tenere aperto più di un file contemporaneamente insomma il "multitasking" roba da far tremare le ginocchia!
Io a volte visto che trovo "disordinato & incomprensibile" come si dovrebbe lavorare su Linux ne ho aperte 89 copie... a volte con file aperti anche più volte
e quell'aborto inizia a creare quegli inutile file .swp... che schifo di modo di lavorare!

Capisci che il fatto che dopo 15 anni che esiste XML, libxml2 sia "ancora un po' bacata" è preoccupante dai... ma poi lasciamo stare bacata o non bacata con C# creo le classi e gli dico "serialize" e via ho il mio XML bello e fatto con libxml2 devo farmelo direttamente a mano...

Addirittura avendo l'XSD c'è un tool che ti crea le classi direttamente: https://docs.microsoft.com/en-us/dot...n-tool-xsd-exe

Mah poi io ho colleghi che preferiscono farsi l'XML a botte di sprintf()... ma quelli sono pazzi lasciamo perdere

Io vorrei eliminare il C non XML, comunque non so se si era... intuito

Comunque se vuoi / volete collaborare al progetto:
http://www.gocosmos.org/download/

Beh dai, Emacs con 5-6 plugin è una potenza, il problema è arrivare ad una configurazione buona (un classico...). Immagino che con Vim sia uguale.

Per il resto, già sai che ci sono un sacco di cose vecchie e ancora bacate, ne abbiamo discusso estensivamente ahah
XML a colpi di sprintf () ha un non so che di romantico...

Al momento sono impelagato in una libreria multithreaded in C. Mutex come se non ci fosse un domani.

Sent from my HUAWEI VNS-L31 using Tapatalk

[fano]

Originariamente inviato da GTKM

Beh dai, Emacs con 5-6 plugin è una potenza, il problema è arrivare ad una configurazione buona (un classico...). Immagino che con Vim sia uguale.

Mah purtroppo sono scelte aziendali... mai usato Emacs, ma conoscendomi mi farebbe schifo pure quello! Io voglio poter usare un IDE... mi accontento pure di Eclipse (no QtCreator mi ha fatto rimpiangere GVIM), ma non si può nel 2017 inoltrato continuare ad usare GVIM + Make da linea di comando dai!

Pensa alla cosa assurda che il cliente (che è il proprietario dei sorgenti) ci ha espressamente richiesto che lavorassimo con Eclipse visto che - purtroppo - vogliono metterci le mani anche loro nel codice ( ) e la gente normale di fare Make sul terminale non vuole nemmeno sentirne parlare... beh abbiamo trovato un "trusco" che permette ad Eclipse di pupparsi i Makefile e noi si continua come negli anni '60 col nostro bravo GVIM e Make

Originariamente inviato da GTKM

Per il resto, già sai che ci sono un sacco di cose vecchie e ancora bacate, ne abbiamo discusso estensivamente ahah
XML a colpi di sprintf () ha un non so che di romantico...

Romantico sì... basta che quando inizia ad andare in core ogni 2 per 3 non debba essere io a debuggare quello schifo
La scusa? Eh ma VxWorks mica la supporta la libxml2 dai... pensa che io in una settimana ho portato:

1. json-c
2. libreria "wrapper" scritta da noi che rende safe json-c
3. libxml2 (!)
4. libreria "wrapper" scritta da noi che rende safe libxml2
5. Posix thread (simulati come task VxWorks non erano totalmente "compliant" visto che non avevano memory leak quando venivano terminati brutalmente)
6. Libreria nostra che doveva interfaccia via XML con un POS

funzionava come un cavallo certo un po' lento sempre di un Motorola 68000 si parla eh... poi quando l'hanno vista funzionare mi hanno detto che ci hanno ripensato

Originariamente inviato da GTKM

Al momento sono impelagato in una libreria multithreaded in C. Mutex come se non ci fosse un domani.

Multithread in C? E cos'hai fatto di male per meritartelo? Poveretto...

Alla fine sbattendo mutex a destra e a sinistra si ottiene la cosa ridicola che solo un thread può girare e tutti gli altri sono bloccati sul mutex proprio utile vero?
Occhio che i mutex vanno anche rilasciati ed è facile scordarselo nei casi di errore... e pthread_exit() a differenza di exit() ha un piccolo "baco": non rilascia la memoria / risorse usate dal thread!

[GTKM]

Originariamente inviato da fano

Mah purtroppo sono scelte aziendali... mai usato Emacs, ma conoscendomi mi farebbe schifo pure quello! Io voglio poter usare un IDE... mi accontento pure di Eclipse (no QtCreator mi ha fatto rimpiangere GVIM), ma non si può nel 2017 inoltrato continuare ad usare GVIM + Make da linea di comando dai!

Pensa alla cosa assurda che il cliente (che è il proprietario dei sorgenti) ci ha espressamente richiesto che lavorassimo con Eclipse visto che - purtroppo - vogliono metterci le mani anche loro nel codice ( ) e la gente normale di fare Make sul terminale non vuole nemmeno sentirne parlare... beh abbiamo trovato un "trusco" che permette ad Eclipse di pupparsi i Makefile e noi si continua come negli anni '60 col nostro bravo GVIM e Make

Emacs con i giusti "plug-in" diventa "produttivo" (per gli amanti ).
Io mi trovo bene con QtCreator ma malissimo con Eclipse per il C. Un disastro proprio, non "trova" nemmeno la libreria standard nonostante abbia controllato tutti i Path.

Originariamente inviato da fano

Romantico sì... basta che quando inizia ad andare in core ogni 2 per 3 non debba essere io a debuggare quello schifo
La scusa? Eh ma VxWorks mica la supporta la libxml2 dai... pensa che io in una settimana ho portato:

1. json-c
2. libreria "wrapper" scritta da noi che rende safe json-c
3. libxml2 (!)
4. libreria "wrapper" scritta da noi che rende safe libxml2
5. Posix thread (simulati come task VxWorks non erano totalmente "compliant" visto che non avevano memory leak quando venivano terminati brutalmente)
6. Libreria nostra che doveva interfaccia via XML con un POS

funzionava come un cavallo certo un po' lento sempre di un Motorola 68000 si parla eh... poi quando l'hanno vista funzionare mi hanno detto che ci hanno ripensato

Almeno ti sei allenato

Originariamente inviato da fano

Multithread in C? E cos'hai fatto di male per meritartelo? Poveretto...

Alla fine sbattendo mutex a destra e a sinistra si ottiene la cosa ridicola che solo un thread può girare e tutti gli altri sono bloccati sul mutex proprio utile vero?
Occhio che i mutex vanno anche rilasciati ed è facile scordarselo nei casi di errore... e pthread_exit() a differenza di exit() ha un piccolo "baco": non rilascia la memoria / risorse usate dal thread!

Eh, è una libreria attualmente attivamente usata per la ricerca. Devo terminare alcune cose e scrivere un articolo col mio prof per proporlo per una conferenza internazionale.
Con le pthread devo ammettere che mi sto trovando malissimo, ma forse sono io, buh.
Il problema grosso è che sono partito da un programma già scritto malissimo, singlethreaded. Quindi immagina. Ho dovuto deallocare tutte le risorse che i geniacci facevano allocare, e tutto il resto.

Io mi trovo bene con C e riga di comando, anche se il progetto è grosso. Quello che non digerisco sono le cose scritte a cazzo di cane.

Appena finisco mi studio CosmOS e .NET in maniera approfondita.

Sent from my HUAWEI VNS-L31 using Tapatalk

[fano]

Originariamente inviato da cdimauro

Mi spiace ma, causa scarsissimo tempo rimasto, ho sostanzialmente abbandonato il forum. Ogni tanto mi arrivano le notifiche ai thread a cui sono sottoscritto, e quando posso guardo i nuovi messaggi, ma finisce lì.

Anch'io in questo periodo sono molto preso con il lavoro! Spero un giorno tu abbia di nuovo tempo per il forum.

Posso aggiungere un nuovo capitolo solo per te:

The incredible stench of GPL

Un ragazzetto proprio uno o 2 giorni dopo che ho postato il qui se ne esce di aver trovato della "bratta" GPL dentro i sorgenti di Cosmos e che eravamo in qualche sorta di "violazione"!
Pretende pure che noi si aggiunga la frasetta del GPL al nostro progetto:

https://github.com/CosmosOS/Cosmos/pull/679/files

per fortuna usiamo solo degli exe e quindi il ragazzetto viene mandato a spigolare (giustamente), il "padrone" di Cosmos dice che GPL "puzza" e se ne esce con questo readme... direi appropriato no?

https://github.com/CosmosOS/Cosmos/b...L%20Readme.txt

Originariamente inviato da cdimauro

In bocca al lupo per il progetto.

In bocca al lupo anche a te!

[fano]

Originariamente inviato da GTKM

Eh, è una libreria attualmente attivamente usata per la ricerca. Devo terminare alcune cose e scrivere un articolo col mio prof per proporlo per una conferenza internazionale.
Con le pthread devo ammettere che mi sto trovando malissimo, ma forse sono io, buh.

No, non è un problema tuo come molto cose in Linux sono fatte con la filosofia "Worse is better": https://en.wikipedia.org/wiki/Worse_is_better

Originariamente inviato da GTKM

Il problema grosso è che sono partito da un programma già scritto malissimo, singlethreaded. Quindi immagina. Ho dovuto deallocare tutte le risorse che i geniacci facevano allocare, e tutto il resto.

Io mi trovo bene con C e riga di comando, anche se il progetto è grosso. Quello che non digerisco sono le cose scritte a cazzo di cane.

Il problema è che scrivere codice non "a cazzo di cane" in C è davvero difficile è il linguaggio che quasi ti obbliga a farlo mancando completamente di struttura (eh gli oggetti che se ne dica aiutano a "pensare" le cose in maniera diversa), il fatto che manchino tipi fondamentale (tipo le stringhe, le liste, i dizionari) e quindi ognuno se le re-implementa tutte le volte, la stessa gestione degli errore "sporca" il codice, ma d'altro canto se non la fai poi rischi che vada tutto in core appena ti giri dall'altra parte

Io ci provo scrivo il codice migliore che il C si sia mai meritato, poi lo do in mano ai miei colleghi torno tra un anno (il mio ruolo è un po' di "apri pista" diciamo creo cose nuove, ma solitamente poi non mi occupo della manutenzione) e non capisco più il mio codice... certo è devastato

Originariamente inviato da GTKM

Appena finisco mi studio CosmOS e .NET in maniera approfondita.

Sent from my HUAWEI VNS-L31 using Tapatalk

Ottimo! Se hai bisogno di "pointers" sono qui a disposizione