FX!32 - trasparenza Lancio trasparente delle win32 x86 applications  Uso di una DLL, il TRASPARENCY AGENT Lanciare un’applicazione su NT  Risultato di.

Presentazione sul tema: "FX!32 - trasparenza Lancio trasparente delle win32 x86 applications  Uso di una DLL, il TRASPARENCY AGENT Lanciare un’applicazione su NT  Risultato di."— Transcript della presentazione:

1 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

2 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 !

3 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

4 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

5 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 …

6 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 !!!

7 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

8 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 … )

9 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 !!!

10 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 …

11 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 !!!

12 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

13 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

14 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.

15 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

16 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.

17 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 !!!

18 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

19 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

20 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

21 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

22 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 - JACKETS

23 FX!32 - SERVER E’ quello che coordina il runtime con il background optimizer

24 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

25 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

26 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)

27 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

28 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

29 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)

30 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.

31 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 !!!

32 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.

33 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

34 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 !