GCC Inline Assembly - Asamblator inline al compilatorului GCC , care este un limbaj de descriere macro pentru interfața de cod compilat de nivel înalt cu inserare de asamblare .
Sintaxa și semantica GCC Inline Assembly are următoarele diferențe semnificative:
Pentru a înțelege cum funcționează GCC Inline Assembly, trebuie să înțelegeți bine pașii implicați în procesul de compilare.
La început, gcc apelează preprocesorul cpp, care include fișierele antet , extinde toate directivele condiționate și efectuează substituții de macro. Puteți vedea ce sa întâmplat după înlocuirea macro cu comanda gcc -E -o preprocessed.c some_file.c. Comutatorul -E este rar folosit, mai ales atunci când depanați macrocomenzi.
Apoi gcc analizează codul rezultat, optimizează codul în aceeași fază și în cele din urmă produce cod de asamblare. Puteți vedea codul de asamblare generat cu comanda gcc -S -o some_file.S some_file.c.
Apoi gcc apelează gazul de asamblare pentru a crea cod obiect din codul de asamblare . De obicei, comutatorul -c (numai pentru compilare) este utilizat în proiecte care constau din multe fișiere.
gcc apelează apoi linkerul ld pentru a construi executabilul din fișierele obiect rezultate .
Pentru a ilustra acest proces, să creăm un fișier test.c cu următorul conținut:
int main () { asm ( "Bla-Bla-Bla" ); // introduceți o astfel de instrucțiune return 0 ; }Dacă în timpul compilării este generată avertismentul -Wimplicit-function-declaration „Declarație implicită a funcției asm”, utilizați:
__asm__ ( "Bla-Bla-Bla" );Dacă spunem execute gcc -S -o test.S test.c, atunci descoperim un fapt important: compilatorul a procesat instrucțiunea „greșită” și fișierul de asamblare rezultat test.S conține șirul nostru „Bla-Bla-Bla”. Cu toate acestea, dacă încercăm să creăm cod obiect sau să construim un fișier binar, atunci gcc va scoate următoarele:
test.c: Mesaje asamblatorului: test.c:3: Eroare: nu există o astfel de instrucțiune: „Bla-Bla-Bla”
Mesajul vine de la asamblator.
De aici rezultă o concluzie importantă: GCC nu interpretează în niciun fel conținutul inserției de asamblare, percepându-l ca o substituție macro în timp de compilare.
Structura generală a insertului de asamblare este următoarea:
asm [volatil]("comenzi și directive ale asamblatorului": parametri de ieșire: parametri de intrare: parametri modificabili);
Cu toate acestea, există și o formă mai scurtă:
asm [volatil] („instrucțiuni de asamblare”);
O caracteristică a asamblatorului de gaz și a compilatorului gcc este faptul că folosesc sintaxa AT&T , ceea ce este neobișnuit pentru x86 , care diferă semnificativ de sintaxa Intel . Principalele diferențe [1] :
Faptul de obicei ignorat că în interiorul directivei asm pot fi nu doar comenzi de asamblare, ci, în general, orice directive recunoscute de gaz, poate servi bine. De exemplu, puteți insera conținutul unui fișier binar în codul obiect rezultat:
asm ( „fișierul_de_date_noastre: \n\t ” ".incbin \" some_bin_file.txt \"\n\t " // folosiți directiva .incbin "nostru_fișier_de_date_len: \n\t " ".long .-our_data_file \n\t " // introduceți .long valoare cu lungimea fișierului calculată );Și apoi adresați acest fișier binar:
extern char fişierul_date_noastră []; extern long our_data_file_len ;Să vedem cum se întâmplă înlocuirea.
Proiecta:
asm ( "movl %0,%%eax" :: "i" ( 1 ));se va transforma in
movl $1 , %eaxCuvântul cheie volatil este folosit pentru a indica compilatorului că codul de asamblare inserat poate avea efecte secundare, astfel încât încercările de optimizare pot duce la erori logice.
Cazuri în care cuvântul cheie volatil este obligatoriu:
Să presupunem că există o inserție de asamblare în interiorul buclei care verifică utilizarea unei variabile globale și așteaptă în spinlock eliberarea acesteia. Când compilatorul începe să optimizeze bucla, aruncă totul din buclă care nu este modificat în mod explicit în buclă. Deoarece în acest caz compilatorul de optimizare nu vede o relație explicită între parametrii insertului de asamblare și variabilele care se modifică în buclă, insertul de asamblare poate fi aruncat din buclă cu toate consecințele care decurg.
SFAT: specificați întotdeauna asm volatile în cazurile în care inserția de asamblare ar trebui să fie „acolo unde este”. Acest lucru este valabil mai ales atunci când lucrați cu primitive atomice.
Următorul „moment subtil” este indicarea explicită a „memoriei” în lista clobber. Pe lângă faptul că pur și simplu îi spune compilatorului că o inserție de asamblare modifică conținutul memoriei, servește și ca directivă de barieră de memorie pentru compilator. Aceasta înseamnă că acele operațiuni de acces la memorie care sunt mai înalte în cod vor fi executate în codul mașină rezultat înaintea celor care sunt mai mici decât inserția de asamblare. În cazul unui mediu multi-threaded, când riscul unei condiții de cursă depinde direct de aceasta , această circumstanță este esențială.
SFAT #1:
O modalitate rapidă de a crea o barieră de memorie
#define mbarrier() asm volatile ("":::"memorie")SFAT #2: Specificarea „memoriei” în lista clobber nu este doar „o practică bună”, ci și în cazul lucrului cu operațiuni atomice menite să rezolve condiția de cursă, este obligatorie.