Subroutines e stack

Tutorial → PIC18 → Assembly → Le subroutines

Scheda con PIC18

Una subroutine (o anche routine o sottoprogramma) è una sequenza di istruzioni assembly che realizza un determinato compito. Questa sequenza non è autonoma, ma viene chiamata (call) all'interno di un generico programma; al termine della esecuzione della subroutine, il Program Counter ritorna (return) al suo valore precedente, per eseguire l'istruzione immediatamente seguente la call.

Una subroutine è generalmente identificata da una label e deve terminare con l'istruzione return.

Un esempio semplice

Per una migliore comprensione di questo esempio, si consiglia di aver prima completato gli esempi ed esercizi da 4a a 4d e di aver provato a far lampeggiare un LED.

Il seguente esempio d'uso mostra il programma principale main al cui interno, per due volte, è invocata la stessa subroutine delay:

Ritardo

Il funzionamento è intuitivo:

Il codice alle righe 23-24 accende i quattro LED 7, 5, 3 e 1
L'istruzione alla riga 25 (call delay) porta il program counter alla riga 33 (nota 5)
L'esecuzione delle righe da 33 a 42 richiede circa un secondo. In pratica è l'esempio 4c
L'istruzione alla riga 44 fa tornare il program counter alla riga 26 (successiva della 25)

Il codice alle righe 27-28 accende inverte l'accensione degli otto LED
L'istruzione alla riga 29 (call delay) porta il program counter alla riga 33
L'esecuzione prosegue e l'istruzione alla riga 44 fa tornare il program counter alla riga 30 (successiva alla 29).

Alcune osservazioni:

La stessa istruzione return di riga 44 una volta fa "tornare" il programma alla riga 26 ed una volta alla riga 30, in relazione alla posizione della corrispondente call
L'indirizzo a cui il program counter deve tornare al termine della esecuzione della subroutine viene salvato nello stack hardware del PIC18 (return address stack). Questa soluzione permette di richiamare una subroutine da più punti diversi di un programma, garantendo sempre il ritorno all'istruzione successiva alla call
La profondità dello stack hardware del PIC18 è pari a 31 (nota 3) e quindi occorre limitare a tale valore il numero di subroutine che richiamano subroutine che richiamano subroutine...

Vediamo nel dettaglio il funzionamento dell'istruzione call, con riferimento ai fogli tecnici (nota 4):

Call

L'istruzione call ha un solo operando, un numero tra 0 e 1 048 575, cioè un qualunque indirizzo compreso all'interno della memoria FLASH (un milione di parole da 16 bit, cioè 2 MB). Questo operando è l'indirizzo a cui si trova la subroutine ed in genere è indicato da una label (delay nell'esempio)
La call memorizza in cima allo stack hardware (Top Of Stack) l'indirizzo dell'istruzione successiva, cioè l'istruzione a cui il codice dovrà tornare dopo la conclusione della subroutine. Questa operazione è a volte indicata come Push
Il valore di k viene messo nel Program Counter e quindi l'esecuzione del codice passa alla subroutine

Vediamo nel dettaglio il funzionamento dell'istruzione return, con riferimento ai fogli tecnici (nota 4):

Return

L'istruzione return non ha argomenti
La return preleva dalla cima allo stack hardware (Top Of Stack) l'indirizzo a cui ritornare, indirizzo precedentemente memorizzato dalla call corrispondente. Questo indirizzo viene posto nel Program Counter, permettendo di tornare all'istruzione successiva alla call

Prima di proseguire, completare l'esercizio 1 e l'esercizio 2

Un secondo esempio

La soluzione proposta nel primo esempio ha vari difetti:

Richiede permanentemente l'uso di due celle di memoria RAM, risorse limitata, anche quando la subroutine non è in esecuzione. Si pensi agli effetti in un programma di grosse dimensioni, con centinaia di variabili
Come effetto collaterale, riscrive il contenuto del registro STATUS (i flag), distruggendo il precedente valore.
(non in questo caso) Potrebbe riscrivere i contenuti anche dei registri WREG e BSR

L'esercizio 2 ha creato, a livello umano, un ritardo molto breve. Un'idea potrebbe essere quella di scrivere una subroutine che richiama decine di volte ritardo_breve, per ottenere un ritardo più lungo. Per esempio il codice seguente mostra ritardo_lungo_1, ovviamente dalla durata di circa 30 ms

Ritardo Lungo - prima versione

Si tratta di una soluzione molto rigida e ben poco elegante; sarebbe più comodo usare un loop che richiama ritardo_breve qualche decina di volte, decrementando per esempio da venti a zero un'apposita variabile contatore:

Ritardo lungo - loop

Ancora meglio sarebbe usare WREG invece che contatore, per non sprecare una cella di memoria. Peccato che tale soluzione non funziona (perché? La risposta poco più avanti, ma vale la pena provare a rispondere usando la propria intelligenza...).

Una subroutine, per essere davvero utilizzabile, non deve come effetto collaterale modificare i registri che descrivono lo stato del processore, cioè i registri WREG, STATUS e BSR.

Una possibile soluzione è quella di creare alcuni registri temporanei che permettono di salvare i valori di tali registri all'inizio del codice della subroutine e di recuperarli al termine.

Questa tecnica è mostrata nella codice che potete scaricare a fondo pagina. Questo codice contiene due subroutines:

La prima ritardo_breve è sostanzialmente identica a quelle appena mostrate, se non nell'uso di registri temporanei per salvare WREG e STATUS (nota 1)
La seconda ritardo_lungo, invoca per 100 volte la subroutine ritardo_breve per ottenere un ritardo di circa 300 ms, significativo anche a livello umano

Il salvataggio nei registri temporanei di WREG e STATUS è reso necessario dal fatto che entrambe le subroutines usano gli stessi registri: non salvarli avrebbe causato un'interferenza tra le due subroutines e, in definitiva, il loro mancato funzionamento.

Si noti che per quanto riguarda ritardo_lungo non è stato implementato alcun meccanismo di registri temporanei; sarebbe stata necessaria la creazione di ulteriori registri temporanei, con ulteriore spreco di spazio e potenziali rischi difficili da controllare nel caso di omonimie. (nota 2)

Un esempio avanzato

L'ultimo esempio mostra l'utilizzo dello stack software per il salvataggio dei registri: in pratica ogni variabile che verrà modificata all'interno della subroutine viene salvata all'inizio e recuperata prima del return. Il codice lo potete scaricare a fondo pagina

Come prassi tutte le subroutines iniziano con il salvataggio del contesto nello stack software (nota 6):

movwf POSTDEC1 ; salva WREG nello stack
movff STATUS, POSTDEC1 ; salva i flags nello stack
movff BSR, POSTDEC1 ; salva BSR nello stack

Terminano con il ripristino del contesto, prelevando i contenuti originali dei registri dalla stack software:

movff PREINC1, BSR ; ripristina il registro BSR
movff PREINC1, STATUS ; ripristina i flags
movf PREINC1, W ; ripristina il registro WREG

Si noti la simmetria tra l'ordine di salvataggio e quello di ripristino; non ha invece particolare importanza l'ordine di salvataggio, purché venga mantenuta la simmetria al momento del ripristino.

Questa può essere considerata la soluzione definitiva, utilizzabile anche in altri contesti, come quello delle interruzioni.

Codice

delay_2.asm - Subroutine di ritardo con registri temporanei
delay_stack.asm - Subroutine di ritardo, stack software

Esercizi

Eseguire passo-passo il primo codice di esempio (saltando i blocchi che si ripetono centinaia di volte...) ed osservare il contenuto dello stack hardware
Commentare il seguente esempio, eseguirlo ed individuare gli effetti collaterali (in particolare: quali registri vengono riscritti all'interno di ritardo_breve?)
(Avanzato) Calcolare il tempo impiegato dalla subroutine ritardo_breve per completare la sua esecuzione.
Trasformare il codice dell'esempio 6b in una subroutine

Note

L'esempio mostra, per generalità, anche il salvataggio del Bank Select Register, sebbene in questo caso non viene modificato all'interno della subroutine
In teoria PIC18 implementa un metodo automatico per il salvataggio dei registri (fast register stack), ma, essendo ad un solo livello è assolutamente sconsigliato il suo uso per subroutines generiche. In genere viene riservato alle interrupt ad alta priorità
In realtà alcuni livelli dello stack sono usati dal debugger
Nell'estratto dei fogli tecnici sono stati tolti i riferimenti al flag {,s} ed ai registri shadow WS, STATUSS e BSRS: questa scelta è motivata dal fatto che è bene non utilizzare tale flag e, in questo caso, tali registri
Sarebbe più corretto riportare l'indirizzo di memoria invece che la riga del codice sorgente, dove molte righe sono vuote
Non sempre è strettamente necessario salvare tutti i registri, ma è una buona prassi per evitare errori

Data di creazione di questa pagina: maggio 2016
Ultima modifica: 5 luglio 2017