Dove è andato il morphing del codice?

Question

Linus Torvalds lavorava per una società di processori chiamata Transmeta. Il processore che hanno realizzato era un oggetto basato su RISC nel core. Se ricordo bene, l'idea era che il core eseguiva un "emulatore di processore" arbitrario e aggiornabile (poteva essere x86, powerpc ecc.), Che traduceva gli opcode di alto livello nel set di istruzioni core RISC.

Cosa è successo a questa idea e quali sono stati a tuo parere i pro, i contro e le situazioni in cui tale approccio avrebbe potuto avere un vantaggio (in termini di programmazione)?

Answer 1

La società non ha funzionato come previsto, e alla fine è stata acquisita da Novafora per la sua tecnologia di risparmio energetico. (http://www.novafora.com/pr01-28-09.html)

Da tutti i conti di cui sono a conoscenza, la tecnologia semplicemente non era in concorrenza con i sistemi esistenti. Erano molto inferiori ai loro numeri di prestazioni. Inoltre, sebbene sia stato possibile inserire un altro traduttore sopra al loro progetto VLIW, non sono a conoscenza di prodotti che hanno prodotto. Non ricordo che il chip di Crusoe sia in grado di accettare un download di microcodice "traduzione" alternativo.

Personalmente possedevo un dispositivo che utilizzava un processore Crusoe e, sebbene fosse certamente in grado di garantire la durata della batteria, le prestazioni del dispositivo erano tristi. Alcune delle colpe potrebbero probabilmente essere livellate sulla versione speciale di Windows utilizzata, ma era comunque lenta.

Nella migliore delle ipotesi, era buono per desktop remoto portatile.

IMHO, la tecnologia ha gli stessi vantaggi del software VM come .NET e JVM:

• Il vantaggio è che si può probabilmente accelerare il codice più veloce con una soluzione hardware (come IBM fa con è processori di acceleratori Java) rispetto al software JIT puro.
• Lo svantaggio è che non si ottiene mai la prestazione originale processori che eseguono il codice nativo get.

Da alcuni punti di vista è possibile pensare ai moderni chip x86 come al codice del morphing, anche se come molto specializzati.Traducono l'architettura x86 in un set di subistruzioni più efficiente simile a RISC, e poi li eseguono.

Un altro esempio di questo tipo di tecnologia potrebbe essere FPGA che può essere programmato per emulare a livello di circuito vari tipi di processori o circuiti grezzi. Credo che alcuni sistemi Cray possano venire con "nodi acceleratori" di questo tipo.

Answer 2

pro evidenti:

• Possibilità di eseguire qualsiasi sistema operativo (solo passare l'emulazione processore a quanto necessario)
• Possibilità (con supporto kernel naturalmente) di esecuzione di binari per architetture diverse sullo stesso processore/OS senza supporto software.

con Ovvio:

• strato di emulazione Extra == più luminosa == processore più veloce necessari per ottenere prestazioni equivalenti per tutto.

Answer 3

Per una cosa, la maggior parte dei processori CISC traducono internamente i propri opcode su micro-ops simili a quelli di RISC. Pipelining e core multipli hanno colmato il gap sui processori RISC fino al punto in cui c'è una minima differenza tra loro, se ce ne sono. Se è necessaria una compatibilità incrociata con l'origine C o un altro front-end di assemblaggio, è possibile utilizzare LLVM. http://llvm.org/

Answer 4

I processori più moderni implementano effettivamente i set di istruzioni utilizzando microcode. Ci sono molte ragioni per questo, inclusi i problemi di compatibilità, ma ci sono anche altri motivi .

La distinzione tra ciò che è "hardware" e ciò che è "software" è in realtà difficile da realizzare. Anche le moderne macchine virtuali come JVM o CIL (.NET) potrebbero essere implementate nell'hardware, ma probabilmente si farebbe comunque con l'uso del microcodice.

Una delle ragioni per avere diversi livelli di astrazione in un sistema è che il programmatori/ingegneri non devono pensare a dettagli irrilevanti quando stanno lavorando a un livello superiore.

Il sistema operativo e le librerie di sistema forniscono anche ulteriori livelli di astrazione. Ma avere questi livelli rende il sistema "più lento" solo se non è necessario disporre delle funzionalità che forniscono (ovvero la programmazione dei thread eseguita dal sistema operativo). Non è un compito facile ottenere il proprio programma di pianificazione specifico per battere quello del kernel di Linux.

Answer 5

Direi che le riduzioni dei costi arrivano con la quantità, quindi qualcosa come il chip Transmeta deve vendere molto volume prima di poter competere sul prezzo con i chip x86 ad alto volume esistenti.

Se ricordo, il punto del chip Transmeta era che era a bassa potenza. Avere meno gate in silicone per capovolgere avanti e indietro ogni ciclo di clock consente di risparmiare energia. Il codice morphing era così che potevi eseguire un set di istruzioni complesso (CISC) su un chip RISC a bassa potenza.

Il primo processore di Transmeta, il Crusoe, non ha funzionato molto bene a causa di problemi con l'esecuzione di software di benchmark. Il loro secondo processore, l'Efficeon, è riuscito a utilizzare meno energia rispetto a Intel Atom (nella stessa categoria di prestazioni), e ha prestazioni migliori rispetto a Centrino nella stessa potenza assorbita.

Ora, guardandolo dal punto di vista del software e della flessibilità come voi, Code Morphing è solo una forma di compilazione Just-In-Time, con tutti i vantaggi e gli svantaggi di tale tecnologia. Il tuo codice x86 è essenzialmente in esecuzione su una macchina virtuale e viene emulato da un altro processore. Il più grande vantaggio della virtualizzazione in questo momento è la possibilità di condividere un singolo processore tra molte macchine virtuali in modo da avere meno cicli di CPU inutilizzati, che è più efficiente (costo hardware e costo energetico).

Quindi mi sembra che il codice di morphing, proprio come qualsiasi altra forma di virtualizzazione, sia l'essere più efficiente con le risorse.

Answer 6

Per un altro approccio alla virtualizzazione ISA x86 con hardware, è possibile leggere la CPU Loongson 3.