SSE3 anche nei processori Transmeta

[Redazione di Hardware Upg]

Link alla notizia: http://news.hwupgrade.it/13295.html

Transmeta implementerà il supporto SSE3 in una nuova versione di Efficeon TM8800 che uscirà entro la fine dell'anno

Click sul link per visualizzare la notizia.

[luckye]

Ma ma pensavo che ma ma fossero usati quasi esclusivamente in dispositivi supercompatti come Pda e cellulari !! Per che socket sono ? Quanto costano ? Dove si trovano ?? Bellissimi !!!

[Crisa...]

il bello di questi processori transmeta e che sicuramente non hanno fatto nessuna modifica hardware per usare le sse3, essendoci uno strato software sopra l'hardware che fa i calcoli bruti....

[DjLode]

Io direi piuttosto che è la cosa brutta
Hanno prestazioni indecenti (o meglio decenti solo per uso d'ufficio o per tablet). I consumi però sono irrisori e quindi vanno benissimo per sistemi altamente integrati dove le prestazioni non sono il primo target. Ad esempio a me piacerebbe veramente un sacco una cpu del genere o un Via Epia per utilizzarlo come server da lasciare acceso 24 ore su 24. Consumi bassi, poco calore, poca spesa.

[Motosauro]

O sono solo per soluzioni tipo Embedded?
Confesso la mia ignoranza

[Kanon]

l'implementazione dei crusoe è troppo costosa, anche sui portatili (I centrino ULV costano meno e sono molto più performanti). è vero che raggiungono le 5 (cinque) ore di autonomia, ma sono un mercato di stranicchia. oltretutto credo che transmeta non abbia sufficienti partner per cominciare la produzione destinata a OEM (mobo+cpu, un po' quello che tutti aspettano, qui la concorrenze del Via epia è troppo forte)

[Motosauro]

Devo ricordarmi di premere "refresh" prima di postare un commento

[lucusta]

effettivamente li ho visti solo su sub-note e sui sistemi ultraportatili..
comunque sono degli ottimi processori, se si conta il fatto che consumano davvero pochissimo..
un'altra delle particolarita' HW interessante del TM8800 e il suo clock variabile a seconda del'occupazione della cpu, simile allo speedstep di intel od al powernow! di AMD (ora diventato cool'n quiet), solo che nel transmeta il cambio del clock varia a cicli di 100 volte al secondo, con un'efficenza tale che non e' nemmeno pensabile dagli altri processori...
il risultato e' che il transmeta, a riposo, consuma qualche decimo di watt!
il fatto che sia un processore con core logico misto (HW/software) non dovrebbe incidere piu' di tanto rispetto ad un processore X86 odierno, questo perche' un processore odierno traduce comunque le ISA in LISA (Long Instruction Set Architecture), il quale perde drasticamente se viene confrontato ad un chip con algoritmo dedicato ad uno specifico compito (un decodificatore, ad esempio), anche se mette in grado di svolgere un piu' ampio spettro di applicazioni.
il vantaggio e' appunto avere un software integrato nel processore che ricompila il codice (in questo caso a 256bit);
il problema e' la parte puramente HW: se e' poco snella (e registri a 256bit non sono tanto pratici), ed inefficente (pipeline mostruosamente lunghe), non si puo' dar colpa al concetto di core software di essere inefficente..
Un'altro vantaggio si otterra con i multi core (che trasmeta aveva gia' annunciato), in quanto il core software farebbe apparire questi core logici come un mono processore; e non e' un vantaggio da poco..
oltretutto e' un software, e puo' essere pian piano aggiornato e migliorato (come ora) senza dovre rifare il disegno del chip..
oppure potrebbe emulare un PPC o qualsiasi altro tipo di codice (in modo drasticamente lento, daccordo, ma puo' farlo); infatti credo che transmeta sia gia' con X86-64bit.
in pratica questo processore e' stato proggettato per essere un efficentissima cpu X86 in rapporto al consumo espresso, cosa che non si puo' affatto dire di tante altre cpu, come il C3 VIA, che consuma poco, ma che ad efficenza tra' istruzioni svolte e consumo, fa' proprio pena..
Per me questi trasmeta sono delle bellissime CPU (hanno soprattutto il vantaggio d'integrare gran parte dei pezzi per costruire un computer); peccato per le potenze espresse, che non ci sono..
Un domani le CPU saranno concettualmente tutte piu' o meno cosi'...
Comunque sarei curioso nel sapere quali prestazioni avrebbe con codice nativo..

[lucusta]

comunque c'e' chi produce sistemi (SBC) con cpu transmeta:
http://www.boser.com.tw/products/sbc/hs2602.htm

[cdimauro]

Originariamente inviato da lucusta
il fatto che sia un processore con core logico misto (HW/software) non dovrebbe incidere piu' di tanto rispetto ad un processore X86 odierno, questo perche' un processore odierno traduce comunque le ISA in LISA (Long Instruction Set Architecture), il quale perde drasticamente se viene confrontato ad un chip con algoritmo dedicato ad uno specifico compito (un decodificatore, ad esempio), anche se mette in grado di svolgere un piu' ampio spettro di applicazioni.

Le differenze però sono sostanziali: i processori attuali eseguono la fase di decodifica e arrangiamento delle istruzioni mascherandoli nei primi stadi di pipeline, e quindi permettono di raggiungere prestazioni molto elevate, mentre per questi processori c'è sempre una fase di compilazione JIT, che porta via tempo, oltre a quella di profiling e "aggiustamento" del codice generato, che avviene nelle successive esecuzioni del medesimo.

il vantaggio e' appunto avere un software integrato nel processore che ricompila il codice (in questo caso a 256bit);

I 256 bit si riferiscono esclusivamente all'opcode VLIW generato.

il problema e' la parte puramente HW: se e' poco snella (e registri a 256bit non sono tanto pratici),

Vedi sopra: i registri non sono a 256. Dovrebbero essere a 32 bit, se la memoria non m'inganna.

ed inefficente (pipeline mostruosamente lunghe), non si puo' dar colpa al concetto di core software di essere inefficente..

Beh, qui il problema delle prestazioni è legato a due cose: il fatto che il processore sia un VLIW (con un bundle molto "lungo") e il motivo per cui viene impiegato.
Il primo caso comporta una notevole inefficienza per quanto riguarda lo spazio occupato e ciò che accade quando non è possibile sfruttare tutto il bundle per eseguire quanto più codice (viene "buttato a mare" dello spazio, ma soprattutto delle istruzioni da eseguire).
Per il secondo caso c'è da dire che eseguire codice x86 "tradotto" non è certamente il massimo: già di codice per sua natura è abbastanza "frastagliato" e difficile da parallelizzare, e in questo modo lo diventa ancora di più. Quindi sarà più difficile trarre vantaggio dalle 8 istruzioni eseguibili in un colpo solo.

Comunque, l'adozione di qualunque set di istruzioni SIMD, come le SSE3 in questo, si rivela invece estremamente vantaggioso, proprio perché è nell'esecuzione di questo tipo di codice che questi processori riescono a rendere al meglio, in quanto decisamente parallelizzabile e "lineare".
A ciò aggiungiamo pure che si tende sempre di più a ottimizzare il codice con le SIMD (in particolare il codice critico), per cui globalmente le prestazioni di questi processori dovrebbero essere discrete, a fronte di consumi veramente ridotti...

Un'altro vantaggio si otterra con i multi core (che trasmeta aveva gia' annunciato), in quanto il core software farebbe apparire questi core logici come un mono processore; e non e' un vantaggio da poco..

Non penso che andrà così: mi sembra estremamente difficile da realizzare.

oltretutto e' un software, e puo' essere pian piano aggiornato e migliorato (come ora) senza dovre rifare il disegno del chip..

Indubbiamente, ma rimangono le considerazioni di cui sopra, che sono legate all'hardware e non al software...

oppure potrebbe emulare un PPC o qualsiasi altro tipo di codice (in modo drasticamente lento, daccordo, ma puo' farlo); infatti credo che transmeta sia gia' con X86-64bit.

Già da tempo Transmeta supporta questo set di istruzioni: da prima che Opteron fosse commercializzato, in quanto fu fatto un accordo con AMD, a cui interessava particolarmente, ai tempi, poter debuggare la sua architettura x86-64, valutare le prestazioni e aiutare i programmatori nello sviluppo di software per questa nuova architettura.

Comunque sarei curioso nel sapere quali prestazioni avrebbe con codice nativo..

Molto più elevate, ovviamente. Ma il problema è che non interessa a nessuno una nuova architettura che si pone in un mercato già abbastanza inflazionato, e soprattutto dominato da x86.

La cosa interessante che, invece, non ho ancora visto, è usare questi processori per emulare processori diversi a seconda delle esigenze. Es.: m'interessa lavorare con Mac OS X, allora faccio emulare un PowerPC a questo processore e fatto il boot dalla partizione Mac. Poi m'interessa Windows o Linux, allora resetto e faccio emulare un x86. Ecc. ecc. Il tutto a discreta velocità.

[xeal]

La cosa interessante che, invece, non ho ancora visto, è usare questi processori per emulare processori diversi a seconda delle esigenze. Es.: m'interessa lavorare con Mac OS X, allora faccio emulare un PowerPC a questo processore e fatto il boot dalla partizione Mac. Poi m'interessa Windows o Linux, allora resetto e faccio emulare un x86. Ecc. ecc. Il tutto a discreta velocità.

E' un'idea davvero interessante, ne deriverebbe una flessibilità notevole che potrebbe diventare il punto di forza di questi processori, oltre ai bassi consumi. L'interesse accresciuto per queste soluzioni potrebbe portare nuove risorse (economiche) e un più rapido miglioramento degli emulatori.

In questo caso specifico, come vedresti una soluzione simile a quella di Itanium per migliorare la velocità dell'emulazione dei 32 bit? Si potrebbe cercare di ottimizzare in background il codice prodotto dal jit per le applicazioni più "critiche"/più usate da un utente e per i kernel degli os, per poi salvarlo su hd, anche se comporterebbe un utilizzo maggiore di memoria; le prestazioni aumenterebbero, no? E se per risparmiare spazio su disco si applicasse una qualche compressione (anche opzionale), con un algoritmo "sbilanciato" a favore della velocità di decompressione (nella sola ram)? Non potrebbe essere un buon compromesso, i tempi necessari alla compilazione jit e al profiling successivo non potrebbero ridursi anche notevolmente? Mi sorge però il dubbio che dopo la decompressione potrebbe essere necessaria un'analisi del codice per la corretta allocazione effettiva del programma... anche se forse si potrebbe integrare nell'algoritmo di decompressione, analizzando le istruzioni appena decompresse e cercare di predisporre la memoria in maniera opportuna per accogliere il programma; oppure in fase di compressione si potrebbero conservare informazioni relative alle pagine da creare e alla natura, per agevolare l'analisi jit... Qualitativamente, come pensi che inciderebbe sulle prestazioni, rispetto alla compilazione on the fly? Ovviamente, partendo direttamente dal codice rilocabile non compresso sarebbe tutto più velocce...

[cdimauro]

Originariamente inviato da xeal
E' un'idea davvero interessante, ne deriverebbe una flessibilità notevole che potrebbe diventare il punto di forza di questi processori, oltre ai bassi consumi. L'interesse accresciuto per queste soluzioni potrebbe portare nuove risorse (economiche) e un più rapido miglioramento degli emulatori.

Indubbiamente. Oltre al fatto di avere una piattaforma hardware universale, e non è una cosa di poco conto...

In questo caso specifico, come vedresti una soluzione simile a quella di Itanium per migliorare la velocità dell'emulazione dei 32 bit? Si potrebbe cercare di ottimizzare in background il codice prodotto dal jit per le applicazioni più "critiche"/più usate da un utente e per i kernel degli os, per poi salvarlo su hd, anche se comporterebbe un utilizzo maggiore di memoria; le prestazioni aumenterebbero, no?

Di fatto CodeMorph (il software di traslazione e ottimizzazione) funziona già così, fatta eccezione per il salvataggio su HD. Quest'ultimo lo vedo più difficile da fare, perché si dovrebbe introdurre a questo livello la conoscenza del sistema emulato (non solo il processore) per capire in che modo salvare le informazioni e caricarle: decisamente troppo dispendioso da realizzare...

E se per risparmiare spazio su disco si applicasse una qualche compressione (anche opzionale), con un algoritmo "sbilanciato" a favore della velocità di decompressione (nella sola ram)? Non potrebbe essere un buon compromesso, i tempi necessari alla compilazione jit e al profiling successivo non potrebbero ridursi anche notevolmente?

A parte i problemi di cui sopra, potrebbero ridursi, ma bisogna vedere anche quanto: con l'accesso al disco i tempi di caricamento aumentano molto, e paradossalmente sarebbe preferibile tradurre al volo il codice ed effettuare qualche passo di profiling, perché in questi casi tutto avviene utilizzando la ram.

Inoltre devi considerare che vengono compilati piccoli blocchi di codice, per poi essere subito eseguiti (generalmente), per cui nella maggior parte dei casi il codice tradotto verrà poi eliminato tramite qualche politica di allocazione dei blocchi di memoria (LRU generalmente). I blocchi più importanti sono chiaramente quelli eseguiti dentro a dei loop, per cui già dopo la traduzione e la prima esecuzione, accorgendosi che verranno eseguiti ancora un'altra volta, si passa al primo profiling del codice.

Tutto, insomma, avviene molto velocemente, e considerate le piccole dimensioni, le politiche perseguibili credo che rimangono sostanzialmente due: o continuare così , oppure cercare di compilare tutto il codice, man mano, e caricarlo tutto in una volta al lancio, come se si trattasse di un'applicazione nativa (salvo poi compilare e conservare nel "nuovo eseguibile" i nuovi pezzi che s'incontrano).

Mi sorge però il dubbio che dopo la decompressione potrebbe essere necessaria un'analisi del codice per la corretta allocazione effettiva del programma... anche se forse si potrebbe integrare nell'algoritmo di decompressione, analizzando le istruzioni appena decompresse e cercare di predisporre la memoria in maniera opportuna per accogliere il programma; oppure in fase di compressione si potrebbero conservare informazioni relative alle pagine da creare e alla natura, per agevolare l'analisi jit...

Generalmente, quando si parla di compilazione JIT, si utilizza sempre qualche tecnica per il reperimento dei blocchi compilati (generalmente le tabelle hash), a cui sono associate delle informazioni addizionali.
Il fatto di conservarle su disco, è una conseguenza logica a ciò che chiedi (conservare il codice tradotto), per cui è chiaro che si dovrebbe pensare a una soluzione di recupero delle informazioni anche in questo caso, e non credo che differisca molto da quanto già utilizzato...

Qualitativamente, come pensi che inciderebbe sulle prestazioni, rispetto alla compilazione on the fly? Ovviamente, partendo direttamente dal codice rilocabile non compresso sarebbe tutto più velocce...

Esatto. Per il resto, le risposte a quanto chiedi dovresti trovarle più sopra, spero.

[xeal]

Originariamente inviato da cdimauro
Quest'ultimo lo vedo più difficile da fare, perché si dovrebbe introdurre a questo livello la conoscenza del sistema emulato (non solo il processore) per capire in che modo salvare le informazioni e caricarle: decisamente troppo dispendioso da realizzare...

Uhm, si, effettivamente servirebbe un layer software aggiuntivo, magari uno straccio di os nativo in una partizione apposita. Però questo strato in più potrebbe consentire l'emulazione contemporanea di più sistemi, con un meccanismo del tipo VM e time slacing eventuale tra le istanze di ciascun os (magari in un "serverino" multiprocessore, multiutente e multi-os forse però sogno o deliro ), anche se potrebbe richiedere davvero molte risorse, implicare molti (continui) swap su disco e risultare lento...

A parte i problemi di cui sopra, potrebbero ridursi, ma bisogna vedere anche quanto: con l'accesso al disco i tempi di caricamento aumentano molto, e paradossalmente sarebbe preferibile tradurre al volo il codice ed effettuare qualche passo di profiling, perché in questi casi tutto avviene utilizzando la ram.

Non ho capito bene cosa intendi in questo punto. Ti riferisci alla scrittura su disco del file decompresso per poi allocarlo? Io pensavo di lasciarlo subito in memoria, eventualmente riorganizzando le "parti" (deframmentando) per evitare che, per motivi contingenti, istruzioni e dati contigui (tipo le celle di un array) si ritrovino spezzati. I file jar non funzionano in modo simile? Oppure vengono decompressi in una cartella temporanea prima dell'esecuzione? Mi pare che la decompressione non incida molto sulla compilazione jit per gli archivi java, e nel meccanismo che pensavo il tempo dedicato alla compilazione verrebbe meno; però non conosco i dettagli, quindi potrei sbagliarmi...

A parte questo il resto mi è chiaro

[cdimauro]

Originariamente inviato da xeal
Uhm, si, effettivamente servirebbe un layer software aggiuntivo, magari uno straccio di os nativo in una partizione apposita. Però questo strato in più potrebbe consentire l'emulazione contemporanea di più sistemi, con un meccanismo del tipo VM e time slacing eventuale tra le istanze di ciascun os (magari in un "serverino" multiprocessore, multiutente e multi-os forse però sogno o deliro ), anche se potrebbe richiedere davvero molte risorse, implicare molti (continui) swap su disco e risultare lento...

E' chiaramente possibile, ma come hai già detto servirebbe uno sforzo non indifferente per realizzare il tutto, oltre a un bel po' di risorse per farlo funzionare discretamente.

Certo, una cosa ancora più bella sarebbe quella di avere un solo s.o. "universale" che attivi un tipo di emulazione piuttosto che un altra a seconda dell'applicazione da eseguire, e si occupi di gestire tutto il resto (l'emulazione del s.o. target), per cui la avendo in mano le risorse e la loro gestione funzionerebbe tutto benissimo. Tanto per chiarire: si occuperebbe della gestione della memoria a seconda delle richieste di ogni applicazione, anziché allocare un buffer di memoria fisso per ogni ambiente emulato.

Non ho capito bene cosa intendi in questo punto. Ti riferisci alla scrittura su disco del file decompresso per poi allocarlo? Io pensavo di lasciarlo subito in memoria, eventualmente riorganizzando le "parti" (deframmentando) per evitare che, per motivi contingenti, istruzioni e dati contigui (tipo le celle di un array) si ritrovino spezzati. I file jar non funzionano in modo simile? Oppure vengono decompressi in una cartella temporanea prima dell'esecuzione? Mi pare che la decompressione non incida molto sulla compilazione jit per gli archivi java, e nel meccanismo che pensavo il tempo dedicato alla compilazione verrebbe meno; però non conosco i dettagli, quindi potrei sbagliarmi...

A parte questo il resto mi è chiaro

In effetti dovevo esplicitare meglio il mio pensiero:
I tipi di utilizzo della tecnologia JIT sono sostanzialmente tre:
1) Interamente software; tutto compilato in real-time, senza archiviare informazioni su disco.
2) Parzialmente software / archiviato su disco; soltanto alcune parti vengono conservati sul disco, presumibilmente quelle più importanti (es. il codice dei cicli), e il resto viene compilato "al volo".
3) Interamente archiviato su disco; le prime esecuzioni servono a tirare fuori l'eseguibile in formato nativo, e soltanto quando si incontra del codice mai eseguito in precedenza si riattiva la compilazione al volo, "riaggiustando" l'eseguibile per tenere in considerazione queste modifiche.

Detto ciò, volevo dire che io parteggio per la 1) o per la 3), perché a mio avviso un sistema "ibrido" come il 2) tende comunque ad annullare i vantaggi della compilazione parziale, a causa degli accessi al disco, che sono troppo lenti.
La 1) ha il vantaggio di essere la più semplice da implementare, e dà anche dei buoni risultati, oltre a consumare meno risorse (si può decidere quanta memoria riservare ai buffer JIT, e inoltre non viene sprecato né frammentato lo spazio su disco).
La 3) ha il vantaggio di garantire le migliori prestazioni in assoluto, ma di richiedere un notevole spazio su disco, e di frammentarlo.

Spero che sia più chiaro adesso.

[xeal]

Originariamente inviato da cdimauro
Certo, una cosa ancora più bella sarebbe quella di avere un solo s.o. "universale" che attivi un tipo di emulazione piuttosto che un altra a seconda dell'applicazione da eseguire[...]anziché allocare un buffer di memoria fisso per ogni ambiente emulato.

Questo forse sarebbe più semplice (per certi versi) e meno "costoso" (in termini di risorse) da realizzare, anche se richiederebbe un notevole sforzo (nel progettare il tutto) per coordinare le varie emulazioni ed evitare eventuali conflitti (non so, tra programmi, o servizi, che richiedono livelli di priorità superiori a quelli previsti, e magari entrano in conflitto perchè cercano di fare la stessa cosa contemporaneamente "pretendendo" di farla in maniera esclusiva, anche se con un po' di accortezza si potrebbe evitare). Si potrebbero fornire all'applicazione tutte le librerie dell'os di origine, con interfaccia immutata e implementate in modo da richiamare le funzioni "vere" dell'os nativo, prevedendo un meccanismo simile per i servizi "erogati" da applicativi dell'os (ad esempio richiamati in una pipe).
Però, questo sistema implicherebbe un problema di supporto non da poco, anzi due. Il primo relativo ai driver, che, se non reperibili come nativi ed emulati per ogni sistema potrebbero creare davvero dei conflitti, oltre che richiedere uno spreco di memoria (RAM in particolare), anche se si potrebbe ovviare con un driver fittizio associato agli originali che richiama all'occorrenza questo o quel driver trattandoli come overlay mutuamente esclusivi, ma questo inciderebbe negativamente sulle prestazioni, sia per l'emulazione, sia per lo swapping anche continuo. Il secondo, credo irresolubile, relativo alle specifiche degli os da emulare, pena la non "rimappabilità" delle funzioni di libreria e delle syscall...

Per il resto, si, il meccanismo che hai descritto mi l'ho capito. Però mi sono spiegato male io... :

Nella mia ipotesi mi riferivo alla 3), aggiungendo qualche accorgimento per cercare di ridurre lo spazio richiesto du disco, e mi chiedevo quanto questi "accorgimenti" potessero incidere sulla velocità, rendendo preferibile la 3) senza compromessi:
a) per ridurre spazio, pensavo di archiviare su disco (compilate per intero) le applicazioni usate più spesso, insieme al kernel, ai driver e ai moduli dell'os, diciamo, "secondari" richiamati più frequentemente, in modo da personalizzare tutto in base alle esigenze dell'utente e all'uso che fa del sistema (dandogli la possibilità di compilare e archiviare tutto o niente);

b) per occupare ancora meno spazio, sempre in maniera opzionale, mi chiedevo se non si potesse comprimere il codice compilato, in modo da decomprimerlo direttamente nella RAM durante l'allocazione, eventualmente ricompattando le parti decompresse per evitare frammentazione di istruzioni e dati contigui (sempre in ram), oppure memorizzando (su disco) informazioni su come allocare correttamente i blocchi da decomprimere e/o analizzando le varie parti, eventualmente eseguite subito dopo la decompressione e prima che si decomprimano le successive (una sorta di decompressione jit che sostituisca la compilazione al volo, sperando che si abbia comunque un vantaggio, altrimenti sarebbe inutile).

Insomma, pensavo ad un compromesso tra la 1) e la 3), più veloce della 1) e meno dispendioso di risorse (memoria non volatile) della 3), sperando di non incorrere in un ibrido che condensi i difetti di entrambe le opzioni di utilizzo (tipo la 2).

Ciao

[cdimauro]

Originariamente inviato da xeal
Questo forse sarebbe più semplice (per certi versi) e meno "costoso" (in termini di risorse) da realizzare, anche se richiederebbe un notevole sforzo (nel progettare il tutto) per coordinare le varie emulazioni ed evitare eventuali conflitti (non so, tra programmi, o servizi, che richiedono livelli di priorità superiori a quelli previsti, e magari entrano in conflitto perchè cercano di fare la stessa cosa contemporaneamente "pretendendo" di farla in maniera esclusiva, anche se con un po' di accortezza si potrebbe evitare). Si potrebbero fornire all'applicazione tutte le librerie dell'os di origine, con interfaccia immutata e implementate in modo da richiamare le funzioni "vere" dell'os nativo, prevedendo un meccanismo simile per i servizi "erogati" da applicativi dell'os (ad esempio richiamati in una pipe).

E' esattamente quel che pensavo.

Però, questo sistema implicherebbe un problema di supporto non da poco, anzi due. Il primo relativo ai driver, che, se non reperibili come nativi ed emulati per ogni sistema potrebbero creare davvero dei conflitti, oltre che richiedere uno spreco di memoria (RAM in particolare),

Hum. Non credo: proprio questo modello servirebbe a semplificare e razionalizzare l'uso della RAM, che viene gestita dal s.o. principale. E' chiaro che se ci sono due applicazioni che allocano 1GB di ram a testa, non ci si può far nulla...

anche se si potrebbe ovviare con un driver fittizio associato agli originali che richiama all'occorrenza questo o quel driver trattandoli come overlay mutuamente esclusivi, ma questo inciderebbe negativamente sulle prestazioni, sia per l'emulazione, sia per lo swapping anche continuo.

E' una soluzione che si potrebbe utilizzare all'inizio, data la cronica mancanza di driver, per poi essere abbandonata col tempo...

Il secondo, credo irresolubile, relativo alle specifiche degli os da emulare, pena la non "rimappabilità" delle funzioni di libreria e delle syscall...

E' chiaro che ogni applicazione si trascina anche un "contesto" legato al s.o. da emulare, e che permette di gestire i passaggi delle chiamate dall'applicazione al s.o. nativo, che si occupa di gestire il servizio, emulandone le parti.
Un po' come avviene con Wine, insomma.

Per il resto, si, il meccanismo che hai descritto mi l'ho capito. Però mi sono spiegato male io... :

Allora ho anche capito male io...

Nella mia ipotesi mi riferivo alla 3), aggiungendo qualche accorgimento per cercare di ridurre lo spazio richiesto du disco, e mi chiedevo quanto questi "accorgimenti" potessero incidere sulla velocità, rendendo preferibile la 3) senza compromessi:
a) per ridurre spazio, pensavo di archiviare su disco (compilate per intero) le applicazioni usate più spesso, insieme al kernel, ai driver e ai moduli dell'os, diciamo, "secondari" richiamati più frequentemente, in modo da personalizzare tutto in base alle esigenze dell'utente e all'uso che fa del sistema (dandogli la possibilità di compilare e archiviare tutto o niente);

OK, ho capito. Sì, sarebbe la soluzione migliore in termini prestazionali.

b) per occupare ancora meno spazio, sempre in maniera opzionale, mi chiedevo se non si potesse comprimere il codice compilato, in modo da decomprimerlo direttamente nella RAM durante l'allocazione, eventualmente ricompattando le parti decompresse per evitare frammentazione di istruzioni e dati contigui (sempre in ram), oppure memorizzando (su disco) informazioni su come allocare correttamente i blocchi da decomprimere e/o analizzando le varie parti, eventualmente eseguite subito dopo la decompressione e prima che si decomprimano le successive (una sorta di decompressione jit che sostituisca la compilazione al volo, sperando che si abbia comunque un vantaggio, altrimenti sarebbe inutile).

Mumble. Quest'ultima è una soluzione di compromesso che non mi piace molto.

Preferirei la prima, ossia comprimere l'eseguibile compilato (con qualcosa tipo UPX), ma che poi viene interamente decompresso in memoria al caricamento, ed eseguito a piena velocità.

E' chiaro che l'occupazione di memoria sarebbe consistente, ma dati i costi delle ram e il continuo aumento del taglio con cui vengono venduti i computer, sia l'ipotesi da prendere maggiormente in considerazione...

Insomma, pensavo ad un compromesso tra la 1) e la 3), più veloce della 1) e meno dispendioso di risorse (memoria non volatile) della 3), sperando di non incorrere in un ibrido che condensi i difetti di entrambe le opzioni di utilizzo (tipo la 2).

Ciao

Ti sei spiegato bene, non ti preoccupare.

Ciao

[xeal]

Originariamente inviato da cdimauro
Hum. Non credo: proprio questo modello servirebbe a semplificare e razionalizzare l'uso della RAM, che viene gestita dal s.o. principale. E' chiaro che se ci sono due applicazioni che allocano 1GB di ram a testa, non ci si può far nulla...

In effetti sulla ram ho un po’ cercato il “pelo nell’uovo”: pensavo all’eventuale spreco nel caricare più driver relativi alla stessa periferica (sarebbe proporzionale al numero di os emulati, in mancanza di driver nativi) e ai conflitti che nascerebbero se alcuni dovessero avere lo stesso interrupt per l’os nativo (ed essere richiamati con quello da alcune applicazioni), cosa che potrebbe non essere vera, e comunque si potrebbe risolvere, ad esempio con una funzione nativa che richiama il driver corretto a seconda dell’applicazione che lo richiede (una sorta di mappatura virtuale degli interrupt). Usare gli overlay risolverebbe entrambi i problemi.

E' chiaro che ogni applicazione si trascina anche un "contesto" legato al s.o. da emulare, e che permette di gestire i passaggi delle chiamate dall'applicazione al s.o. nativo, che si occupa di gestire il servizio, emulandone le parti.
Un po' come avviene con Wine, insomma.

Qui sono rimasto un po’ fermo a qualche tempo fa: non c’erano dei problemi con qualche applicazione (ricordo che ce n’erano con Office, ma sono stati risolti)? E con le directx la chiusura delle specifiche non è un problema?

Ti sei spiegato bene, non ti preoccupare.

E invece no ma è colpa mia.

Preferirei la prima, ossia comprimere l'eseguibile compilato (con qualcosa tipo UPX), ma che poi viene interamente decompresso in memoria al caricamento, ed eseguito a piena velocità.

E’ quello che pensavo, tutto il resto, informazioni aggiuntive sul disco, deframmentazione della ram, esecuzione di qualche istruzione, sono solo ipotesi di meccanismi per evitare problemi di corretta allocazione del programma legata alla decompressione, ad esempio perché non c’è uno spazio contiguo sufficiente e un array si ritrova spezzato, oppure non si riesce a seguire lo scema delle richieste di allocazione di pagine che contengano istruzioni e/o debbano essere “etichettate” in un determinato modo. Il problema è che non conosco in dettaglio la gestione dell’allocazione di un eseguibile (specialmente a basso livello) e quindi ho formulato delle ipotesi un po’ confuse…

[cdimauro]

Originariamente inviato da xeal
In effetti sulla ram ho un po? cercato il ?pelo nell?uovo?: pensavo all?eventuale spreco nel caricare più driver relativi alla stessa periferica (sarebbe proporzionale al numero di os emulati, in mancanza di driver nativi)

Non credo che un driver "mangi" così tante risorse da "ingolfare" il sistema...

e ai conflitti che nascerebbero se alcuni dovessero avere lo stesso interrupt per l?os nativo (ed essere richiamati con quello da alcune applicazioni),

Gli interrupt da tempo si possono "virtualizzare".

cosa che potrebbe non essere vera, e comunque si potrebbe risolvere, ad esempio con una funzione nativa che richiama il driver corretto a seconda dell?applicazione che lo richiede (una sorta di mappatura virtuale degli interrupt). Usare gli overlay risolverebbe entrambi i problemi.

Per gli interrupt OK. Cosa intendi per "overlay" in questo contesto?

Qui sono rimasto un po? fermo a qualche tempo fa: non c?erano dei problemi con qualche applicazione (ricordo che ce n?erano con Office, ma sono stati risolti)? E con le directx la chiusura delle specifiche non è un problema?

L'unico problema in generale è proprio questo: se mancano le specifiche, è chiaro che si non puoi realizzare quanto ipotizzato...

Il problema è che non conosco in dettaglio la gestione dell?allocazione di un eseguibile (specialmente a basso livello) e quindi ho formulato delle ipotesi un po? confuse?

Neppure io conosco le specifiche dei formati degli eseguibili (ricordo soltanto la suddivisione in "hunk" di quelli per Amiga ), ma più o meno sono simili: suddivisione in sezioni codice, dati, bss, ed eventuale aggiunta di una sezione di rilocazione degli indirizzi assoluti per le sezioni di codice e/o dati.

[xeal]

Originariamente inviato da cdimauro
Per gli interrupt OK. Cosa intendi per "overlay" in questo contesto?

Quello che avevo ipotizzato nell'altro post: carichi i driver relativi a un os solo all'occorrenza, sostituendoli a quelli relativi a un altro os, appunto come se fossero overlay mutuamente esclusivi. Magari lo si fa solo in base alla quantità di memoria disponibile, che so, prima di effettuare lo swapping di pagine di memoria relative agli applicativi che sto eseguendo cerco di eliminare dalla ram i driver superflui, in base all'utilizzo fatto e/o alla presenza nelle code di programmi che li richiedono (eventualmente anche in base alla loro priorità), sempre che non appesantisca il meccanismo. Poi, appena i driver rimossi vengono richiamati, se c'è abbastanza memoria li carico e li lascio li insieme agli altri. Ok che un driver pesa poco, però tenerne in memoria tre/quattro per ogni periferica, quando magari lasciare solo quelli necessari mi consentirebbe di evitare uno swapping continuo su un'applicazione grossa (faccio un'ipotesi) che usa spesso tutte le sue pagine, non credo che sia il massimo. Comunque, si tratta (tratterebbe) di dettagli implementativi temporanei in attesa dell'arrivo di driver nativi.

L'unico problema in generale è proprio questo: se mancano le specifiche, è chiaro che si non puoi realizzare quanto ipotizzato...

A meno che...
Alcuni giochi e applicazioni cercano di installare una copia delle direct x... A questo punto, non si potrebbero considerare come una parte del programma da eseguire mediante jit? Probabilmente, però, qualcuno non sarebbe d'accordo...

Neppure io conosco le specifiche dei formati degli eseguibili (ricordo soltanto la suddivisione in "hunk" di quelli per Amiga ), ma più o meno sono simili: suddivisione in sezioni codice, dati, bss, ed eventuale aggiunta di una sezione di rilocazione degli indirizzi assoluti per le sezioni di codice e/o dati.

Insomma, in quel punto cercavo di dettagliare alla meno peggio un meccanismo per allocare l'eseguibile compresso esattamente come accadrebbe se non lo fosse, con l'unica differenza (se possibile) che durante l'allocazione viene decompresso

Ciao

[cdimauro]

Originariamente inviato da xeal
Quello che avevo ipotizzato nell'altro post: carichi i driver relativi a un os solo all'occorrenza, sostituendoli a quelli relativi a un altro os, appunto come se fossero overlay mutuamente esclusivi.

OK, adesso è chiaro.

Magari lo si fa solo in base alla quantità di memoria disponibile, che so, prima di effettuare lo swapping di pagine di memoria relative agli applicativi che sto eseguendo cerco di eliminare dalla ram i driver superflui, in base all'utilizzo fatto e/o alla presenza nelle code di programmi che li richiedono (eventualmente anche in base alla loro priorità), sempre che non appesantisca il meccanismo. Poi, appena i driver rimossi vengono richiamati, se c'è abbastanza memoria li carico e li lascio li insieme agli altri. Ok che un driver pesa poco, però tenerne in memoria tre/quattro per ogni periferica, quando magari lasciare solo quelli necessari mi consentirebbe di evitare uno swapping continuo su un'applicazione grossa (faccio un'ipotesi) che usa spesso tutte le sue pagine, non credo che sia il massimo. Comunque, si tratta (tratterebbe) di dettagli implementativi temporanei in attesa dell'arrivo di driver nativi.

OK. Considera, comunque, che la memoria non è affatto un problema, e il consumo da parte dei driver è abbastanza ridotto.

A meno che...
Alcuni giochi e applicazioni cercano di installare una copia delle direct x... A questo punto, non si potrebbero considerare come una parte del programma da eseguire mediante jit? Probabilmente, però, qualcuno non sarebbe d'accordo...

Esattamente.

Insomma, in quel punto cercavo di dettagliare alla meno peggio un meccanismo per allocare l'eseguibile compresso esattamente come accadrebbe se non lo fosse, con l'unica differenza (se possibile) che durante l'allocazione viene decompresso

Ciao

Praticamente quello che facevano programmini del calibro di PPLoadSeg per Amiga...