Quanto non portatile è il linguaggio assembly, / davvero /?

Question

Capisco che scrivere qualsiasi cosa in assembly o aggiungere assembly a qualsiasi programma ne danneggi la portabilità. Ma quanto male? Voglio dire, praticamente tutti i PC sono x86 o x64 in questi giorni, giusto? Quindi, se incorporo assembly in un programma C, perché non dovrebbe ancora essere compilato, non importa dove sia andato?

Questa nozione di non portabilità si riferisce solo a quando veramente approfondisci le stranezze specifiche di un processore specifico, per spremere ogni calo di prestazioni da un pezzo di codice?

Il gioco per PC " Roller Coaster Tycoon " è stato scritto quasi interamente in linguaggio assembly se ricordo bene. Quindi ... Quanto potrebbe non essere portabile davvero?

Answer 1

Oltre al processore stesso, ci sono, ovviamente, sempre altre considerazioni: quali sono le convenzioni di chiamata sulla piattaforma di destinazione? Come vengono passati i valori struct ad altre funzioni (diciamo: API)? Quali registri possono essere bloccati dalla chiamata? Quali sono garantiti per essere conservati per il chiamante? Come effettuare una chiamata di sistema? Qual è il layout di memoria preparato per te dal sistema operativo all'avvio del processo?

Answer 2

Assemblaggio del porting, c'è anche il problema dell'ABI, che varia da SO a SO. Il porting di un programma C da Unix a Windows (o anche da Linux a OpenBSD) può essere una semplice ricompilazione, ma per un programma di assemblaggio, potresti scoprire che alcuni registri di salvataggio chiamate diventano salvataggi chiamante o che i parametri in virgola mobile sono passato diversamente.

E questo non è solo teorico, vale a dire. registrare r2 delle versioni PowerPC di Linux e Mac OS X. In pratica il problema potrebbe non essere troppo grave, ad esempio AMD ha pubblicato un "raccomandato". ABI contemporaneamente al set di istruzioni a 64 bit.

Answer 3

Se pensi che " PC == Windows " ;, l'aggiunta dell'assemblatore a un programma C non fa molto male. Se entri nel mondo Unix, avrai molte CPU diverse: PPC su PS3 o XBox, vecchi Mac e molti server potenti. Per molti piccoli dispositivi, avrai ARM. I dispositivi integrati (che rappresentano oggi la stragrande maggioranza delle CPU installate) di solito usano la propria CPU personalizzata con un set di istruzioni speciale.

Quindi, mentre molti PC oggi saranno in grado di eseguire il codice Intel, ciò rappresenta solo una piccola parte di tutte le CPU là fuori.

Detto questo, il codice x86 non è sempre lo stesso. Esistono due motivi principali per il codice assembly: è necessario accedere a funzioni speciali (come i registri di interrupt) o si desidera ottimizzare il codice. Nel primo caso, il codice è piuttosto portatile. In quest'ultimo caso, ogni CPU è leggermente diversa. Alcuni hanno SSE . Ma SSE fu presto sostituito con SSE2 che fu sostituito con SSE3 e SSE4. AMD ha il proprio marchio. Presto ci sarà AVX. A livello di codice operativo, ciascuno di essi ha tempi leggermente diversi sulle varie versioni delle CPU.

A peggiorare le cose, alcuni codici operativi hanno dei bug risolti in specifici passaggi di una CPU. Inoltre, alcuni codici operativi sono molto più veloci su alcune versioni di CPU rispetto ad altre.

Successivamente, dovrai interfacciare questo codice assembly con la parte C. Questo di solito significa che devi affrontare i ABI .

Quindi puoi vedere che questo può diventare arbitrariamente complesso.

Answer 4

assembly sta scrivendo le istruzioni direttamente per un processore specifico, il che significa che se x86 vive per sempre il tuo codice è in qualche modo portatile.

Ma anche ora il processore arm sta tornando (cioè il libro di rete della prossima generazione) e sono sicuro che il processore non cambierà nel prossimo anno.

Direi che il linguaggio dell'assemblaggio non è portatile per progettazione.