Esercitazioni PIC - Assembly

La scrittura del sorgente

La scrittura del sorgente Assembly (e questo vale per qualsiasi linguaggio) è anche un fatto formale e il mantenere una certa struttura consente notevoli vantaggi rispetto ad una scrittura disordinata.
Li definiamo "linguaggi" proprio perchè, come la lingua parlata e scritta, hanno una sintassi ed una ortografia, che, per quanto possano essere semplici, sono da rispettare con assoluta precisione: come se a scuola, sbagliando ortografia e sintassi, l' insegnante ci avrebbe dato un cattivo voto, anche qui un sorgente il cui testo non risponde alle regole del linguaggio sarà respinto dal compilatore, con una lista degli errori commessi e la mancata produzione del file oggetto.

Dunque è opportuno, già dall' inizio, adeguarsi ad una scrittura ordinata e sensata, evitando quegli errori che rendono poi pesante la correzione del sorgente. Sfortunatamente si trovano in rete  molti cattivi esempi di programmazione Assembly (e non solo...); in generale, si tratta di scheletriche liste di istruzioni in cui i commenti sono praticamente assenti, rendendo penosa la lettura e difficile la comprensione, mentre si utilizzano solo molto parzialmente le possibilità offerte dall' Assembler.
Tra i problemi principali vogliamo citare:

1. la mancanza di una qualsiasi forma: un sorgente privo di una forma logica nella sua scrittura impedisce di realizzare un lavoro ordinato ed efficace e rende difficile, se on impossibile, la rilettura del testo durante la correzione degli errori (debug)
2. la mancanza di commenti utili a capire cosa e come si sta facendo: il problema maggiore nella programmazione Assembly è l' inadeguatezza dei commenti, elemento chiave di un sorgente che sia auto documentante, ma sopratutto comprensibile. Non solo per altri che lo debbano leggere, ma anche per se stessi: qualunque programmatore sa che quanto ha scritto, se non adeguatamente commentato, gli risulterà difficilmente comprensibile a distanza di tempo, nonostante l' abbia scritto lui stesso.Non parliamo poi di quando sia necessario apportare modifiche al programma, riutilizzarne parti o ricercare le cause di mal funzionamenti.
3. l' uso smodato di valori assoluti: l' Assembly nasce proprio per evitare per quanto possibile l' uso di valori assoluti. Se è ben vero che in Assembly trattiamo a livello di registri, di bit e bytes, è anche vero che il linguaggio nasce proprio per evitare di citare valori esadecimali o binari, sostituendoli con simboli (label) mnemonici, che consentono una ben più immediata comprensione e gestione.
4. la configurazione lasciata al programma di gestione del dispositivo di programmazione o espressa in esadecimale : in questo ricade anche la configurazione iniziale dell' hardware del  microcontroller: non si tratta di un elemento secondario, ma di una base da cui dipende poi il corretto svolgimento del programma. E' ben vero che nella memoria del microcontroller i Configuration Bits si trovano sotto forma binaria, ma nel momento di determinarli l' uso di valori binari è assurdo, in quanto nasconde quali siano le impostazioni programmate.
   La scrittura sotto forma di testo, che poi sarà interpretata dal compilatore, è invece di immediata comprensione
5. l' inserimento di comandi dell' Assembler non giustificati, come Errorlevel -302 e simili: l'Assembler fornisce numerose funzioni (direttive), dalla formattazione del file lista (file .lst) ottenuto dalla compilazione, alla gestione di memoria, all' aggiunta di pseudo istruzioni o ad automatismi di aiuto al programmatore. E', purtroppo, normale trovare in rete esempi in cui questi comandi da una una parte sono abusati e dall' altra restano in gran parte inutilizzati. Questa mancanza di conoscenza delle funzioni messe a disposizione dall' Assembler non è certo un aiuto per il principiante.
6. l' uso del simbolo $ e l' uso limitato di simboli, macro, subroutine: Assembly è un linguaggio simbolico, ma i simboli hanno valori e funzioni ben precise ed il loro uso non può essere nè casuale, nè eccessivo e neppure inadeguato. Un testo sorgente ben strutturato consente spesso di poter essere riutilizzato anche in altre situazioni ed è la base per realizzare librerie. L' idea di scrivere in modo modulare, sfruttando subroutine, macro, librerie è la chiave per poter realizzare senza eccesso di fatica programmi via via più complessi.
7. l' assenza di modularità: la mancanza di forma è causa di mancanza di modularità. macro, subroutine, librerie, sono elementi chiave  della programmazione e consentono, oltre ad una maggiore efficacia della scrittura, la possibilità di riutilizzare quanto scritto, riportandolo in altre occasioni senza la necessità di scrivere nuovamente. Una struttura modulare è l' unica via per affrontare sorgenti di una certa complessità.

Se avete già iniziato con una forma poco corretta di Assembly, consigliamo di adottare da subito una forma rigorosa che non è pedanteria, ma necessità.

Spendiamo, dunque, un bel po' di parole per cercare di fornire una base di partenza abbastanza solida.
Anche se per vari esercizi proposti la loro semplicità è tale da non richiedere molti "fronzoli", ugualmente riteniamo sia necessario anche in questi casi attenersi strettamente alle regole di una buona programmazione.  In caso contrario, la mancanza di un metodo ci farà trovare in enormi difficoltà una volta si voglia affrontare programmi più complessi.