Quanto è spiacevole il linguaggio assembly,/veramente /?

Question

Capisco che scrivere qualcosa 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 l'assembly in un programma C, perché non dovrebbe ancora compilare, non importa dove sia andato?

Questa nozione di non portabilità si riferisce a quando si in realtà si scava nelle peculiarità specifiche di un processore specifico, per spremere ogni goccia di prestazioni da un pezzo di codice?

Il gioco per PC "Roller Coaster Tycoon" è stato scritto quasi interamente in linguaggio assembly, se non ricordo male. Quindi ... quanto potrebbe essere davvero sfortunato?

Answer 1

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

Answer 2

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

Ma anche ora il processore di braccio sta tornando (vale a dire il netbook di prossima generazione) e sono sicuro che il processore non cambierà nel prossimo anno.

Direi che il linguaggio assembly non è portatile.

Answer 3

Assemblaggio di porte, c'è anche il problema dell'ABI, che varia da OS a OS. Portare un programma C da Unix a Windows (o anche da Linux a OpenBSD) può essere una semplice ricompilazione, ma per un programma di assemblaggio, potreste scoprire che alcuni registri salvati con il callee diventano chiamanti-salvati, o che i parametri in virgola mobile sono passato diversamente.

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

Answer 4

Se si pensa "PC == Windows", l'aggiunta di assembler a un programma in C non danneggia molto. Se entri nel mondo Unix, avrai molte CPU diverse: PPC in PS3 o XBox, vecchi Mac e molti server potenti. Per molti piccoli dispositivi, avrai ARM. I dispositivi integrati (che rappresentano la maggior parte delle CPU installate oggi) usano solitamente la propria CPU personalizzata con un set di istruzioni speciali.

Così mentre molti PC oggi saranno in grado di eseguire il codice Intel, ciò rappresenta solo una piccola parte di tutte le CPU disponibili.

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 è abbastanza portatile. Nel secondo caso, ogni CPU è leggermente diversa. Alcuni di loro hanno SSE. Ma SSE è stato presto sostituito con SSE2 che è stato sostituito con SSE3 e SSE4. AMD ha il proprio marchio. Presto, ci sarà AVX. A livello di opcode, ognuno di questi ha un timing leggermente diverso sulle varie versioni di CPU.

Per peggiorare le cose, alcuni codici operativi hanno bug corretti in specifici passaggi di una CPU. Inoltre, alcuni opcode sono molto più veloci su determinate versioni di CPU rispetto ad altre.

Successivamente, sarà necessario interfacciare questo codice di assieme con la parte C. Questo di solito significa che devi risolvere i problemi con ABI.

Così puoi vedere che questo può diventare arbitrariamente complesso.