SOFTWARE > Altri & "Nerd OS"
Muen Separation Kernel
dsar:
.
cdimauro:
Ma non sempre è possibile prevederli. Per questo motivo ho lavorato a una nuova tecnologia per accelerare in hardware il controllo dei bound; a breve sottoporrò il draft al comitato per i brevetti, e poi vediamo cosa mi diranno.
Comunque ADA è troppo complesso come linguaggio. La sintassi, da pascaliano, mi piace molto, ma se il linguaggio diventa troppo grande la facilità di scrittura del codice tipica di Pascal & co. va a farsi benedire, e non mi piace affatto.
TheKaneB:
Vorrei ricordare che questo kernel fa "Muuuuueen". Coincidenze? Io non credo :D
cdimauro:
--- Citazione da: dsar - 02 Dicembre 2014, 11:06:47 ---
--- Citazione da: cdimauro - 01 Dicembre 2014, 17:25:12 ---Ma non sempre è possibile prevederli.
--- Termina citazione ---
Dipende, con il range type (bounded) esempi classici che delegano il range checking in runtime possono essere controllati in compile time, per esempio: buffer[f()]; il ritorno di f() deve essere lo stesso range type che utilizza l'array del tipo buffer. Andando sul generale non puoi iterare quel buffer con un indice che non è dichiarato dello stesso range type. Se l'array viene dichiarato con un tipo range bounded, il type checking implica il range checking.
--- Termina citazione ---
Chiaro.
--- Citazione ---Il range checking avviene per gli unbounded range, in cui il tipo range è conosciuto solo durante il runtime (ma nel mission critical non si usano mai). Il range checking di Ada in compile time si comporta molto bene in questi casi, soprattutto quando l'array non è guarded nei cicli (for i in buffer'Range), in particolare nei cicli generici non ti permette di accedere ad un array se l'index non è controllato nella condizione.
Onestamente non ho trovato casi in cui un unbounded range non venisse catchato in compile time, sicuramente saranno casi eccessivamente complicati.. ma qui ci vuole un po' di software engineering e buon senso, casi così delicati vanno trattati con estrema semplicità per essere il più possibile padroneggiati. In ogni caso c'è il bounds checking in runtime, che protegge i casi in cui il guard sull'array non può essere garantito.
--- Termina citazione ---
E' troppo pesante. Per questo motivo sono state sviluppate soluzioni, anche hardware, per evitarlo. Ad esempio Intel ha tirato fuori di recente la tecnologia MPX allo scopo (un altro utile link che ne parla è questo), che sarà disponibile nei prossimi processori. Ma c'è parecchio fermento, e si trovano diverse altre soluzioni o ricerche in merito. Qui trovi altra roba.
Le motivazioni sono molto semplici: si tratta di problematiche molto comuni e frequenti, e per le quali c'è forte richiesta (ma non posso dire altro, mi spiace) di tecnologie per la loro accelerazione in hardware.
--- Citazione ---Il vero problema comunque sono gli array dinamici, che oltre ad essere pericolosi per la sicurezza (buffer overflow, il resize non è altro che un free()/malloc() quindi tutti i reference diventano dangling pointer, etc) offre delle pessime performance se fai tantissime operazioni di modifica.
--- Termina citazione ---
Esistono delle politiche per ridurre l'impatto di queste operazioni. O... altro, ma anche di questo non posso parlarne per adesso.
--- Citazione ---Morale della favola, evitare gli array dinamici ed utilizzare solo ed esclusivamente strutture dati. Questo è uno dei motivi per cui Wirth non implementò mai gli array dinamici nei suoi linguaggi.
--- Termina citazione ---
Non sono d'accordo perché sono strumenti molto utili.
Tra l'altro con tecnologia adeguata si possono gestire in scioltezza e riducendo al minimo problematiche di robustezza e sicurezza.
Questo è anche il motivo per cui ho speso un po' di mesi per sviluppare una mia idea che mi trascinavo da anni: dimostrare che si può ottenere bound checking in hardware a un costo minimo sia a livello implementativo sia, soprattutto, a runtime. Fortunatamente dove lavoro adesso ho avuto la possibilità di svilupparla e perfezionarla ulteriormente, ma soprattutto c'è la concreta possibilità di vederla implementata su silicio (SE l'idea piacerà, e passerà poi tutta la trafila burocratica, che purtroppo è lunghetta).
--- Citazione da: legacy - 02 Dicembre 2014, 11:11:33 ---
--- Citazione da: cdimauro - 01 Dicembre 2014, 17:25:12 ---Ma non sempre è possibile prevederli. Per questo motivo ho lavorato a una nuova tecnologia per accelerare in hardware il controllo dei bound;
--- Termina citazione ---
mi sa che non sei il primo ad averci pensato, anche se in quel caso non ne e' valsa la candela: idee varie in OpenRISC!
--- Termina citazione ---
Non conosco OpenRISC e come abbiano affrontato il problema, ma certamente non sono affatto l'unico ad averci pensato. C'è parecchia letteratura in merito, progetti, e... richieste di avere soluzioni efficienti (e che non penalizzino troppo le prestazioni). Se Intel ha sviluppato MPX, non l'ha fatto certo per caso. ;)
--- Citazione ---esattamente cosa presenti ?
--- Termina citazione ---
Mi spiace, ma a questo stadio non posso rilasciare alcuna informazione in merito. L'unica cosa che posso dirti è che si tratta di un'intera tecnologia che aiuta a risolvere o limitare fortemente le problematiche di bound-checking, protezione dei buffer (anche di sottoinsiemi/slice di buffer esistenti), e dangling-pointer.
E' una soluzione hardware che ha un impatto trascurabile a runtime, al contrario di altre tecnologie.
--- Citazione ---hai un nodello HDL ?
--- Termina citazione ---
No, nessun modello HDL: lo sai che le mie conoscenze in merito sono nulle. :'(
Al momento ho scritto un lunghissimo draft che espone tutti i dettagli, dall'implementazione all'interno di un processore fino all'applicazione che esegue il codice, con l'analisi di diversi casi d'uso e comparazione con tecnologie esistenti e concorrenti (MPX è una di esse, ma ce ne sono altre, anche in forma di sola idea interna). Ma devo ridurre notevolmente questo draft, perché per sottometterlo alla commissione brevetti il testo deve occupare al massimo un paio di paginette, e scritte in maniera quanto più chiara e intelligibile possibile.
Se dovesse andare bene, io mi fermerò qui. Al massimo sarei chiamato come consulente per la scrittura del brevetto (che viene realizzata da gente che lavora in questo campo, inclusi legali ovviamente), e forse per discutere qualcosa riguardo all'implementazione su silicio (ma ne dubito, perché quegli ingegneri non ne avranno sicuramente bisogno).
--- Citazione da: legacy - 02 Dicembre 2014, 12:21:54 ---
--- Citazione da: dsar - 02 Dicembre 2014, 12:07:05 ---Non so se ti rendi conto dell'idea totalmente insana, ci metteresti due/tre mesi per finire di compilarlo
--- Termina citazione ---
per questa porcata lavoro sotto QEMU/MIPS su un muletto di ordine almeno i2
fossi matto ad usare un SoC a 800Mhz che performa meno di un P3
pero' anche cosi' il cross compilare e' un bel macello, e metterlo a posto anche peggio
in compenso per PowerPC si trovano bootstrap (l'ho fatto, funge)
e anche per ARM c'e' qualcosa (non l'ho provato di persona)
--- Termina citazione ---
Alla fine emuli i MIPS con gli x86, eh! ;D Ma lasciali perdere e dedicati direttamente a questi ultimi. 8)
cdimauro:
--- Citazione da: legacy - 02 Dicembre 2014, 23:25:55 ---
--- Citazione da: cdimauro - 02 Dicembre 2014, 22:12:04 ---Alla fine emuli i MIPS con gli x86, eh! ;D Ma lasciali perdere e dedicati direttamente a questi ultimi. 8)
--- Termina citazione ---
per forza, non ho abbastanza quattrini per comprare hw + carrozzato, volendo dalla Cina ci sarebbe pure qualcosa di + potente della + potente CPU mips che ho in casa, un R16K a 800Mhz, che non accendo quasi masi, si succhia 600Watt e' un 4 CPU.
mi costa di meno usare un muletto intel per QEMU/MIPS-catalyst (che crede di fare compilazione nativa)
Vedremo con Edison, per ora non c'e' alcun rimpiazzo, da parte mia, per i SoC MIPS
in compenso ho definitivamente abbandonato PowerPC: Cerbero, di cui vedi le foto nell'altro thread e' l'ultimo progetto, poi metto la parola fine.
E pure sulle HP.
--- Termina citazione ---
Uno in meno. Quando smetterai con MIPS stapperemo una bottiglia di spumante. ;D
Navigazione
[0] Indice dei post
Vai alla versione completa