Grazie a Snapdragon notebook Windows con l'autonomia di uno smartphone

[zappy]

Originariamente inviato da LucaLindholm

...- Quado viene eseguito per la prima volta un programma desktop tradizionale, il compilatore Jitter ricompila l'eseguibile, convertendo le chiamate al processore x86 in chiamate verso ARM:

scusa l'ignoranza assoluta, ma se un exe x86 viene ricompilato x arm vuol dire che quando lo installi da qualche parte c'è pure sorgente?

[LMCH]

Originariamente inviato da zappy

scusa l'ignoranza assoluta, ma se un exe x86 viene ricompilato x arm vuol dire che quando lo installi da qualche parte c'è pure sorgente?

Non e' necessario il sorgente.
In questi casi il codice binario x86 invece di essere decodificato dalla cpu viene letto da un compilatore come se fosse un sorgente (codificato in binario invece che come testo) e le istruzioni x86 "decodificate in software" vengono convertite in un formato intermedio simbolico che poi viene poi compilato in codice binario per ARM.

E' in poche parole come quando si fa la compilazione JiT oppure AoT del bytecode CIL di .Net o del bytecode JVM di Java, solo che invece di usare un bytecode "ottimizzato per essere ricompilato" si usa il formato delle istruzioni x86 (che non e' stato ottimizzato per questo e quindi è più complesso da gestire, specialmente perche invece di una VM "pulita" ha come modello di esecuzione quello delle cpu x86 con tutte le loro peculiarità).

[amd-novello]

Originariamente inviato da cecco89

ma se wind 10 sta su snapdragon, perche non posso metterlo su uno smarphone, con la tipe C puoi attaccare un monitor esterno, hai tutte le connettività per tastiera e mouse, praticamente diventa un pc tascabile!

calcola che in macchine del genere possono farli andare a freq più alte che negli spazi risicati dei cellulari non si può.

[TheDarkAngel]

Originariamente inviato da amd-novello

calcola che in macchine del genere possono farli andare a freq più alte che negli spazi risicati dei cellulari non si può.

Se non spremi la gpu, la frequenza cala di ben poco, l'835 è un soc veramente poco energivoro.

[cdimauro]

Originariamente inviato da LMCH

Non e' necessario il sorgente.
In questi casi il codice binario x86 invece di essere decodificato dalla cpu viene letto da un compilatore come se fosse un sorgente (codificato in binario invece che come testo) e le istruzioni x86 "decodificate in software" vengono convertite in un formato intermedio simbolico che poi viene poi compilato in codice binario per ARM.

E' in poche parole come quando si fa la compilazione JiT oppure AoT del bytecode CIL di .Net o del bytecode JVM di Java, solo che invece di usare un bytecode "ottimizzato per essere ricompilato" si usa il formato delle istruzioni x86 (che non e' stato ottimizzato per questo e quindi è più complesso da gestire, specialmente perche invece di una VM "pulita" ha come modello di esecuzione quello delle cpu x86 con tutte le loro peculiarità).

Diciamo che è molto più simile alla JVM di Java, che compila frammenti di bytecode quando gli servono, e quindi senza compilazione AoT (come invece capita con .NET).

Una compilazione AoT di un eseguibile x86/x64 (ma vale per qualunque qualunque architettura) in genere non è possibile, perché normalmente un binario non si porta mai dietro sufficienti informazioni per identificare tutti i pezzi di codice / funzioni / metodi al suo interno.

Per ottenere tutte queste informazioni non basta partire dal punto di avvio (entry point in gergo) e tracciare via via tutte le routine eseguite: funziona bene soltanto per codici molto semplici, che contengono esclusivamente istruzioni di salto a funzioni/metodi statici (le istruzioni referenziano direttamente la locazione di memoria da eseguire).
Ma il codice di un'applicazione "di spessore" usualmente impiega puntatori a funzioni/metodi e tabelle di puntatori a funzioni/metodi, che potrebbero anche cambiare valore durante l'esecuzione; in questi casi non si può far altro che tracciare l'esecuzione finché non si arriva all'istruzione di salto che fa uso del puntatore a funzione, leggere finalmente l'indirizzo a cui saltare, e se non è stato ancora compilato provvedere ad analizzare il frammento e convertirlo finalmente in un frammento dell'architettura nativa.

Dunque, e per concludere, una compilazione AoT di un binario "non banale" si potrebbe fare se e solo, durante tutte le volte che è stato eseguito, alla fine si è riusciti a mappare tutti i suoi frammenti di codice. In questo caso, avendo ormai la mappa di tutto, sarebbe possibile tirare fuori direttamente un eseguibile per l'architettura nativa, buttando via il binario originale.

C'è una sola eccezione a tutto questo discorso, ed è rappresentata dalle applicazioni che generano codice dinamicamente. Ad esempio WinUAE, un emulatore Amiga, che compila dinamicamente codice Motorola 68K in frammenti x86 o x64 (a seconda del binario utilizzato). In questo caso l'applicazione x86/x64 genera ed esegue al volo frammenti di codice x86 o x64, a seconda di quando gli servono. Questo significa che una compilazione AoT di WinUAE x86/x64 per ARMv8 non sarà mai possibile (per essere precisi, sarebbe possibile convertire l'intero binario x86/x64, ma il JIT x86/x64 -> ARMv8 dovrà essere sempre attivo per intercettare i casi in cui venga richiamato codice x86/x64 generato dinamicamente).