FX!32 - trasparenza
Lancio trasparente delle win32 x86
applications 
Uso di una DLL, il TRASPARENCY AGENT
Lanciare un’applicazione su NT 
Risultato di una chiamata alla funzione
CreateProcess
Il TRASPARENCY AGENT analizza l’immagine
FX!32 - trasparenza
Immagine X86?
il TRASPARENCY AGENT viene “iniettato” nell’address
space del processo  ENABLED
Trasparency agent
Capace di cambiare il comportamento delle API
chiamate da Alpha … es: LoadLibrary
Importante perché tentativi di avviare img x86 con
il loader nativo  errore !
FX!32 - Run Time
Run Time Environment
WIN NT invoca il runtime di FX!32 tramite il trasparency
agent
Garantiscono la trasparenza
L’emulatore
Il pieno supporto per l’ambiente WIN32
FX!32 - Run Time
Run Time operations
Carica l’immagine in memoria
Setta il runtime environment
 inizia l’emulazione dell’immagine
Il Run Time Loader …
Duplica le funzionalità del loader di NT
Dopo che l’immagine è caricata  il loader inserisce
puntatori alla stessa in varie liste utilizzate da NT
FX!32 - Run Time
Il Run Time Loader
Queste liste permettono a NT nativo di Alpha di
trattare in egual modo codice alpha e codice x86.
Fortunatamente queste liste sono nell’user address
space  non sono richieste modifiche del sistema
operativo nt !!!
Sfortunatamente … La struttura di queste liste non è
parte dell’interfaccia documentata di win 32 … e
usarle crea dipendenza sulla particolare versione di
NT che si sta utilizzando …
FX!32 - Run Time
Cosa succede poi …
L’immagine è inserita nel database di FX!32
Al db si accede con un ID hash dell’header
dell’immagine
C’è l’immagine tradotta ?
Non è altro che una normale DLL contenente il codice
Alpha risultato di traduzione e le corrispondenze tra
codice x86 e codice alpha
Altrimenti emulazione !!!
TIPI DI EMULATORE
Gli emulatori possono essere sviluppati
per lavorare
- in un ambiente ristretto
l’utente lancia l’emulatore e dalla finestra dello stesso esegue
l’applicazione  NIENTE TRASPARENZA !!!
- in maniera integrata con il sistema operativo
la via scelta da DIGITAL per FX!32
ricordiamo inoltre che WIN NT conteneva, sin dalla sua prima versione
per RISC, un emulatore per applicazioni 16-bit
TIPI DI EMULATORE
Con Fx!32 lavorano solo applicazioni
win32
- chiamate al sistema operativo
eseguite nativamente dalle API  MOLTO VELOCI
- NON TRADOTTE
applicazioni da 16 bit per win16, win3.x o dos
di queste si occupa appunto l’emulatore di cui si parlava prima
(sempre emulate … )
EMULAZIONE
Qual’è il lavoro fondamentale
dell’emulatore ?
… Fare girare le applicazioni prima
che siano tradotte.
La prima esecuzione di un immagine x86 su FX!32
è infatti eseguita dall’emulatore !!!
EMULAZIONE
Non è possibile determinare
staticamente tutto il codice che può
essere eseguito da un’applicazione
… l’emulatore è sempre “presente” per eseguire il codice
non ancora tradotto…
L’integrazione del PROFILE avviene al termine
dell’esecuzione dell’immagine, dopo la quale verranno
elaborate le dll mancanti …
EMULATORE DI FX!32
L’emulatore di FX!32 è stato realizzato
con estrema cura :
- Scritto in Alpha Assembler
- Richiede una media di 45 istruzioni Alpha per
un’istruzione X86
Accettabile per un utilizzo non frequente …
MA TROPPO LENTA per incontrare i design
goals dei progettisti della DIGITAL !!!
EMULATORE DI FX!32
Come lavora questo emulatore ?
- quando un’applicazione x86 sta girando
lo stato del processore x86 è tenuto
 in parte nei registri alpha
 in parte in una struttura chiamata CONTEXT
- i registri
interi di x86 sono mappati permanentemente nei registri di Alpha
i registri di alpha mantengono i valori degli x86 condition codes
quando l’emulatore gira  un registro alpha dedicato punta al CONTEXT
Mantiene lo stato dell’x86 assieme ad altre
Parti del sys  es: API di Alpha
EMULATORE DI FX!32
Qual è la sua struttura ?
- è quella classica del ciclo fetch & evaluate
 L’emulatore prende in considerazione i primi 2 byte di ogni istruzione
 Performa un controllo in una tabella (dispatch table) di 64 entries
 Ogni entry contiene l’indirizzo ad una routine da eseguire per
interpretare una istruzione + la lunghezza dell’istruzione
Struttura del ciclo di dispatch
 costruita ad arte per fare uso efficiente dei registri a 64 bit di alpha
 per ottenere uno scheduling efficiente
E’ utilizzato un pipeling software
per sovrappore il fetch e il lookup alla dispatch table della successiva
istruzione
con l’esecuzione dell’istruzione corrente
EMULATORE DI FX!32
Concludendo sull’emulatore …
Tiene traccia della porzione di applicazione che è stata
emulata
 Il risultato è mantenuto in un file di log, EXECUTION
PROFILE.
 Questo profilo serve per fare partire la successiva parte
di traduzione.
EMULATORE DI FX!32
Contenuto del profilo generato
Indirizzi che sono target di istruzioni di tipo CALL
 source e target address per jump indiretti
I dati del profilo sono raccolti inserendo valori in una hash
table quando avvengono operazioni rilevanti  una volta finita
l’emulazione, la tabella viene processata e si crea il profilo
EMULATORE DI FX!32
La prima volta che un’applicazione
gira
 performance ridotte: completamente emulata e senza
ottimizzazione
le applicazioni che soffrono di più  quelle di calcolo
vanno meglio  quelle basate su sys call di NT.
FX!32 - JACKETS
Tra le altre funzioni di FX!32 
JACKETING
I Jacket sono piccoli frammenti di codice che servono per
Permettere cross-architecture interoperability
NT ALPHA provvede le stesse routines
provviste da NT per X86 ma …
… DIVERSE CONVENZIONI DI CHIAMATA !!!
FX!32 - JACKETS
2 tipi di jacket:
Statici
creati in base ad una definita interfaccia conosciuta
a load time
Dinamici
per gli oggetti COM le cui interfacce non sono
staticamente disponibili (jacketing dinamico a runtime
tramite le librerie OLE)
FX!32 - JACKETS
Jackets più comuni
 Per win32 api
molte applicazioni spendono almeno la metà del loro
execution time utilizzando queste librerie.
FX!32 provvede più di 50 dll native Alpha; circa 12.000
routines sono correntemente jacketed
Ogni jacket contiene una istruzione illegale e speciale x86 che serve a
dire all’emulatore di effettuare lo switch nell’Alpha Environment
l’operazione principale dei jacket è muovere argomenti dall’x86 stack
ai registri Alpha
FX!32 - JACKETS
Jackets più comuni
 Per call back routines
in molte routines sono passati gli indirizzi di routines
da chiamare in caso di un determinato evento
se questo indirizzo venisse passato “alla cieca”,
alpha potrebbe chiamare una locazione con codice
x86  sicuramente errore !!!
Viene creato staticamente un jacket per ogni argomento che rappresenti
un puntatore a procedura, e l’indirizzo di questo jacket è passato al
codice nativo  quando viene chiamata la routine con questo
argomento si entra nell’FX!32 runtime
FX!32 - JACKETS
Jackets più comuni
 per COM objects
un oggetto COM è rappresentato da una tavola di
puntatori a funzioni OLE.
Queste funzioni spesso hanno argomenti che sono
puntatori a funzioni o strutture contenenti puntatori
a funzioni…
FX!32 - JACKETS
Jackets più comuni
 per plug-in extensions
funzionalità interessante : applicazione nativa
ma plugin per x86 !!!
ognuna di esse richiede interfacce
 1 interfaccia  1 jacket
non disponibile a runtime  solo alcune
applicazioni
FX!32 - SERVER
E’ quello che coordina il runtime con il
background optimizer
FX!32 - Velocità
Abbiamo visto sinora come garantire la
trasparenza … e la velocità ?
C’è il BACKGROUND OPTIMIZER
Il background optimizer è un
BINARY TRANSLATOR DI TERZA GENERAZIONE,
PROFILE-DIRECTED
Produce high speed alpha native code dal codice x86
utilizzando le informazioni rese note dal profile
FX!32 - Velocità
Anche il background optimizer assicura la
trasparenza e deve essere robusto
quanto il RUN TIME
L’user non deve mai vedere le operazione del background
Optimizer  no manual initiation, no user intervention
Il background optimizer …
Garantisce la trasparenza e robustezza cooperando
con il runtime per assicurare una fedele rappresentazione
dell’x86 machine state
FX!32 - Velocità
Per x86 machine state coerente si intende
che …
… tutte le assegnazioni di valore ai registri x86, i call/return
boundaries e lo stack x86 riflettono quello che realmente
potrebbe osservarsi su un HW x86
Il background optimizer …
… è stato realizzato per avere buone performance.
Per questo sono state utilizzate tecniche di ottimizzazione
globale (usate anche dai moderni compilatori)
FX!32 - Velocità
Un difetto dei vecchi binary translator era
la loro limitazione ai basic blocks come
fondamentale unità di traduzione
Il background optimizer rimosse con successo questa restrizione
gruppi di basic blocks scelti in unità dette translation units.
Concettualmente, una translation unit approssima una routine
in un compilatore tradizionale
FX!32 - TRANSLATOR
La traduzione del codice parte dal profile
Essendo basato sul profilo, il translator è stato più
facile da scrivere di altri, è più veloce e produce
codice migliore
Regionizer
Rappresenta routines come collezione di regioni 
ogni regione è un range di indirizzi contigui
contenenti istruzioni raggiungibili dall’entry point
della routine
Diversamente da basic block  regioni possono avere
multiple entry point
FX!32 - TRANSLATOR
Rappresentazione intermedia
L’immagine è processata una routine alla volta; per i
cammini non esplorati si inserisce nella traduzione
una chiamata all’emulatore
Ottimizzazione
Il translator utilizza un simple code generator per
mappare le istruzioni x86 in una corretta, ma lunga,
sequenza di istruzioni alpha.
 Il translator utilizza quindi tecniche di global
optimization per migliorare il codice (dead code
elimination, register renaming etc)
FX!32 - TRANSLATOR
Background optimizer …
… salva su disco il risultato della traduzione come file
.dll; i file che vengono tradotti sono i .exe e i .dll
(librerie)
Ritraduzione
Generalmente dopo una traduzione
 no aggiornamenti o ritraduzioni… a meno che non vengano
utilizzate features del sw mai utilizzate prima (quindi cambia il
modo in cui il pgm è utilizzato) e quindi ci sia bisogno di una
completa ritraduzione con relativa ottimizzazione. La
decisione di una eventuale ritraduzione è basata sulla
crescita dell’execution profile.
FX!32 - Requisiti
 le traduzioni sono messe su file  fx!32 può
prendere vantaggio dall’idea di shared code
libraries. Questo vale soprattutto per gruppi di
applicazioni che condividono codice.
 Il vantaggio si traduce in meno spazio occupato
su disco : infatti su disco devono stare il file
originale x86 e la sua traduzione, che solitamente
occupa il doppio dello spazio dell’originale !!!
FX!32 - Requisiti
Requisiti particolarmente modesti
Il server di trasparenza occupa in RAM solo 140
KB
Il run-time emulator richiede circa 2 MB di RAM,
poco se si considera il task svolto
 Quando gira il background translator questo
occupa circa 1.5 MB di ram più abbastanza per
mantenere il file originale e quello tradotto.
FX!32 - Prestazioni
Qui i risultati di un benchmark a confronto con un pentium 200 mhz a un alpha a 500 mhz con
configurazioni simili
FX!32 - Mancanze





Non esegue drivers … solo drivers nativi
non è provveduto supporto completo per tutti i servizi di
windows nt perché taluni vengono abilitati solo dopo la
partenza del server di fx!32
Non supportate le API di debug di NT (utilizzate dai
development environments di x86)
No 16 bit (vedi emulazione)
Sicuramente allo stato odierno fx!32 non raggiunge il suo
obiettivo di girare al 70% della velocità nativa alpha. Per
alcune applicazioni – tipo word o e-mail – raggiungere la max
velocità non è una grande cosa !