1. Introduzione all’Interfaccia Hardware-Software

L’interazione SW e HW rappresenta il substrato fondamentale di qualsiasi sistema di elaborazione, definendo il confine dove le astrazioni logiche algoritmiche si traducono in segnali elettronici fisici e transizioni di stato nei registri.
Questa relazione non è semplicemente una gerarchia statica, ma un dialogo dinamico governato da contratti rigorosi:

• l’Instruction Set Architecture (ISA) ,
• l’Application Binary Interface (ABI) ,
• I meccanismi di gestione delle eccezioni .

La presente relazione tecnica offre un’analisi esaustiva di queste interazioni, focalizzandosi sulle architetture predominanti nel panorama embedded e general-purpose odierno: RISC-V, MIPS32, ARM (specificamente la serie Cortex-M utilizzata nei microcontrollori STM32) e x86 (Intel).

L’obiettivo è decostruire i meccanismi che permettono a sistemi operativi complessi, siano essi Real-Time Operating Systems(RTOS) come ChibiOS e FreeRTOS o kernel monolitici come Linux, di operare su piattaforme hardware eterogenee quali STM32, PIC32, ESP32, Raspberry Pi e BeagleBone Black. Attraverso l’analisi di simulatori didattici come MARS e implementazioni hardware reali, verrà dimostrato come le scelte progettuali a livello di silicio – dalla gestione della pipeline alla segmentazione della memoria – impongano vincoli stringenti allo sviluppo software .

2. Paradigmi Architetturali e Instruction Set Architecture (ISA)

L’ISA costituisce l’interfaccia visibile al programmatore e al compilatore, dettando le regole di ingaggio con l’hardware. Le architetture prese in esame rappresentano filosofie progettuali distinte che influenzano direttamente l’efficienza del codice, la densità delle istruzioni e la complessità del compilatore.

2.1) MIPS32: L’Archetipo RISC e la Gestione della Pipeline

L’architettura MIPS32 (Microprocessor without Interlocked Pipelined Stages) incarna la filosofia RISC (Reduced Instruction Set Computer) nella sua forma più pura, focalizzandosi su un set di istruzioni semplificato per massimizzare la frequenza di clock e l’efficienza della pipeline.

2.1.1) Il File dei Registri e la Filosofia del Registro Zero

• File Register : MIPS32 impiega un banco di 32 registri general-purpose a 32 bit ($0–$31).
• Registro Zero : Una caratteristica architetturale distintiva è il registro $0 (zero), cablato rigidamente al valore logico 0 . Questa scelta progettuale non è banale: permette di sintetizzare istruzioni complesse utilizzando opcode di base.
  • Ad esempio, l’operazione di copia tra registri (move $d, $s) non esiste come opcode nativo, ma è implementata come un’addizione con zero (add $d, $s, $0). Questo riduce la complessità del decoder hardware, liberando area di silicio per altre ottimizzazioni.

2.1.2) Pipeline e Branch Delay Slot

Nelle prime implementazioni MIPS, e simulate fedelmente nell’ambiente MARS, l’architettura esponeva al software i pericoli della pipeline (pipeline hazards). Un artefatto critico di questa esposizione è il “Branch Delay Slot”: l’istruzione immediatamente successiva a un salto condizionato o incondizionato viene eseguita indipendentemente dall’esito del salto stesso. Questo meccanismo, nato per evitare stalli nella pipeline mentre l’unità di fetch calcolava il nuovo indirizzo, obbliga il compilatore o l’assembler a inserire istruzioni utili (o NOP) in questo slot. Sebbene le moderne implementazioni MIPS (come la MIPS32 Release 6) abbiano introdotto rami compatti senza delay slot, la comprensione di questo meccanismo è essenziale per l’analisi del codice legacy e per l’ottimizzazione manuale in assembly su piattaforme come il PIC32.

2.2) ARM Cortex-M (STM32): Efficienza Compressa e Architettura Harvard

L’architettura ARM, in particolare il profilo Cortex-M utilizzato nella famiglia STM32 di STMicroelectronics, rappresenta un’evoluzione del modello RISC ottimizzata per il mercato embedded, dove la densità del codice e il determinismo sono prioritari rispetto al puro throughput.

2.2.1) Thumb-2 e Densità del Codice

• A differenza del formato fisso a 32 bit di MIPS, i core Cortex-M eseguono prevalentemente il set di istruzioni Thumb-2, un mix ibrido di istruzioni a 16 e 32 bit.
• Questa architettura a lunghezza variabile permette di ridurre significativamente l’occupazione di memoria flash, un parametro critico nei microcontrollori.
• Il processore decomprime le istruzioni nello stadio di fetch senza penalità di ciclo, mantenendo le prestazioni di un set a 32 bit con la densità di uno a 16 bit. Tuttavia, ciò introduce complessità nella decodifica e rende l’allineamento del codice meno prevedibile rispetto a MIPS2 .

2.2.2) Il Program Counter come Registro Generale

ARM espone il Program Counter (PC) come registro R15 all’interno del banco dei 16 registri core (R0-R15). Questa caratteristica permette tecniche di programmazione avanzate, come il caricamento di costanti direttamente dal flusso di istruzioni (Literal Pools) accessibili via offset relativo al PC. Tuttavia, l’uso improprio di R15 in operazioni aritmetiche può causare salti imprevedibili o disallineamenti, dato che il bit meno significativo (LSB) dell’indirizzo di salto in Thumb-2 deve essere impostato a 1 per indicare lo stato Thumb; un LSB a 0 causerebbe un tentativo di switch allo stato ARM (non supportato su Cortex-M), generando un Fault.6

2.3) RISC-V: Modularità e Separazione dei Privilegi

RISC-V si distingue per essere un’architettura ISA aperta e modulare, libera dai debiti tecnici delle architetture proprietarie. La sua struttura è definita da un set base (RV32I) estendibile con moduli opzionali (M per Moltiplicazione, A per Atomiche, F per Floating Point, C per Compresso).

2.3.1) Livelli di Privilegio Rigorosi

RISC-V definisce una gerarchia di privilegi hardware-enforced: Machine Mode (M-mode), Supervisor Mode (S-mode) e User Mode (U-mode).

• M-mode: È il livello più alto, obbligatorio per tutte le implementazioni, con accesso completo alle risorse hardware. È qui che risiede il firmware di basso livello o l’implementazione di un RTOS bare-metal.
  
• S-mode: Progettato per ospitare sistemi operativi “ricchi” come Linux, supporta la memoria virtuale e la gestione delle pagine.
  
• U-mode: Il livello a privilegi minimi per le applicazioni utente. Questa separazione netta, gestita tramite registri CSR (Control and Status Registers) dedicati come mstatus e mideleg, facilita l’implementazione di kernel sicuri e la virtualizzazione, permettendo al processore di delegare trap e interrupt direttamente al livello S senza passare per il livello M, riducendo l’overhead di contesto.
  

2.3.2) Gestione CSR vs General Purpose

A differenza di MIPS, dove i registri di controllo (CP0) sono spesso accessibili muovendo dati tra essi e i registri generali, RISC-V utilizza uno spazio di indirizzamento separato a 12 bit per i CSR, accessibili solo tramite istruzioni atomiche dedicate (csrrw, csrrs, csrrc). Questo disaccoppia lo stato del sistema dal flusso di calcolo dei dati, semplificando la progettazione di pipeline superscalari e out-of-order execution, poiché le dipendenze tra stato di controllo e dati sono esplicite.

2.4) x86-64 (Intel): L’Eredità CISC

L’architettura x86, dominante nei personal computer e server (es. Core i7), rappresenta l’approccio CISC (Complex Instruction Set Computer).

2.4.1) Decodifica e Register Renaming

Nonostante l’ISA x86 esponga istruzioni complesse di lunghezza variabile (da 1 a 15 byte) e operazioni aritmetiche dirette in memoria (es. ADD, RBX), i moderni processori Intel operano internamente come macchine RISC. Un decoder front-end traduce le macro-istruzioni x86 in sequenze di micro-operazioni (uOps) più semplici. Inoltre, sebbene l’ISA a 64 bit esponga 16 registri (RAX, RBX,… R15), l’hardware sottostante utilizza centinaia di registri fisici tramite il “Register Renaming” per eliminare le false dipendenze (Write-After-Write, Write-After-Read) e massimizzare il parallelismo a livello di istruzione, una complessità hardware che rimane trasparente al software ma critica per le prestazioni.

Tabella Comparativa delle Caratteristiche Architetturali

Caratteristica	MIPS32	ARM Cortex-M (Thumb-2)	RISC-V (RV32)	x86-64
Tipologia ISA	RISC Puro	RISC Compresso	RISC Modulare	CISC (con uOps backend)
Endianness	Bi-endian (Config.)	Little-endian (Default)	Little-endian	Little-endian
Registri GP	32 ($0-$31)	16 (R0-R15)	32 (x0-x31)	16 (RAX-R15)
Branch Delay	Sì (Architetturale)	No	No	No
Return Address	Registro $31 (ra)	Registro R14 (LR)	Registro x1 (ra)	Stack (Push hardware)
Interrupt Ret	ERET	BX LR (Magic Value)	mret/sret	IRETQ

3. Application Binary Interface (ABI) e Convenzioni di Chiamata

L’ABI (Application Binary Interface) è il contratto software che definisce come le funzioni interagiscono a livello di codice macchina. Essa stabilisce l’uso dei registri, la gestione dello stack e il passaggio dei parametri, fungendo da ponte essenziale tra il compilatore C e l’hardware sottostante.

3.1) MIPS O32 ABI: Rigidità e Ottimizzazione

L’ABI O32, standard de facto per MIPS a 32 bit (utilizzata in PIC32), impone regole rigide per massimizzare le prestazioni riducendo gli accessi alla memoria.

• Passaggio Argomenti: I primi quattro argomenti di una funzione vengono passati nei registri $a0–$a3 ($4–$7). Tuttavia, il chiamante ha l’obbligo di riservare 16 byte di spazio sullo stack (chiamato “home area” o “shadow space”) per questi registri, anche se non vengono utilizzati. Questo permette al chiamato di salvare facilmente i registri nello stack se necessario (ad esempio in funzioni variadiche o durante il debugging).
  
• Registri Callee-Saved vs Caller-Saved: I registri $s0–$s7 devono essere preservati dalla funzione chiamata, mentre $t0–$t9 sono temporanei e possono essere sovrascritti. Questa distinzione è critica per i compilatori per ottimizzare l’allocazione dei registri (Register Allocation).
  

3.2) ARM AAPCS: Allineamento e Ottimizzazione Leaf

La specifica AAPCS (Procedure Call Standard for the ARM Architecture) introduce vincoli specifici per l’ecosistema ARM.

• Utilizzo R0-R3: Similmente a MIPS, i primi quattro argomenti risiedono nei registri. Tuttavia, tipi di dati a 64 bit (come long long) devono essere allineati a coppie di registri pari-dispari (es. R0-R1 o R2-R3), creando potenziali “buchi” nell’utilizzo dei registri se non gestiti correttamente.
  
• Ottimizzazione Leaf Function: Una funzione “foglia” (che non chiama altre funzioni) non ha bisogno di salvare il Link Register (LR) sullo stack. Può ritornare semplicemente eseguendo BX LR. Questo riduce significativamente l’overhead per piccole funzioni utility frequenti nei driver di basso livello.
  
• Allineamento dello Stack: L’AAPCS impone che lo stack pointer (SP) sia allineato a 8 byte ai confini delle funzioni pubbliche. Questo requisito è fondamentale per le istruzioni LDRD e STRD (load/store double word) presenti in ARMv7, che generano un Fault se l’indirizzo non è allineato, un errore comune durante il porting di RTOS.
  

3.3) x86-64: Conflitto di Standard (System V vs Microsoft)

L’architettura x86-64 evidenzia come l’ABI sia una costruzione software più che hardware, con due standard incompatibili che governano lo stesso processore.

• System V AMD64 ABI (Linux/BSD): Passa i primi sei argomenti interi nei registri RDI, RSI, RDX, RCX, R8, R9. Introduce la “Red Zone”, un’area di 128 byte sotto lo stack pointer che le funzioni foglia possono utilizzare senza decrementare RSP, risparmiando istruzioni.
  
• Microsoft x64 Calling Convention: Utilizza RCX, RDX, R8, R9 per i primi quattro argomenti interi. Richiede al chiamante di allocare 32 byte di “Shadow Space” sullo stack. A differenza del System V, non esiste la Red Zone e l’ordine dei registri è diverso, rendendo il codice assembly non portabile tra Windows e Linux senza wrapper condizionali.
  

4. Modelli di Gestione delle Eccezioni e degli Interrupt

La gestione degli eventi asincroni (interrupt) e sincroni (trap/exception) è l’aspetto dove l’interazione HW/SW è più stretta e dove le architetture divergono maggiormente in termini di latenza e complessità software.

4.1) ARM Cortex-M: NVIC e Stacking Hardware

Il Nested Vectored Interrupt Controller (NVIC) degli STM32 rappresenta un’integrazione hardware avanzata progettata per minimizzare la latenza e semplificare il software.

• Stacking Automatico: All’ingresso di un interrupt, l’hardware Cortex-M esegue automaticamente il push di un “Exception Frame” contenente R0-R3, R12, LR, PC e xPSR sullo stack corrente (PSP o MSP). Questo permette di scrivere le ISR (Interrupt Service Routine) come normali funzioni C, poiché l’hardware predispone lo stato conforme all’ABI.
  
• Tail-Chaining: Se un interrupt pendente di priorità maggiore o uguale arriva mentre il processore sta completando una ISR, l’NVIC esegue il “tail-chaining”: salta direttamente alla nuova ISR senza eseguire le operazioni di unstacking e restacking. Questo riduce la latenza tra due interrupt consecutivi da oltre 30 cicli a soli 6 cicli, un vantaggio cruciale per applicazioni real-time ad alta frequenza.
  
• Late Arrival: Se un interrupt ad alta priorità arriva durante la fase di stacking di un interrupt a bassa priorità, il processore commuta immediatamente al vettore ad alta priorità, sfruttando il salvataggio di contesto già in corso .
  

4.2) MIPS32: Gestione Software e Shadow Sets

L’architettura MIPS32 (es. PIC32) delega quasi interamente al software la gestione del contesto, offrendo flessibilità a costo di codice più complesso.

• Coprocessore 0 (CP0): Le eccezioni sono gestite tramite registri speciali nel CP0. Il registro Cause (Reg 13) contiene il campo ExcCode che identifica la natura dell’evento (interrupt hardware, syscall, overflow). Il registro Status (Reg 12) controlla le maschere di interrupt globali e i bit di modalità (EXL – Exception Level).
  
• Stacking Manuale: All’ingresso dell’eccezione, il processore salta a un vettore generale (tipicamente 0x80000180). Il codice di avvio dell’ISR deve salvare manualmente nel frame dello stack il registro EPC (Exception Program Counter), Status e tutti i registri GPR utilizzati. Non esiste stacking hardware automatico. Questo aumenta la latenza di ingresso e richiede prologo/epilogo in assembly.
  
• Shadow Register Sets: Per mitigare l’overhead software, alcune implementazioni avanzate come il PIC32MZ offrono banchi di registri ombra (Shadow Sets). Il processore può commutare automaticamente su un banco di registri alternativo per interrupt ad alta priorità, eliminando la necessità di salvare i GPR nello stack, emulando via hardware l’efficienza che ARM ottiene con lo stacking.
  

4.3) RISC-V: Flessibilità e Delegazione

RISC-V adotta un approccio intermedio, puntando sulla semplicità hardware e sulla configurabilità.

• Meccanismo di Trap: Al verificarsi di una trap, l’hardware salva il PC in mepc (Machine Exception PC) e la causa in mcause. Lo stato precedente di abilitazione degli interrupt viene salvato in mstatus.
  
• Modalità Vettorizzata vs Diretta: Il registro mtvec controlla il flusso. In modalità “Diretta”, tutte le trap saltano allo stesso indirizzo base. In modalità “Vettorizzata”, gli interrupt asincroni saltano a BASE + 4 * Causa, permettendo una latenza ridotta per la dispatrio, simile alla tabella vettori di ARM ma configurabile via software.
  
• Delegazione delle Eccezioni: Una caratteristica unica è la capacità di delegare selettivamente interrupt ed eccezioni a livelli di privilegio inferiori (es. da M-mode a S-mode) tramite i registri mideleg e medeleg. Questo permette a un OS in S-mode (come Linux) di gestire i page fault direttamente, senza l’overhead di invocare il firmware M-mode (SBI), ottimizzando le prestazioni del sistema operativo .
  

4.4) x86: IDT e Transizione Ring 3-0

La gestione su x86 è fortemente legata alla protezione della memoria e alla separazione dei privilegi (Ring).

• Interrupt Descriptor Table (IDT): La CPU utilizza la IDT per localizzare l’handler. L’ingresso in un interrupt comporta spesso una transizione dal Ring 3 (User) al Ring 0 (Kernel), che richiede il cambio dello stack (caricando SS:RSP dal Task State Segment) e il salvataggio hardware di SS, RSP, RFLAGS, CS e RIP.3
  
• Syscall vs Int 0x80: Nei sistemi Linux moderni su x86-64, l’istruzione int 0x80 (interrupt software) è stata soppiantata da syscall. Quest’ultima è ottimizzata per evitare l’overhead completo della gestione delle eccezioni IDT, caricando il RIP direttamente da registri specifici (MSR_LSTAR) e mascherando i flag, riducendo drasticamente il tempo di commutazione User-Kernel necessario per operazioni frequenti.24
  

5. Gestione della Memoria e Accesso alle Periferiche

L’interazione con il mondo esterno (GPIO, UART, Timer) avviene attraverso il Memory-Mapped I/O (MMIO), dove registri fisici delle periferiche sono mappati nello spazio di indirizzamento della CPU. La gestione di questa memoria varia radicalmente tra microcontrollori flat-memory e sistemi con memoria virtuale e OS complessi.

5.1) Mappe di Memoria e Segmentazione

• PIC32 (MIPS) e Segmentazione KSEG: L’architettura MIPS del PIC32 opera in uno spazio di indirizzamento virtuale fisso. La memoria è divisa in segmenti con proprietà di caching distinte:
  • KSEG1 (0xA0000000): Non-cached e non-mapped. Questo è il segmento critico per l’MMIO. Accedere ai registri delle periferiche attraverso un segmento cacheable (come KSEG0) porterebbe a incoerenza dei dati, poiché la CPU leggerebbe valori obsoleti dalla cache invece dello stato reale hardware.26
    
  • KSEG0 (0x80000000): Cacheable. Utilizzato per il codice kernel e i dati per massimizzare le prestazioni di esecuzione.
    
• STM32 (ARM) e Matrice AHB: Lo spazio di indirizzamento è piatto (flat) e unificato (4GB). Le periferiche sono mappate tipicamente a partire da 0x40000000. L’accesso è mediato da una matrice di bus multi-layer AHB.
  • Bit-Banding: Una caratteristica specifica dei Cortex-M (presente in alcuni STM32) è la regione di bit-banding. Essa mappa ogni singolo bit di una regione di RAM o periferica a una parola intera di 32 bit in una regione alias. Scrivere in questa regione alias permette di modificare atomicamente un singolo bit di un registro di controllo senza la necessità di una sequenza read-modify-write software, eliminando le race condition in ambienti multitasking senza dover disabilitare gli interrupt.2
    

5.2) Case Study: Accesso MMIO e Coerenza

• MARS Simulator (MIPS): In ambiente simulato MARS, l’MMIO è implementato in modo semplificato alle locazioni 0xFFFF0000 (Controllo Ricevitore) e 0xFFFF0004 (Dati Ricevitore). Il bit 0 del registro di controllo funge da flag “Ready”. Il software deve eseguire un polling attivo su questo bit prima di leggere il registro dati. Questo modello didattico riflette fedelmente il funzionamento dei registri di stato nelle UART reali (es. registro USART_SR su STM32).4
  
• Raspberry Pi (Linux e BCM2835): Sul SoC Broadcom, le periferiche risiedono a indirizzi fisici (es. 0x7E200000). In Linux, l’accesso diretto richiede il mapping di questa memoria fisica nello spazio virtuale del processo utente tramite /dev/mem e mmap().
  • Offset e Volatile: Il codice C deve calcolare l’offset corretto (che varia tra Pi 1, 2, 3 e 4) e utilizzare puntatori volatile per impedire al compilatore di ottimizzare o riordinare gli accessi alla memoria, garantendo che ogni scrittura C corrisponda a un ciclo di bus fisico.30
    
  • Sysfs vs libgpiod: L’approccio classico sysfs (/sys/class/gpio) è deprecato a causa della sua natura basata su file system, che introduce latenza e non garantisce atomicità. L’interfaccia moderna libgpiod utilizza character device (/dev/gpiochipN) e ioctl, permettendo operazioni atomiche su gruppi di pin e gestione degli eventi basata su interrupt, riflettendo uno spostamento verso un’astrazione kernel-mediated più robusta.32
    
• BeagleBone Black (PRU e Shared Memory): L’AM335x integra due unità PRU (Programmable Real-time Unit) che condividono la RAM con il core ARM principale (Linux).
  • Coerenza della Memoria: La comunicazione avviene scrivendo in una regione di memoria condivisa (es. 0x00010000 nello spazio PRU). Poiché la cache del core ARM potrebbe trattenere i dati, è necessario gestire esplicitamente la coerenza (spesso disabilitando la cache per quella regione o usando primitive di barriera) per garantire che i dati scritti dalla PRU siano immediatamente visibili a Linux e viceversa. Questo modello di shared-memory è molto più veloce di qualsiasi IPC basato su socket o pipe.34
    

6. Astrazione del Sistema Operativo: Kernel, HAL e Driver

Il sistema operativo funge da arbitro tra le richieste delle applicazioni e le risorse hardware. Analizziamo come questo viene implementato in sistemi RTOS (ChibiOS) e General Purpose (Linux).

6.1) ChibiOS: Astrazione a Oggetti in C

ChibiOS adotta un design HAL (Hardware Abstraction Layer) unico che utilizza strutture C e puntatori a funzione per emulare un approccio orientato agli oggetti, garantendo portabilità senza il bloat del C++.

• Modello a Driver: Un driver (es. UART) è definito da un’API di alto livello indipendente dall’hardware (uartStart, uartSend) e da un’implementazione di basso livello (LLD – Low Level Driver) specifica per il microcontrollore (uart_lld.c).
• Virtualizzazione Statica: A differenza delle vtable dinamiche del C++, ChibiOS risolve le dipendenze a tempo di compilazione tramite macro e inclusione condizionale. L’applicazione chiama uartStart(&UARTD1, &config). UARTD1 è una struttura costante che contiene l’indirizzo base dei registri fisici (es. USART1 su STM32). L’HAL gestisce internamente il mapping bit-a-bit sui registri di controllo (CR1, CR2), mascherando la complessità all’utente.
• Portabilità vs Efficienza: Confrontato con l’HAL di STM32Cube, spesso criticato per l’eccessiva verbosità e overhead di controllo errori, l’HAL di ChibiOS è progettato per mappare quasi 1:1 le chiamate API in scritture di registro, spesso tramite funzioni inline. Tuttavia, questo richiede uno sforzo significativo di porting: adattare ChibiOS a una nuova architettura (es. da STM32 a PIC32MZ) richiede la riscrittura completa del livello pal_lld.c per gestire le differenze tra il GPIO dell’STM32 (MODER, OTYPER) e quello del PIC32 (TRIS, LAT, PORT).

6.2) Linux Kernel Modules (LKM) e Spazio Utente

In Linux, l’accesso diretto all’hardware dallo spazio utente è fortemente limitato per garantire stabilità e sicurezza.

• Kernel Module: Per controllare un GPIO o una periferica custom su Raspberry Pi, è spesso necessario scrivere un LKM. Questo codice gira in Ring 0 e utilizza API kernel come ioremap per accedere ai registri fisici. Espone poi un’interfaccia al file system virtuale (/dev/mydevice).
  
• Overhead di System Call: Quando un programma utente scrive su /dev/mydevice, avviene un context switch costoso. La CPU deve salvare lo stato utente, passare in modalità kernel, verificare i permessi, eseguire il codice del driver e ritornare. Questo introduce una latenza nell’ordine dei microsecondi, rendendo Linux inadatto per il bit-banging ad alta frequenza (MHz) che è invece banale su un microcontrollore bare-metal o con RTOS.40
  

6.3) AVR e Context Switch Semplificato

Per completezza, analizziamo il context switch su architettura AVR a 8 bit (Arduino), spesso citata come termine di paragone per la semplicità.

• SaveContext: Non avendo meccanismi complessi come il PendSV, il context switch su AVR (usato in porting sperimentali di ChibiOS o FreeRTOS) è puramente software. La macro portSAVE_CONTEXT disabilita gli interrupt (cli), e poi esegue il push manuale di 32 registri (r0-r31) e del registro di stato (SREG) sullo stack. L’assenza di modalità privilegiate o stack multipli (MSP/PSP) rende il processo lineare ma “pesante” in proporzione alla potenza della CPU, consumando molti cicli per salvare un contesto relativamente ampio.42
  

7. Il Context Switch: Il Cuore dell’Interazione HW/SW

Il cambio di contesto (Context Switch) è l’operazione che definisce un sistema multitasking, richiedendo al software di salvare lo stato “congelato” dell’hardware per ripristinarlo successivamente.

7.1) Meccanismo ARM Cortex-M (ChibiOS/FreeRTOS)

Su STM32, il context switch sfrutta l’eccezione PendSV (Pendable Service Call), impostata alla priorità minima.

1. Trigger: Lo scheduler determina la necessità di un cambio task e solleva il flag PendSV.
2. Hardware Save: L’hardware salva automaticamente i registri Caller-Saved (R0-R3, R12, LR, PC, xPSR).
3. Software Save (ISR): L’handler PendSV (scritto in assembly nudo) salva i registri Callee-Saved (R4-R11) sullo stack del processo (PSP).
4. Switch Stack Pointer: Il valore corrente del PSP viene salvato nella struttura del thread uscente. Viene caricato il PSP del nuovo thread.
5. Software Restore: L’handler esegue il pop di R4-R11 dal nuovo stack.
6. Exc Return: L’istruzione BX LR con un codice speciale (es. 0xFFFFFFFD) segnala all’hardware di completare il ripristino automatico (unstacking di R0-R3, PC, etc.) e riprendere l’esecuzione del nuovo task. Questo approccio ibrido HW/SW è estremamente efficiente e garantisce che il context switch non interrompa mai interrupt critici ad alta priorità.43

7.2) Meccanismo MIPS32 (Porting ChibiOS/PIC32)

Su MIPS, l’assenza di stacking hardware richiede un approccio diverso.

1. Software Save Totale: L’handler dell’eccezione deve allocare spazio sullo stack (ADDI SP, SP, -frame_size) e salvare tutti i registri, inclusi quelli temporanei, HI, LO (per moltiplicazioni) e EPC.
2. Switch: Si aggiorna il puntatore allo stack globale corrente.
3. Restore e ERET: Il ripristino carica i registri dal nuovo stack e termina con l’istruzione ERET, che atomicamente riabilita gli interrupt (impostando il bit EXL a 0 nel registro Status) e salta all’indirizzo contenuto in EPC. La gestione atomica del bit EXL è critica per evitare interrupt annidati incontrollati durante lo switch.43

Tabella Comparativa di Latenza e Meccanismi

Piattaforma	Meccanismo di Switch	Salvataggio Contesto	Latenza Stimata (Cicli)	Note
STM32 (Cortex-M)	Eccezione PendSV	Ibrido (HW Auto + SW Manuale)	~30-50	Tail-chaining ottimizza switch consecutivi
PIC32 (MIPS32)	Interrupt Software	Completamente Software	~60-100	Richiede gestione manuale di Status e EPC
AVR (Atmega)	Interrupt Timer	Completamente Software	~40-80	Lento in proporzione al clock (8-16MHz)
Linux (x86-64)	Scheduler Kernel	Software (TSS + Registri)	>1000	Include overhead MMU, cache flush, user/kernel

8. Conclusioni e Sintesi

L’analisi comparativa delle architetture RISC-V, MIPS32, ARM e x86 rivela una dicotomia fondamentale nella progettazione dei sistemi di elaborazione: il compromesso tra automazione hardware e flessibilità software.

Le architetture come ARM Cortex-M (STM32) incarnano l’approccio dell’integrazione verticale: l’hardware si fa carico di compiti complessi come lo stacking dei registri e la gestione vettorizzata delle priorità (NVIC). Questo semplifica la scrittura di RTOS e firmware, riducendo la latenza e aumentando il determinismo, rendendole ideali per il controllo real-time. Tuttavia, questa automazione impone una rigidità strutturale (layout dello stack fisso).

Al contrario, MIPS32 e RISC-V offrono un modello più “puro” e disaccoppiato. La mancanza di stacking hardware automatico e la gestione esplicita tramite registri CSR/CP0 spostano la complessità sul compilatore e sullo sviluppatore del kernel. Sebbene ciò possa aumentare la latenza iniziale e la dimensione del codice di interrupt, offre una flessibilità totale nella gestione del contesto, permettendo ottimizzazioni software aggressive (come lo stacking parziale o lazy) che sono impossibili su hardware più rigidi.

Infine, l’analisi dei sistemi operativi (Linux vs ChibiOS) evidenzia come l’astrazione sia il nemico naturale della latenza. Mentre ChibiOS sfrutta la mappatura diretta delle strutture C sui registri fisici per ottenere prestazioni quasi bare-metal, Linux interpone strati di memoria virtuale e protezione che, pur garantendo stabilità e sicurezza su hardware complessi (x86, Cortex-A), rendono l’interazione diretta HW/SW costosa e indiretta. La soluzione moderna a questo collo di bottiglia risiede in architetture eterogenee (come BeagleBone Black con PRU o STM32MP1), dove core applicativi e core real-time coesistono, permettendo al software di scegliere il giusto livello di interazione hardware per ogni specifico compito.

In conclusione, non esiste un codice “universale”. Ogni riga di C o Assembly è intrinsecamente legata alle decisioni prese dal progettista del chip riguardo alla pipeline, alla memoria e alle eccezioni. Una programmazione di sistema robusta ed efficiente non può prescindere da una comprensione profonda di questi meccanismi sottostanti.