Riassunto sugli Universal Binary per Mac OS X

n.d.t. Questa pagina web è la traduzione in italiano di una pagina inglese realizzata da Richard Buckle denominata "Mac OS X Universal Binary API redux".

Di seguito sono riportate alcune note brevi e relativamente non strutturate che ho realizzato durante la lettura del documento di Apple Universal Binary guidelines, con la prospettiva di creare una lista delle cose da fare per i miei progetti personali. Spero che siano utili. Eventuali errori ed omissioni sono i miei (n.d.t. oppure del traduttore) e suggerimenti e chiarificazioni sono i benvenuti.

Considerazioni generali

• Se non si utilizza ancora Mach-O, bisogna migrare al più presto.
• Se non si utilizza ancora Xcode, bisogna migrare al più presto.
• Soltanto il nuovo MacOSX10.4u.sdk è portabile verso x86.
• Aggiornamento: è possibile combinare eseguibili per PowerPC, creati con versioni precedenti del GCC e/o precedenti SDK di Mac OS X, con eseguibili x86, in questo modo supportare Panther e precedenti non è un problema. Chris Espinosa ha un esempio nella sua cartella pubblica di iDisk "cdespinosa", contenuto in una cartella chiamata "SDKExample"
• Eric Albert ha fatto notare il tool standard per sviluppatori lipo, per ispezionare e manipolare arbitrariamente gli eseguibili fat.
• A partire da Xcode 2.2 è possibile raggiungere lo stesso risultato mostrato nell'esempio di Espinosa in maniera più semplice e veloce, utilizzando alcuni flag di configurazione dipendenti dall'architettura, come GCC_VERSION_ppc, SDK_ROOT_ppc e MACOSX_DEPLOYMENT_TARGET_ppc.
• CodeWarrior è morto, Jim. Mi dispiace così come dispiace a chiunque, ma i fatti sono fatti. :-( 

Ordinamento ed inversione dei byte, ecc...

Devono essere prese in considerazione tutte le questioni relative all'ordinamento dei byte che sono familiari a chiunque abbia fatto un porting da Mac a Windows o viceversa:

• Per le strutture gestite dal sistema operativo, ad esempio i menu, il sistemo operativo si occuperà dell'inversione dei byte. Si è responsabili per l'inversione dei byte dei propri dati caricati o salvati su disco e trasmessi su network, inclusi i dati personalizzati (custom) degli Apple Event e qualsiasi cosa si include dentro, ad esempio pacchetti TCP. Si continui la lettura...
• I tipi di dato relativi agli Apple Event predefiniti dal sistema sono invertiti dal sistema operativo, ma si devono invertire manualmente i tipi di dato definiti dalla propria applicazione. Si può registrare una procedura 'flipper' con il gestore degli Apple Event per ridurre l'impatto sul codice.
• Analogamente si può registrare una procedura flipper con il Resource Manager, per invertire i byte delle risorse e dei tipi di dato utilizzati con la clipboard definiti dalla propria applicazione. Può essere la stessa procedura flipper utilizzata con gli Apple Event. Attenzione: se la risorsa è definita come "preloaded" (pre-caricata), il flipper non sarà chiamato. Ad una prima lettura, le API per la registrazione sembrano occuparsi degli espedienti necessari per la conversione tra OSType e UTI.
• La seconda edizione del documento include una guida nettamente migliorata per invertire i byte delle risorse PowerPlant 'PPob', in cui l'idea chiave è di concentrare tutte le inversioni nella classe LStream. Pressappoco tutto quello che bisogna fare ora è verificare le eventuali classi personalizzate che chiamano LStream::ReadData e scegliere se utilizzare metodi di LStream a grana più fine od occuparsi personalmente dell'inversione. 
• Gli AliasRecord sono sempre big-endian e bisogna usare i metodi accessori per userType e aliasSize.
• Alcune funzioni deprecate della Toolbox hanno problemi con l'inversione dei byte. I warning per queste funzioni sono attivi per default in XCode 2.1 o superiore.
• Aggiornamento: Mi hanno chiesto maggiori dettagli su questo punto. Il documento di Apple è un po' vago, dice soltanto "come quelle che utilizzano i dati PICT e PS".
• FOND, NFNT, sfnt, ecc..., sono sempre big-endian. Bisogna utilizzare le funzioni dell'Apple Type Services oppure occuparsi personalmente dell'inversione.

Altre questioni relativi alla dimensione ed all'allineamento dei dati

• Di nuovo queste saranno familiari per chiunque abbia fatto un porting da Mac a Windows o viceversa:
• i bit-field del C sono dipendenti sia dall'architettura che dal compilatore. Nessuna sorpresa.
• Non bisogna mischiare BitTst(), ecc.. con gli operatori del C per i bit come |, & e ~.
• Bisogna stare attenti nell'utilizzare BitTst() sui valori di Gestalt().
• bool è di un byte su x86 e 4 byte su PowerPC, almeno sotto Xcode. Nessuna sorpresa: lo standard ha sempre detto che sizeof(bool) dipende dall'implementazione, anche se entro certi limiti.
• Confrontare l'uguaglianza tra floating point dipende dall'architettura (ma ammettiamolo, sarebbe stupido affidarsi a tale confronto in ogni caso).
• "Su x86, un long double è ancora di 16 byte, ma soltanto 80 bit sono significativi." Ho bisogno di riflettere prima di commentare cosa implichi questo fatto.
• Convertire un tipo double ad un integer che non è grande abbastanza per rappresentare la parte intera del double dipende dall'architettura. Si potrebbe ottenere INT_MAX, si potrebbe ottenere INT_MIN. Si potrebbe ottenere il nome da nubile della mia prozia in ASCII. Non bisogna affidarsi a tali conversioni.
• Non si dice nulla a proposito di wchar_t. Probabilmente è meglio evitarlo. :-(

Strutture di basso livello del disco

• Il partizionamento del disco è diverso su x86.
• Alcune strutture HFS+ a basso livello sono sempre big-endian.

Objective-C

• Su x86 i messaggi ad oggetti nil in Objective-C ritornano spazzatura per i tipi di ritorno float e double (in realtà qualsiasi cosa ci sia in st(0)). Apple afferma che su PowerPC si ottiene 0.0, ma non è corretto: si ottiene qualsiasi cosa ci sia nel registro FPR1. E' stata inviata una correzione.
• C'è un paragrafo su una differenza sull'ABI con la funzione runtime objc_msgSend_stret dell'Objective-C che va al di là della mia testa.

AltiVec

• Si può utilizzare il framework Accelerate (per Mac OS X 10.3 o superiore) al posto di Altivec o fare il porting verso le API SIMD di Intel. Ho saltato il resto di questa sezione perché era al di là della mia testa, ma ho notato che le questioni di allineamento richiedono un'attenzione speciale.

QuickDraw, QuickTime e OpenGL

• Gli GWorld sono big-endian per default ma è possibile creare formati little-endian. Tuttavia QuickDraw su PowerPC non supporta gli GWorld little-endian.
• Alcuni tipi di pixel di OpenGL e Quartz necessitano di particolare attenzione riguardo alle questioni di ordinamento dei byte.
• Per le strutture Picture di QuickDraw bisogna utilizzare QDGetPictureBounds() piuttosto che accedere a .picFrame. Non si deve effettuare il cast del risultato di DeltaPoint() ad una struttura Point, ma bisogna invece utilizzare le macro LoWord e HiWord.
• Le risorse 'thng' di QuickTime necessitano di un trattamento particolare.

Rosetta

• Rosetta è trasparente per l'utente, ma il comando "Ottieni Informazioni" del Finder mostrerà per quale piattaforma l'applicazione è compilata.
• Rosetta esegue le applicazioni PowerPC su x86, ma non viceversa :-(
• Rosetta non può eseguire applicazioni Classic, codice AltiVec, pannelli di preferenze di sistema, codice specifico per G4/G5, estensioni del kernel, applicazioni Java "bundled" ed applicazioni Java con librerie JNI che non possono essere tradotte. 
• Aggiornamento: ora la versione di Rosetta in distribuzione supporta AltiVec
• Rosetta non supporta il mischiare differenti architetture riguardo applicazioni e plug-ins, framework privati, ecc... E' un meccanismo tutto-o-niente per ogni processo.
• Rosetta è just-in-time, traduce dinamicamente le istruzioni al run-time solo quando servono, ma fa uso di un ampio buffer di traduzione. Apple dichiara che il codice riutilizzato verrà tradotto una sola volta.
• Ci sono problemi con il formato di ordinamento dei byte (endian) quando un'applicazione tradotta condivide formati di file proprietari, clipboard personalizzate, ecc... con applicazioni native.
• E' possibile forzare un universal binary ad aprirsi con Rosetta.
• Ci sono limitazioni abbastanza severe riguardo il debugging di un'applicazione tradotta.
• Chi di noi ha vissuto la transizione da 68K a PowerPC vedrà immediatamente che Rosetta non è per niente una soluzione così completa com'era il Mixed Mode Manager :-(

64-bit

Questo documento non dice nulla sull'indirizzamento a 64-bit e sulle API per file a 64-bit. Ovviamente l'indirizzamento a 64-bit non è supportato in x86 ("cough", AMD, "cough"). Presumibilmente le API per file a 64-bit "semplicemente funzioneranno" (senza bisogno di altri accorgimenti).

Accorgimenti vari

• La divisione per zero tra interi è fatale su x86
• L'x86 ha meno registri del PowerPC, quindi le variabili locali hanno più probabilità di essere sullo stack di quante non ne abbiano con il PowerPC. Pertanto del cattivo codice che scrive al di là dello spazio riservato alle variabili locali ha più probabilità di superare lo stack e mandare in crash l'applicazione su x86.
• Se si utilizza la struttura MachineLocation per i fusi orari, ecc..., si dovrà utilizzare .u.dls.Delta piuttosto che .u.dlsDelta e bisogna settare .u.dls.Delta DOPO aver settato .u.gmtDelta. Ugh.
• L'hyperthreading ed il dual-core di Intel verranno supportati dalle API per i thread. Per questo non bisogna forzare manualmente nel codice il numero di thread o limitarlo al numero di CPU.
• OSEnqueueAtomic e OSDequeueAtomic non sono disponibili su x86 (il documento di Apple cita erroneamente OSEnqueAtomic).
• Se si genera del codice al run-time, bisogna essere consapevoli che lo stack deve essere allineato a 16-bit quando si chiamano librerie di sistema o framework. Presumibilmente questo si applica anche a chi scrive codice assembler.

Questo è tutto per adesso. Se lo trovi utile fammelo sapere (n.d.t. in inglese, corrisponde alla mail dell'autore originale).

n.d.t. Per scrivere al traduttore e segnalare eventuali errori di traduzione cliccare qui.