Ambiente di sviluppo

In questo corso, programmeremo assembler per architettura x86, a 32 bit. Useremo la sintassi GAS (anche nota come AT&T), usando la linea di comando in un sistema Linux. Utilizzeremo degli script appositi per assemblare, testare e debuggare. Questi script non fanno che chiamare, semplificandone l'uso, gcc e gdb.

Attenzione all'architettura

Programmare in assembler vuol dire programmare per una specifica architettura di processori. L'architettura x86 è stata rimpiazzata nel tempo da x64, a 64 bit, ma è del tutto retrocompatibile (ci limitiamo a x86 perché tanto ci basta ai fini didattici). Usare una macchina con architettura diversa (in particolare, ARM) è inevitabilmente fonte di problemi.

Da una parte, si potrebbe pensare di esercitarsi scrivendo assembler per la propria architettura, anziché quella usata nel corso. Sorgono diversi problemi: dover imparare sintassi, meccanismi, registri completamente diversi; dover fare a meno o reingegnerizzarsi la libreria usata per l'input-output a terminale; dover comunque imparare l'assembler mostrato nel corso perché quella sarà richiesta all'esame e supportata dalle macchine in laboratorio.

La seconda opzione è usare strumenti di virtuallizzazione capaci di far girare un sistema operativo con architettura diversa. Sorge come principale problema l'ergonomicità ed efficienza di questa soluzione, che dipende molto dagli strumenti che si trovano e dalle caratteristiche hardware della macchina, che potrebbero essere non sufficienti.

Tenere comunque presente che, per i programmi che intendiamo scrivere, basta una macchina x86 molto poco potente.

Struttura dell'ambiente

I programmi che scriveremo ed eseguiremo, così come quelli utilizzati per assemblare, gireranno in un terminale Linux.

Perché Linux?

Questo perché è molto più facile virtualizzare un ambiente Linux moderno in Windows o Mac che il contrario. In precedenza si usava MS-DOS, un sistema del 1981 facilmente emulabile, ma molto limitato data l'età.

Nell'ambiente d'esame, si usa un Ubuntu 22.04 virtualizzato tramite WSL su macchina Windows 11. Come editor usiamo Visual Studio Code con l'estensione per lo sviluppo in WSL.

Schema dell'ambiente usato all'esame.

Questo ci permette di mantenere un ambiente grafico moderno mentre si lavora con un terminare Linux virtualizzato. È anche relativamente facile da riprodurre in altri contesti, utilizzando altre forme di visualizzazione e SSH.

Tra i file del corso (Teams o sito web) trovate il pacchetto di installazione con le istruzioni passo-passo per riprodurre l'ambiente del laboratorio su una macchina Windows 11 con architettura x86: questo perché è pensata e testata per le macchine in laboratorio usate per l'esame.

Le stesse istruzioni possono essere adattate per riprodurre un ambiente funzionale in un contesto diverso.

Schema di un ambiente che usa SSH.

Requisiti minimi

L'ambiente Linux deve essere in grado di

• Eseguire gli script powershell dell'ambiente
• Assemblare, usando gcc, programmi x86 scritti con sintassi GAS
• Eseguire programmi x86
• Debuggarli usando gdb

Su Ubuntu 22.04, i pacchetti da installare sono

• build-essential
• gcc-multilib
• gdb
• powershell (guida)

Perché Powershell?

Perché Powershell (2006) è object-oriented, e permette di scrivere script leggibili e manutenibili, in modo semplice. Bash (1989) è invece text-oriented, con una lunga lista di trappole da saper evitare.

Lanciare l'ambiente e primo programma

Una volta eseguiti i passi dell'installazione, avremo una cartella C:/reti_logiche con contenuto come da figura.

Il file assembler.code-workspace lancerà VS Code, collegandosi alla macchina virtuale WSL e la cartella di lavoro C:/reti_logiche/assembler.

informazioni

Questo file è configurato per l'ambiente d'esame, per automatizzare l'avvio. Se si usa un ambiente diverso, il file andrà modificato di conseguenza per funzionare, o si dovrà avviare l'ambiente "manualmente".

La finestra VS Code che si aprirà sarà simile alla seguente.

Nell'angolo in basso a sinistra, WSL: Ubuntu-22.04 sta a indicare che l'editor è correttamente connesso alla macchina virtuale (compare una dicitura simile se si usa SSH).

I file e cartelle mostrati nell'immagine sono quelli che ci si deve aspettare dall'ambiente vuoto.

Il file test-ambiente.s è un semplice programma per verificare che l'ambiente funzioni.

.include "./files/utility.s"

.data
messaggio: .ascii "Ok.\r"

.text
_main:  
   nop
   lea messaggio, %ebx
   call outline
   ret

Apriamo quindi un terminale in VS Code (Terminale > Nuovo Terminale). Per poter lanciare gli script, il terminale deve essere Powershell, non bash.

Per cambiare shell si può usare il bottone + sulla sinistra, o lanciare il comando pwsh senza argomenti.

informazioni

Se si preferisce, in VS Code si può aprire un terminale anche come tab dell'editor, o spostandolo al lato anziché in basso.

A questo punto possiamo lanciare il comando per assemblare il programma di test.

./assemble.ps1 ./test-ambiente.s

Dovremmo adesso vedere, tra i file, il binario test-ambiente. Lo possiamo eseguire con ./test-ambiente, che dovrebbe stampare Ok..