Paolo Borzini - Pixel & Pensieri

 Sono passati mesi dall'ultima volta che ho inserito qualche notizia o novità. Per pigrizia o forse perchè non mi è mai piaciuto tenere un diario :-O Comunque sia ad un certo punto guardando il sorgente in LiveCode del compilatore Z80 questo era diventato un coacervo di codice ridondante con funzioni duplicate e in alcuni casi dissonanti tra loro. A quel punto la decisione di ripartire da zero per la terza volta ma ora con le idee più chiare (forse) e una lista di funzioni base per riconoscere i vari dati, d'altronde non ha senso inventare ogni volta la ruota.  Ad aprile è nato il SAM ovvero Strange And Messy Compiler hahahaha. Il codice assembler generato non è proprio ottimizzato e spesso è arzigogolato ma funziona alla grande, per lo meno sul mio 6128 plus. Questi i comandi e funzioni implementate finora: ASM,BORDER,CALL,CLS,COLORFG,COLORBG,COLORINV,CURSOR,DIM,ELSE,END,ENDIF,FOR,GET,GOTO, IF,IFG,IFP,INPUT,INK,NEXT,LABEL,LOCATE,MODE,PEEK,POKE,PRINT, RANDOMIZE,READGET,REM,RND...

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 ...

 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.

La scrittura del programma è ultimata ma mi sono accorto che visto la quantità di guide scritte negli anni e utilizzando sia un semplice editor di testi che programmi apposta non tutte le guide sono uguali. Alcune i NODE sono ta apici alcuni senza, alcuni separati solo da TAB. Inoltre alcuni fanno un uso molto pesante del comando SYSTEM chiamando programmi esterni, comandi di AmigaOS o immagini. Da qui la decisione di ignorarli e visualizzarli in rosso , se si clicca sopra appare il Token o comando.

Installando la versione 3.0 di CanDo sul mio Amiga 600 mi sono ritrovato, dopo più di vent'anni di non utilizzo, a consultare continuamente la guida su Amiga. Cosa un poco scomoda ora che ci si è abituati bene con schermi enormi possibilità di collegare più monitor eccetera. Quindi ho cominciato a cercare un visualizzatore di file in formato AmigaGuide per MacOs, deserto quasi assoluto. Soluzione, ho iniziato a scrivere un programma per visualizzare quel formato di file, visto anche la struttura abbastanza semplice.

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 :-)

Dopo molte prove e tentativi di ottimizzare l'interprete a velocità decenti ho deciso di sospendere il progetto. Utilizzo ora molte delle funzioni scritte e in pratica tutto il tokenizer per un compilatore Z80 / Amstrad CPC  Ecco cosa vuol dire riciclare i byte usati :-)

Nuovo giorno e una nuova funzione aggiunta. Mi sono reso conto che lo schermo virtuale è comodo perché mi permetterà più avanti di cambiare quattro funzioni e adattarlo a qualsiasi output ma al costo della lentezza. Infatti la funzione odierna è SECONDS() che restituisce i secondi passati dal 1 gennaio 1970 è stata scritta proprio con lo scopo di cronometrare il tempo impiegato. Ho avuto la triste conferma con questo codice: se visualizzo il conto alla rovescia da 100 a 1 impiega ben 12 secondi ma se metto il REM davanti a LOCATE e PRINT allora il tempo è 0 secondi ;-O Per il momento proseguo così e poi si vedrà :-)

Eccoci qui e un'altro poco di codice è stato scritto Winking  Aggiunto i cicli For-Next nidificati con tanto di TO e DOWNTO oltre allo STEP. Inoltre ho creato uno schermo virtuale per l'output di 80x50 caratteri con gestione del colore tramite comando INK la paletta di 27 colori è stata ispirata dal Amstrad CPC Happy ovviamente Dimenticavo i comandi CENTER e LOCATE per posizionare il testo. Ho parecchie idee in stile CLIPPER ma per il momento procediamo un passo alla volta.

Anche oggi un mattone in più nel mio interprete, prima o poi gli darò anche un nome hahaha Ora i cicli WHILE/ENDWHILE possono essere nidificati, sono arrivato a 24, dopodiche mi sono rotto e poi avevo terminato le lettere del alfabeto per le variabili ;-) Mentre stavo scrivendo il codice ho deciso di aggiungere tre nuovi comandi AUTOINC, AUTODEC e AUTOVAL che servono a incrementare o decrementare con un valore imposto la variabile del ciclo WHILE in maniera automatica.  Così il codice risultante sarà più pulito, forse. Inoltre ho aggiunto la possibilità di formattare automaticamente le variabili numeriche e i numeri.  Ecco un esempio…

Sto ampliando e migliorando il mio interprete Basic e oggi mi sono accorto di un problema legato ad una funzione che uso da tanti anni, e mi sono reso conto di essere un pollastro ;-) La funzione in questione è Trim, siccome in LiveCode non c'era e avevo bisogno di qualcosa minimalista la scrissi così: function Trim pText return word 1 to -1 of pText end Trim Siccome lo spazio non viene considerato tipo WORD, scrivendo in questa maniera restituisco tutte le WORD dalla prima all'ultima e se ci sono degli spazi all'inizio o alla fine li salta, geniale. Ma c'è sempre un ma, in Basic per distinguere i tipi di variabili si usa mettere il simbolo $ alla fine del nome della variabile, cosi anche nel mio interprete Basic, se la riga è:  VAR Pollo$ = "Paolo" PRINT "Ciao ", Pollo$ , " bentornato!" Nella prima riga tutto bene perché Pollo$ è considerato tipo TOKEN ma se eseguo la funzione Trim nel PRINT, visto che ci sono tre segmenti separati dalla v...

Quasi tutti i programmatori della mia generazione, prima o poi si sono cimentati nello sviluppo di un interprete o in un compilatore. Oggi è stata la mia volta Happy In realtà qualche anno addietro avevo scritto un linguaggio script incluso in una applicazione che avevo sviluppato per un cliente ma questa volta è ispirato al buon vecchio linguaggio Basic. Linguaggio che tutti noi, quando abbiamo mosso i primi passi nell'uso dei nostri amati Home Computers ci siamo impegnati ad imparare, usare e abusarne ;-) Sono alla versione 0.0.1, ho iniziato a scriverlo due ore fa. E' molto rigido e al momento mancano IF e cicli FOR ma funziona. Ho usato il buon vecchio LiveCode, linguaggio che amo, evoluzione del HyperTalk e in meno di 200 linee di codice funziona :-) Ecco una foto dello schermo dove per provarlo ho scritto il classico generatore dei numeri di Fibonacci.