Linguaggio assembly

Assembly; linguaggio di programmazione
	Codice in Assembly per processore Motorola 6800
Data di origine	risale ai primi computer a programma memorizzato
Utilizzo	linguaggio general-purpose
Paradigmi	programmazione generica
Tipizzazione	nessuna
Estensioni comuni	.asm .s

Il linguaggio assembly, detto anche linguaggio assemblativo^[1] o linguaggio assemblatore^[2], è, tra i linguaggi di programmazione, quello più vicino al linguaggio macchina vero e proprio, pur essendo differente rispetto a quest'ultimo. Erroneamente viene spesso chiamato "assembler", ma quest'ultimo termine identifica solo il programma "assemblatore" che converte il linguaggio assembly in linguaggio macchina.

Caratteristiche generali dell'assembly

L'assembly ha lo scopo generale di consentire al programmatore di ignorare il formato binario del linguaggio macchina. Ogni codice operativo del linguaggio macchina viene sostituito, nell'assembly, da una sequenza di caratteri che lo rappresenta in forma mnemonica; per esempio, il codice operativo per la somma potrebbe essere trascritto comeADDe quello per il salto comeJMP. In secondo luogo, i dati e gli indirizzi di memoria manipolati dal programma possono essere scritti, in assembly, nella base numerica più consona al momento: esadecimale, binaria, decimale, ottale ma anche in forma simbolica, utilizzando stringhe di testo (identificatori). Il programma assembly risulta in questo modo relativamente più leggibile di quello in linguaggio macchina, con il quale mantiene però un totale (o quasi totale) isomorfismo. Il programma scritto in assembly non può essere eseguito direttamente dal processore; esso deve essere tradotto nel linguaggio macchina (binario) corrispondente, usando un programma compilatore detto assembler.

Non univocità dell'assembly

A causa di questa "vicinanza" all'hardware, non esiste un unico linguaggio assembly. Al contrario, ogni CPU o famiglia di CPU ha un suo proprio assembly, diverso dagli altri. Ad esempio, sono linguaggi assembly ben diversi quelli per i processori Intel x86, per i Motorola 68000 e per i Dec Alpha. Questo significa che conoscere un certo linguaggio assembly significa saper scrivere programmi solo su una determinata CPU o famiglia di CPU. Passare ad altre CPU però è relativamente facile, perché molti meccanismi sono analoghi o del tutto identici, quindi spesso il passaggio si limita all'apprendimento di nuovi codici mnemonici, nuove modalità di indirizzamento ed altre varie peculiarità del nuovo processore.

Molto meno facile è invece portare un programma scritto in assembly su macchine con processori diversi o con architetture diverse: quasi sempre significa dover riscrivere il programma da cima a fondo, perché i linguaggi assembly dipendono completamente dalla piattaforma per cui sono stati scritti. Molti compilatori assembly supportano sistemi di macro che potrebbero essere impiegati per ovviare in parte a questo problema, ma si tratta di una soluzione poco efficace.

Inoltre l'assembly non offre alcun "controllo sui tipi" (non esiste alcunché di vagamente simile al concetto di "tipo" nella programmazione low-level), ma lascia al programmatore la responsabilità di occuparsi di ogni singolo dettaglio della gestione della macchina e richiede molta disciplina e un esteso lavoro di commento per non scrivere codice che risulti assolutamente illeggibile (ad altri programmatori come anche a se stessi dopo qualche tempo).

A fronte di questi svantaggi l'assembly offre un'efficienza senza pari e il controllo completo e assoluto sull'hardware: i programmi in assembly sono, in linea di principio, i più piccoli e veloci che sia possibile scrivere su una data macchina.

Scrivere (buon) codice in assembly è dispendioso in termini di tempo, difficile e quindi molto costoso, soprattutto in prospettiva (future modifiche): per questo, raramente l'assembly è il solo linguaggio usato in un progetto mainstream, a meno che questo non sia di dimensioni e portata limitate. In genere si usa in combinazione con altri linguaggi: la maggior parte del codice viene scritta in un linguaggio ad alto livello, mentre le parti più critiche (per motivi di performance, precisione del timing o affidabilità) si scrivono in assembly.

Tali problematiche sono riscontrabili principalmente su piattaforme come i personal computer attuali, dove la vastità quantitativa e l'enorme gamma qualitativa dell'hardware disponibile crea alle applicazioni low-level un oggettivo problema mai risolto (e presumibilmente non risolvibile) a livello di unificazione e standard. A ciò si aggiunga l'evoluzione costante verso una sempre maggiore stratificazione dei comuni sistemi operativi, caratterizzata da numerosi vincoli e virtualizzazioni delle periferiche fisiche e dei canali di comunicazione, che non rendono agevole lo sviluppo di un software che interagisca direttamente con l'hardware sottostante e ne gestisca direttamente le caratteristiche.

Si possono però citare due esempi, peraltro correlati, di totale inversione di questo paradigma generale:

Ha ampiamente senso creare programmi interamente in assembly destinati ad hardware caratterizzato architetturalmente da documentazione esaustiva, grande predicibilità, stabilità e scarsa variabilità temporale del design: per esempio, si possono citare gli home computer degli anni ottanta, come i Commodore Vic-20 e C64 o il Sinclair ZX Spectrum.
Ha parimenti senso, ed un forte riscontro nella pratica invalsa negli ultimi trenta anni, operare prevalentemente o esclusivamente in assembly nel vastissimo mercato dei sistemi embedded, per la programmazione di microcontroller e DSP, eventualmente anche sotto forma di core implementati tramite ASIC, CPLD ed FPGA, al fine di massimizzare performance e rispetto dei vincoli temporali, minimizzando nel contempo il footprint. Ciò trova riscontro a tutti i livelli della filiera produttiva, a partire dalla progettazione dei chip e del relativo linguaggio utilizzando ISA di tipo RISC e fortemente ortogonali, la cui ottimizzazione (in spazio o in performance) è altamente semplificata. Questo approccio è fondamentale in quanto consente grandi economie di scala nei progetti tipici del mondo embedded, caratterizzati dalla capacità di assorbire costi iniziali (NRE, non-recurrent engineering costs) anche elevati, purché finalizzati ad una forte compressione del costo unitario del prodotto finale, anche per volumi medio-bassi.

Ecco allora che la possibilità di utilizzare un microcontroller con limitatissime risorse di memoria ROM e RAM scrivendo il firmware integralmente in assembly diventa essenziale al fine di minimizzare i costi, l'ingombro in piastra, la suscettibilità elettromagnetica, aumentando anche l'affidabilità (processori più "datati" hanno un incolmabile vantaggio in termini di milioni di ore di test e funzionamento sul campo, ossia la "merce" di gran lunga più preziosa per i sistemi embedded variamente critici) ed ottimizzando numerosi altri fattori.

RISC e CISC

Il linguaggio assembly costituisce il cosiddetto ISA (Instruction Set Architecture) di un processore. I diversi ISA possono essere divisi in due grandi gruppi: i RISC (Reduced Instruction Set Computer) e i CISC (Complex Instruction Set Computer). Il primo gruppo tende ad avere operazioni semplici e veloci, con grande abbondanza di registri per memorizzare i risultati intermedi. Il secondo mette a disposizione del programmatore istruzioni più complesse, che a volte mimano quelle dei linguaggi di livello più alto (ad esempio, la copia di stringhe nei processori x86). In entrambi i casi, i migliori set di istruzioni tendono ad essere quelli cosiddetti ortogonali, dove i diversi metodi di indirizzamento e i diversi registri possono essere usati indifferentemente in tutte le istruzioni. Famosi set di istruzioni ortogonali sono quelli del Motorola 68000 (CISC) e del MIPS (RISC). L'ISA dei processori Intel x86 era originariamente ben poco ortogonale, ed è andata via via migliorando.

La distinzione tra set di istruzioni RISC e CISC è oggi un po' sfumata, perché la maggior parte dei processori consumer sono oggi dei CRISP, cioè un misto fra i due. Inoltre, alcuni processori traducono l'ISA originale in un set di istruzioni interno, per ragioni diverse e con modalità diverse:

nel caso dell'Intel Pentium 4 e dell'AMD Athlon, è per liberarsi dalle limitazioni causate da un'ISA retrocompatibile ormai arcaica, e la conversione è eseguita direttamente da hardware dedicato che effettua la necessaria decodifica;
nel caso dei processori Transmeta, è per poter "tradurre" ISA di altri processori esistenti come se fossero proprie, e la traduzione è fatta da qualcosa di concettualmente molto simile a routine firmware (denominate microcodice) memorizzate in un'area ROM ricavata sul silicio del microprocessore.

Struttura

La struttura di un tipico listato Assembly x86 per PC si articola, a grandi linee, nei seguenti termini:

intestazione, in cui possiamo inserire, tramite dei commenti, il nome e la funzione del programma.
segmento dati, in cui andiamo a dichiarare formalmente le variabili usate dal programma (in pratica allochiamo delle zone di memoria nel segmento puntanto dal DS data segment)
segmento di stack, in cui definiamo la struttura dello stack associato al programma (parleremo dello stack in seguito)
segmento di codice, in cui è presente il codice del programma
chiusura

Vale la pena di ribadire che tale struttura, nella sua generalità, dipende quasi per intero dalla piattaforma e anche dall'assembler utilizzato e quindi non è in alcun modo universalizzabile. Architetture diverse, dai mainframe ai microcontroller, con relativi assemblatori e cross-assembler, impongono strutture di sorgente a volte nettamente diverse dal semplice esempio illustrato, relativo ai comuni PC. Per un controesempio banale, nelle architetture Harvard usate dalla quasi totalità dei microcontroller e da molte architetture di supercalcolo:

il segmento di codice non risulta scrivibile durante la normale elaborazione: ne consegue, tra l'altro, l'assoluta impossibilità di creare codice self-morphing (automodificante), ma anche un modo generalmente diverso di referenziare variabili (a rigore, label corrispondenti ad una o più locazioni in memoria dati) e codice nel sorgente;
i dati a loro volta risiedono in memorie fisicamente separate, talora dotate anche di persistenza tra le sessioni (EPROM, Flash EEPROM, RAM "tamponate" ossia dotate di batteria di backup...), e tutto ciò si riflette in modo esplicito e pervasivo nella sintassi supportata dall'assembler, nelle direttive specifiche e nella struttura effettiva di un sorgente Assembly;
ultimo, ma non meno importante: registri come DS e SS (stack segment) sono altre peculiarità della piattaforma x86, sovente lo stack di chiamata non è neppure direttamente accessibile nei core MCU più diffusi.

Esempio di codice

Esempio di programma "Hello world" in assembly Intel x86 con sintassi Intel (sfrutta le chiamate al sistema operativo DOS). Non è compatibile con le versioni Assembly UNIX GNU

MODEL SMALL
STACK 100H
.DATA
    HW      DB      "hello, world", 13, 10, '$'
.CODE
.STARTUP
    MOV AX, @data
    MOV DS, AX
    MOV DX, OFFSET HW
    MOV AH, 09H
    INT 21H
    MOV AX, 4C00H
    INT 21H
END

Questo invece è l'esempio del programma scritto per sintassi AT&T (per le architetture UNIX GNU)

.section .data

	hello:
		.ascii "ciao ciao mondo!\n"

	hello_len:
		.long . -hello	# lunghezza della stringa in byte

.section .text

	.global _start

_start:
	movl $4, %eax		# 4 corrisponde alla system call "write"
	movl $1, %ebx		# stampa nello standard output (schermo)
	leal hello, %ecx	# puntatore char a ciò che si vuole stampare
	
	movl hello_len, %edx	# copia del contenuto della variabile. carica la lunghezza della variabile

	int $0x80		# system call  (int sarebbe "interrupt"); con 0x80 si lancia una interaction generale 
                                # dichiarata (in base ai valori caricati precedentemente nei registri)
				
	movl $1, %eax		# 1 corrisponde alla system call "exit"

	xorl %ebx, %ebx		#azzera EBX; si può anche scrivere movl $0, %ebx ma risulta meno efficiente

	int $0x80

Microistruzioni

Quando si esegue un'istruzione Assembly, il processore (in base all'architettura presa in considerazione) esegue una serie di operazioni chiamate "Microistruzioni Assembly", cioè delle operazioni hardware che servono per configurare i registri e gli operatori della CPU in modo che possa essere eseguita quella istruzione.

Tale processo si divide, nel caso delle CPU Intel x86 e di alcune altre, in 3 parti:

Fetch: fase di caricamento in cui si incrementa il registro PC e si prepara la CPU a compiere l'operazione;
Decode: si configurano i multiplexer interni alla CPU e viene eseguita una codifica dell'istruzione qualora sia necessario (indirizzamenti indiretti, a spiazzamento, ecc...)
Execute: il momento in cui si esegue veramente l'operazione

Da qui la sigla FDE, Fetch-Decode-Execute, riportata nei testi di architettura e nei datasheet.

Per fare un esempio per l'architettura dell'Intel 80x86 con un singolo BUS, in sintassi AT&T, questa istruzione:

ADD %EBX, %EAX

in cui si somma il contenuto del registro EAX con il contenuto del registro EBX e il risultato verrà salvato in EAX, vengono svolte queste microoperazioni:

1. PCout, SELECT[4], ADD, Zin, MARin, READ   ;viene incrementato il PC per eseguire l'operazione successiva
2. Zout, PCin, WMFC                          ;si aspetta che sia avvenuta la lettura in memoria
3. MDRout, IRin                              ;viene inviata l'istruzione prossima in IR
4. EAXout, Vin                               ;viene inviato il contenuto di EAX in un registro temporaneo
5. EBXout, SELECT[V], ADD, Zin               ;viene sommato il contenuto di EBX tramite la ALU con EAX
6. Zout, EAXin, END                          ;il risultato viene copiato in EAX

Su alcune architetture tali fasi risultano invece essere quattro (ad esempio, nei PIC Microchip, negli Intel 8051 e in numerosissimi core analoghi), da cui risulta anche l'effettivo rapporto tra velocità di clock ossia frequenza del quarzo esterno (es. 10 MHz) e numero di istruzioni effettivamente eseguite in un secondo. Per i PIC (famiglie baseline e midrange in particolare) tale rapporto è pari ad 1/4, poiché ad ogni ciclo di clock il core esegue effettivamente una singola fase Fetch-Decode-Execute-Write e dunque sono necessari quattro cicli del clock esterno per completare una singola istruzione. Su architetture di microcontroller e core più arcaiche o comunque di diversa concezione, sono necessari anche più cicli di clock per ciascuna fase (ad esempio tre o quattro), da cui il diverso rapporto tra clock e MIPS, che nel caso del design 8051 originale richiede ad esempio 12 cicli di clock per ciascuna singola istruzione. Si ricordi infine che talune istruzioni, tra le quali tipicamente i salti incondizionati, richiedono su un numero notevole di piattaforme (sia RISC che CISC, concepite in varie epoche) un numero di cicli superiore alle altre, a causa delle operazioni accessorie (non parallelizzabili) richieste dall'aggiornamento del registro IP e di eventuali code di prefetch interne.

C-asm

Talvolta, nella programmazione ad alto livello in ambienti come il DOS, c'è la necessità di effettuare alcune operazioni che sono molto più veloci usando delle istruzioni di linguaggi a basso livello (in Windows invece a causa delle protezioni della memoria si ricorre più frequentemente alle chiamate WINAPI, le chiamate in L/M sono usate per lo più per procedure matematiche accelerate o dai driver). Tra i linguaggi ad alto livello che permettono questo vi sono il C e il C++, in cui possono essere inserite nei propri sorgenti parti scritte in assembly che, in fase di compilazione, verranno tradotte con un procedimento noto come assembler inline. Un esempio di codice scritto in C-asm (usando l'assembly Intel x86), che visualizza in binario un numero dato in input, è il seguente:

#include <stdio.h>
#include <iostream.h>
#include <[[conio.h]]>
int main() 
{
    int a;

    /* Acquisizione del valore numerico */
    printf("Inserisci un valore compreso tra -32768 e 32768: "); 
    scanf("%d", &a);

    /* Visualizzazione del messaggio di risposta */
    printf("Il valore corrispondente in binario è: "); 
    
    /* Keyword per delimitare le sezioni di codice Assembly */
    asm 
    { 
        /* Visualizzazione della stringa di bit corrispondente */
        MOV BX,WORD PTR a
        MOV CX,00Ah
    }

    /* Etichetta esterna */
    Ciclo: 
        asm
        {
            /* Estrazione di un bit */
            MOV DL,00H
            RCL BX,1   /* Il valore del bit viene posto nel flag di carry */
            ADC DL,'0' /* Determino il carattere da visualizzare */
            MOV AH,02H /* Visualizzazione */
            INT 21h
            Loop Ciclo
        } 
    return 0;
}

Per la maggioranza delle applicazioni mainstream, è ormai convinzione comune nella comunità dei programmatori applicativi che fattori come le ottimizzazioni generate automaticamente dai compilatori nei linguaggi di più elevato livello, l'evoluzione di librerie a loro volta sempre più ottimizzate (almeno in linea di principio) e la sempre maggiore potenza elaborativa delle piattaforme comunemente diffuse rendano meno necessario rispetto al passato il ricorso alla verticalizzazione tramite assembly inline o moduli assembly, anche in favore della portabilità e leggibilità del codice. Tuttavia, non mancano numerose eccezioni in totale controtendenza rispetto a tale diffusa concezione: in particolare nel mondo dei sistemi dedicati, basato quasi per definizione su un paradigma ben diverso, come ricordato al paragrafo "Non c'è un solo assembly", ma anche in numerose nicchie specialistiche ai margini del mainstream, dai sistemi CAD/CAM al calcolo numerico, alle applicazioni scientifiche di varia natura, fino allo sviluppo di driver e altro software di sistema.

Strutture di controllo in Assembly x86

Il processore esegue le istruzioni così come si presentano, una dopo l'altra. Tuttavia, attraverso particolari strutture, si può controllare il flusso esecutivo in base ad una determinata condizione. In questo modo si può creare strutture di semplice selezione o di tipo iterativo (cicli). Le istruzioni assembly che vengono utilizzate per questo scopo sono principalmente di due tipo: salto e confronto.

I salti possono essere incondizionati o condizionati. JMP effettua un salto incondizionato. In genere l'indirizzo di riferimento è un'etichetta. La condizione del salto è sempre dettata dai valori del registro dei flag. I flag più usati per i salti sono:

ZF (flag zero) indica se l'ultima istruzione ha generato come risultato 0
SF (flag segno) indica se l'ultima istruzione ha generato un risultato di segno negativo
OF (flag overflow) indica se l'ultima istruzione ha generato un overflow (con troncamento del bit più significativo del risultato)

Il costrutto di selezione (if, else)

La selezione è una struttura che permette di eseguire un blocco di istruzioni oppure un altro in base al verificarsi di una condizione.

 se
     blocco istruzioni 1
 altrimenti
    blocco istruzioni 2
 fine se

in assembly, attraverso la logica dei salti, viene rappresentato così:

 se:
   JNcondizione altrimenti
   blocco istruzioni 1
   JMP fine_se
 altrimenti:
   blocco istruzioni 2
 fine_se:

Il ciclo a controllo in coda (do...while)

L'iterazione è una struttura che permette di ripetere più volte un'istruzione sotto il controllo di una condizione.

 ripeti
     istruzioni
 finché condizione

in assembly, attraverso la logica dei salti, viene rappresentato così:

 inizio_ciclo:
   istruzioni
 Jcondizione inizio_ciclo

esempio:

 MOV AX, 0000h
 inizio_ciclo:
   INC AX
   CMP AX, 000Ah    ;confronta AX e il valore 0Ah (10d)
 JNE inizio_ciclo     ;salta all'inizio (e ripete il ciclo) se diverso

Dato che il controllo della condizione viene eseguito alla fine del ciclo, le istruzioni in sequenza vengono eseguite comunque almeno una volta, anche se la condizione era già verificata in partenza. In pratica:

 MOV AX, 000Ah
 inizio_ciclo:
   INC AX
   CMP AX, 000Ah
 JNE inizio_ciclo

Questo spezzone di codice dovrebbe controllore se AX = 10d, e in caso contrario incrementare AX. In caso favorevole uscire dal ciclo. Vediamo però che AX vale già 10d, tuttavia tale registro viene comunque incrementato (alla fine varrà 000Bh). Inoltre, in questo particolare programma, il ciclo non finirà mai: AX varrà 11, poi 12, poi 13 e non diventerà mai uguale a 10. Sarebbe buona norma, nelle condizioni, evitare di esprimere un'uguaglianza:

  MOV AX, 000Ah
  inizio_ciclo:
    INC AX
    CMP AX, 000Ah
  JB inizio_ciclo                     ; salta se minore (invece di salta se non uguale)

In questo modo abbiamo risolto il problema del ciclo infinito. Tuttavia, a causa del fatto che la sequenza viene eseguita almeno una volta, in genere si evita il ciclo a controllo in coda e si utilizza invece quello a controllo in testa.

Il ciclo a controllo in testa (while)

Una struttura iterativa a controllo in testa si può descrivere, ad alto livello, così:

 mentre condizione
   istruzioni
 fine ciclo

Equivale alla while (condizione) { sequenza } del C. in assembly:

 inizio_ciclo:
   JNcondizione fine_ciclo
       sequenza
   JMP inizio_ciclo
 fine_ciclo

esempio:

 inizio_ciclo:
   CMP AX,0Ah            ;confronta AX con 10d
   JNE fine_ciclo        ;salta se diverso
       INC AX            ;incrementa AX
   JMP inizio_ciclo
 fine_ciclo

La differenza tra questa struttura e quella a controllo in coda sta nel fatto che se la condizione è inizialmente verificata, la sequenza di istruzioni non viene eseguita nemmeno una volta.

Il ciclo a contatore (for)

Il ciclo a contatore ha una struttura di questo tipo:

 CONTATORE = 0
 mentre CONTATORE < N
   sequenza
   incrementa CONTATORE
 fine ciclo

Possiamo utilizzare un ciclo a contatore se vogliamo ripetere un blocco di istruzioni per un numero di volte noto a priori. i cicli in assembly sono in genere a decremento:

 CONTATORE = N
 ripeti
   sequenza
   decrementa CONTATORE
 finché CONTATORE n > 0

Come contatore si usa di solito il registro CX (registro contatore, appunto), perché esiste un'istruzione che esegue le ultime due istruzioni automaticamente: l'istruzione LOOP: decrementa CX e, se CX non è 0, salta all'etichetta specificata.

 MOV CX, 0
 inizio_ciclo:
   CMP CX, N
   JGE fine_ciclo
   sequenza
 JMP inizio_ciclo
 fine_ciclo:

Grazie all'istruzione LOOP diventa semplice scrivere un ciclo a contatore in assembly:

 MOV CX, <N>            ; dove N è il numero di ripetizioni da eseguire
 inizio_ciclo:
   sequenza
 LOOP inizio_ciclo

Va sottolineato che nel primo esempio si ha un ciclo a controllo in testa, mentre nel secondo uno a controllo in coda, e che, sebbene il secondo sia più compatto e veloce da scrivere, possa generare degli errori, come già detto sopra, se non si sta attenti a come lo si usa, infatti in esso le istruzioni vengono eseguite almeno una volta, per cui se non si è sicuri che il numero di ripetizioni non possa mai essere zero, è meno rischioso usare il primo.

L'input/output tramite l'INT 21h del DOS

L'assembly, specialmente nel mondo dei PC, non prevede funzioni di input/output già pronte. Il programmatore deve quindi creare le proprie routine o appoggiarsi a quelle create da terze parti. Negli ambienti DOS è sufficiente porre il codice del servizio richiesto in AX ed usare l'istruzione INT 21h per richiamare il relativo software interrupt, una delle caratteristiche più peculiari delle CPU Intel x86. Tra le funzioni più comuni per l'input/output da tastiera:

servizio 01h==> Acquisizione di un carattere da tastiera con eco sul video. Attende la pressione di un tasto e restituisce il codice ASCII del tasto premuto
servizio 02h ==> Visualizzazione di un carattere a video. Stampa il carattere il cui codice ASCII è contenuto in DL
servizio 07h ==> Acquisizione di un carattere da tastiera senza eco sul video. Come il servizio 01h, ma non visualizza il carattere sullo schermo
servizio 09h ==> Visualizzazione di una stringa a video. Stampa la stringa a cui punta l'indirizzo di memoria contenuto in DX
servizio 4Ch ==> Servizio di ritorno al sistema operativo. Consente di terminare il programma.

Quindi, per acquisire un carattere (con eco sul video):

 MOV AH, 01h    ; servizio 01h
 INT 21h         ; se AX=0001h, allora in AL va il codice ASCII del tasto premuto

E volendo poi stamparlo:

 MOV DL,AL       ; copio il codice ASCII del tasto letto il DL
 MOV AH,02h    ; servizio 02h
 INT 21h         ; se AX=0002h, allora stampa il carattere di codice ASCII in D

Come si può vedere, sia le operazioni di acquisizione che di stampa fanno rifemento ai codici di carattere ASCII. Nel caso si voglia leggere in input una cifra numerica, per risalire al valore numerico basta sottrarre il valore 30h (48 in decimale) al suo codice ASCII. Infatti 30h in ASCII corrisponde al carattere "0", 31h (49 in decimale) all'"1" e così via...

Nel caso in cui si voglia stampare una stringa:

 stringa DB 13,10,"questa è una stringa","$" ;alloco una variabile da un byte che chiamo stringa e in cui ci salvo una sequenza di caratteri(una stringa appunto)
 LEA DX,stringa ;copio l'indirizzo di memoria che punta alla stringa in DX
 MOV AH,09h    ; servizio 09h
 INT 21h         ; se AX=0009h, allora stampa la stringa a cui punta l'indirizzo di memoria contenuto in DX

Assembly x86

Assembly x86 è una famiglia di linguaggi Assembly, usati per creare codici oggetto per i processori Intel X86. Come tutti i linguaggi assembly, sfrutta brevi parole per realizzare le istruzioni per la CPU.

Note

^ Tanenbaum 2006
^ linguaggio assemblatore, in Treccani.it – Enciclopedie on line, Roma, Istituto dell'Enciclopedia Italiana.

Bibliografia

Andrew Stuart Tanenbaum, Livello del linguaggio assemblativo, in Architettura dei calcolatori. Un approccio strutturale, Milano, Pearson Education, 2006, pp. 491-528, ISBN 978-88-7192-271-3.
Randall Hyde, The Art of Assembly Language, No Starch Press, 2010, ISBN 978-1-59327-301-9.

Voci correlate

Altri progetti

Wikibooks contiene testi o manuali sull'linguaggio assembly
Wikimedia Commons contiene immagini o altri file su linguaggio assembly

Collegamenti esterni

Guida Linguaggio Assembly MIPS/SPIM Architetture R2000/R3000
Imparare l'Assembly con Visual C++
(EN, IT, FR, ES, DE, ZH) PC Assembly Language, tutorial di Paul Carter sull'assembly x86
Intel x86 programming

Controllo di autorità	Thesaurus BNCF 45031 · LCCN (EN) sh85008765 · GND (DE) 4003255-3 · BNF (FR) cb11961749m (data) · J9U (EN, HE) 987007408650105171

Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica

[1] Tanenbaum 2006

[2] uaggio assemblatore, in Treccani.it – Enciclopedie on line, Roma, Istituto dell'Enciclopedia Italiana.

[1]

[2]