Convenzioni, convenzioni

Ma ci sono, e sono necessarie altre convenzioni.

Se ci arrivasse dallo spazio un messaggio con la richiesta di 100, ci potremmo trovare in difficoltà: il messaggio viene da Pandora , da Hex, da Scorpio o da una stazione terrestre ?

Perchè, scritto così, senza l' indirizzo del mittente, la cosa si presta a confusione: a seconda del sistema numerico con cui esprimo quelle cifre, possibili in tutti e quattro i sistemi, definisco valori totalmente diversi tra di loro.

Per il buon esito delle comunicazioni spaziali urge un qualche metodo per distinguere il sistema per cui scrivo le cifre.

Così, si sono definiti dei suffissi o prefissi per questo scopo. E abbiamo :

Queste convenzioni ci sono indispensabili per capire quale è il numero che viene rappresentato con una certa serie di cifre, in quanto nei listati di programmazione di un computer o di un micro controller, posso trovare mischiati tutti e quattro i sistemi numerici.
Come abbiamo visto, 100 decimale è ben diverso da 100 binario o 100 ottale !

In base alle convenzioni, trovando una riga che contiene   NUM = 0x145 , so al volo che si tratta di esadecimale.
Così se scrivo NUM = b'11110000' è binario.

Avvertenza : non tutti i compilatori accettano tutte le possibili convenzioni.  
Per i PIC solitamente sono accettate le forme x ' cifre ', con x che è 

• B o b per binario (ad esempio b'11100011' o B'11100011')
• H o h per esadecimale (esempio H'3F' o h'3F'
• O o o per ottale (esempio O'100' oppure o'100')
• D o d per decimale.(d'100' o D'100')

e le cifre comprese tra due apici semplici. Altre forme correnti sono  :

• . cifre (ad esempio .1250) per il decimale 
• 0xcifre (ad esempio 0x1A) per l' esadecimale.

tenete presente che in un listato Assembly, una linea iniziale

può essere usata per impostare il sistema di interpretazione dei numeri.
Se non scritta, questa linea è intesa come default (programmabile nelle opzioni); per MPASM vale dec.

Indicazioni locali di numeri con i prefissi/suffissi visti qui sopra sovra passano per quel numero quanto stabilito dalla radix.

Se tutto è chiaro, possiamo ora scorrere i listati dei sorgenti con maggiore coscienza.

E BCD ? e ASCII ?  

Abbiamo detto che BCD non è un vero sistema di numerazione, ma una convenzioni per semplificare le operazioni di presentazione dei numeri; e ASCII è una codifica per interscambio di testi e simili. Non c'è quindi un "modo" per dire che quel numero è in BCD o in ASCII, se non il dichiararlo come tale in un commento. Dipenderà da come uso, nel flusso del programma, il numero, per ottenere un risultato piuttosto che un' altro.
In effetti, nei microcontroller, un dato espresso in ASCII può essere indicato nella lista sorgente come ' ', ovvero compreso tra due apici, per cui la scrittura 'ABC' non indica un numero esadecimale (che avrebbe potuto essere definito con 0xABC o H'ABC' o ABCh o simili, bensì indica le tre lettere (maiuscole) tali e quali. E ASCII non serve solo a rappresentare lettere e numeri, ma anche segni di interpunzione, spazi, ecc.

Va compreso che per il calcolatore il senso dei numeri che gli passiamo non  ha alcuna importanza, perchè il computer non ha un "cervello". Il calcolatore utilizza le cifre che gli passiamo e le tratta secondo la logica che gli abbiamo imposta. Quindi, se inserisco un dato, ad esempio 100, senza specificare se si tratti di binario o decimale, il calcolatore non mi chiede certo che cosa intendevo: si limita ad eseguire l' operazione richiesta con i default che gli ho applicato. Se poi intendevo che 100 era decimale, ma avevo lasciato tutto come se il dato fosse binario, invece di una risposta per 100, ricevo una risposta per 4.

Questo è molto importante da capire : il computer non agisce di testa sua, non ce l' ha ! 
Fa solo ed esclusivamente quanto gli ordino, secondo le leggi e le regole che il suo progettista ha fissato. 

"Però sto scemo mi accende il primo terzo led, ma non gli altri". 
Non è scemo, non può esserlo; semplicemente se gli ho detto "metti sul comando dei led il numero 100", in binario, solo il terzo bit sarà a 1. Se però gli dico che il numero è decimale (100 decimale = 1100100 binario), si accenderanno anche i led 6 e 7.

Convenzioni piccole e grandi

Sempre a riguardo delle convenzioni, è opportuno ricordare che nella tabella ASCII le lettere maiuscole e minuscole hanno un diverso codice. 

Questo fa si che una password solitamente sia "case sensible", ovvero distingua se i caratteri sono maiscoli o no. Per cui, un ambiente "case sensitive" riterrà diversi tra di loro "ABC" e ABc".

Normalmente nei linguaggi di programmazione e in molte altre circostanze, l' ambiente può essere reso "case sensitive" come opzione, oppure non esserlo. Un ambiente "non case sensitive" riterrà uguali "ABC", "Abc", "abc", ecc.

La cosa non ha una importanza solo formale. Perchè non siamo nell' ambito degli SMS dove la trascuratezza e lo scarso rispetto non tanto per norme che si possono ritenere obsolete, quanto del "rispetto" per se stessi e per gli altri, fa si che tutto, compreso il proprio nome, sia scritto in minuscole. 

Qui ci rivolgiamo all' ambito della programmazione, dove vigono non regole di buona creanza, ma regole molto più rigide, che sono quelle della macchina. Per cui è ben possibile che "ABC" venga accettato e "ABc" no. 
Una esperienza del genere la possono avere tutti digitando password in ambienti case sensitive, come è la maggior parte dei casi. La possibilità di far valere diversamente maiuscole e minuscole permette un numero molto maggiore di combinazioni.

"Oh stupida macchina", dirà qualcuno, ma non a ragione. 
Perchè nella struttura che il progettista ha elaborato per permettere a quella macchina di funzionare in un certo modo c'è proprio la necessità di identificare con chiarezza i dati inseriti, distinguendo anche se si tratta di maiuscole o minuscole.

Se ci riferiamo a MPASM, l' Assembly dei PIC, troviamo che il case sensitive è disabilitato dove potrebbe creare lungaggini nella scrittura.

Ad esempio, gli opcodes posso essere scritti tanto in minuscolo che in maiuscolo: così  

• movwf è la stessa cosa di MOWVF. 

L' Assembler provvede a verificare il caso e fa passare ugualmente le due scritture come equivalenti.

Non farà passare la scrittura MOVTF o movtf perchè non fa parte degli opcodes ammessi. 
Questo comportamento è stato deciso da chi ha elaborato l' Assembler e spesso può essere variato attraverso le opzioni del menu di configurazione del programma.

Ma se definisco un oggetto (variabile) con il nome (label) Mario e poi mi aspetto di poterlo ritrovare scrivendo mario o MARIO, questo non sarà più possibile : l' Assembler ha ricevuto e messo nelle sue liste Mario e non ha alcun modo di confonderlo con mario o MARIO. 

Anzi, non deve neppure farlo, perchè la scelta delle label dipende dall' utente. 
Quindi, in ambiente case sensitive avrò la possibilità di scrivere:

• mario

• MARIO

• mArIo

• MaRIo

o qualsiasi altra variazione possibile, ottenendo un elevato numero di label, tutte utilizzabili. 

In ambiente non case sensitive, tutte queste possibili scritture saranno esattamente equivalenti: meno difficoltà a ricercare una label perchè mArIo sarà considerato identico a MaRiO o a marIO, ma saranno drasticamente ridotte le possibilità di creare nuove label.