Un'altra manciata di giorni e ho aggiunto gli Array, per il momento mono-dimesione.
Sia stringhe che numerici e i comandi per usarli sono ANEW, APUT e AGET.
Al momento ogni elemento di un array di numeri occupa due byte perché uso word ma
un array di stringhe occupa 256 byte estremamente esoso per un Amstrad CPC.
Sto pensando, in fase di creazione con ANEW, di poter dichiarare lo spazio massimo in byte
per elemento in maniera da ridurre il consumo di memoria.
Anche perché in questo esempio mi partono 2 interi KByte.
Come anche nel caso di PROC/FUNC il valore viene restituito tramite le variabili
globali _Value e _Value$ come succede per "it" in Livecode.

Un'altra manciata di giorni e il compilatore cresce un'altro pochino.
Ora c'è la struttura di controllo IF/ELSE/ENDIF su più righe (alla faccia del Locomotive Basic) e
in più è possibile nidificarli. La parte più complicata, se posso dire così, è stato scrivere il codice Z80
per ogni tipo di confronto usando i salti jr ed ottimizzare il più possibile con le label.
Inoltre nel esempio uso il nuovo comando FUNC/ENDFUNC e il ciclo FOR/NEXT
Tanto per controllare che continua a funzionare tutto hahahahaha

Credevo di scrivere molto più codice in Livecode per implementare due nuovi fondamentali comandi PROC/ENDPROC FUNC/ENDFUNC
Invece con una buona analisi, con un pugno di righe, ecco qui due istruzioni fondamentali:

case "PROC"
case "FUNC"
if gaProc[v_Token2]["Nome"] = v_Token2 then
xAbort "[ERROR] PROC/FUNC already declared"
else
put v_Token2 into gaProc[v_Token2]["Nome"] //Aggiungo il nome della procedura all'elenco
put 0 into gaProc[v_Token2]["NParametri"]
put true into gProcedura //Indica al output che si sta generando una procedura
xOutPut v_Token2&":" //Nome_procedura:
repeat for each item tVar in v_RestoTesto2
add 1 to gaProc[v_Token2]["NParametri"] //Incremento il numero di parametri
put (tVar) & comma after gaProc[v_Token2]["Parametri"] //Aggiungo
xSeNonEsisteCrea tVar,,True //Crea una variabile per ogni parametro esistente
end repeat
end if
break

case "ENDFUNC"
case "ENDPROC"
xOutPut "ret"
put false into gProcedura
break

Ovviamente poi nella fase di generazione del codice Z80 ci sono tutte le dichiarazioni delle variabili/parametri
distinguendo tra variabili testo e numeriche. Oltre alla valorizzazione della variabile di ritorno per le variabili.
Come da mia idea iniziale li dati di ritorno delle funzioni sarò contenuto nelle variabili globali _Value e _Value$
come succede per "it" in Livecode.

Da qualche giorno, nelle mie ore libere da impegni, ho ripreso il progetto del compilatore Z80.
Il nome provvisorio è NOBasicCompiler e l'unico target, per il momento, è l'Amstrad CPC.
Mancava però una procedura per salvare e ripristinare lo schermo.
Alle volte la semplicità è la strada migliore in 10 righe ecco qui le due funzioni:
_RestoreScreen: di"
ld hl,&4000"
ld de,&c000"
jr EsciSRScreen"
_SaveScreen: di"
ld hl, &c000"
ld de, &4000"
EsciSRScreen: ld bc,#4000"
ldir"
ret"
Certo manca ancora una gestione dell'area superiore ai 64KB nel caso dei modelli
6128, 6128Plus e con la presenza di espansione di memoria. Ma arriverà con il tempo.
E sopratutto mi "mangia" 16KB di memoria per salvare lo schermo, il che riduce lo
spazio dedicato al programma.

Oggi ho terminato di implementare alcuni comandi base del Basic nel NOBasic Compiler.
Funziona tutto, non credevo
Ora passo al progetto successivo e in futuro ottimizzerò il codice Z80

Sono passati quasi due mesi da quando ho cominciato a scrivere questo compilatore e visto che il lavoro mi occupa gran parte della giornata e mi dedico solo poche ore alla settimana sta venendo proprio bene.
I registri dello Z80 sono favolosi, Federico Faggin è proprio un genio.
Sono ancora nella fase della scrittura brutale l'ottimizzazione arriverà più avanti.
Partendo dalla sintassi del Basic che ho scritto per l'interprete trasformo il codice in istruzioni Z80 poi compilo con Pasmo e creo il file .DSK direttamente usando iDisk.
Funziona alla grande ed è velocissimo.