Paolo Borzini - Pixel & Pensieri

BLOG di Paolo Borzini Ovviamente il titolo è una provocazione. O forse no. Oggi pomeriggio sono stato all’inaugurazione di un negozio di cui conosco i titolari e tre quarti delle persone presenti. Ho augurato loro buona fortuna per questa nuova apertura. Un augurio che viene dal cuore. Non soltanto perché si desidera il meglio per chi apre un negozio, soprattutto in un periodo di acquisti online, ma anche perché, da ex piccolissimo imprenditore, vedo tutto questo come un’ulteriore tappa, un’altra casa verde costruita sul vero tabellone del Monopoli che è la vita imprenditoriale. Poi, da bravo nerd, mi sono posizionato accanto al punto ristoro e al distributore di birra. Perché è un ottimo punto strategico. Ho cominciato a parlare con una persona che conosco da quasi trent’anni. Abbiamo amici in comune e ogni volta ci scambiamo i soliti convenevoli: «Stai bene?». «Sì, tutto bene. E tu?». Poi, non si sa come, siamo finiti a parlare di IA. Il mio interlocutore non è una persona qualsiasi,...

BLOG di Paolo Borzini Questo è il seguito del post precedente Il C come il Latino Il latino ha un lato affascinante che può essere fuorviante, sembra libero, ma non è anarchico. Prendiamo una frase semplice: F los puellam amat ovvero  Il fiore ama la ragazza. Qui l’ordine è abbastanza lineare: soggetto, oggetto, verbo. Ma posso anche scrivere:  Puellam flos amat E il significato grammaticale di base non cambia. È sempre il fiore che ama la ragazza. Perché? Perché  flos  resta nominativo, quindi soggetto. E  puellam r esta accusativo, quindi complemento oggetto. La desinenza, in latino, è una specie di cartellino identificativo. Ti dice chi fa cosa, anche se sposti le parole. Però attenzione, questo non vuol dire che l’ordine non conti, conta eccome. Solo che spesso non decide il significato di base ma decide l’enfasi, il ritmo, lo stile, la sfumatura. Flos puellam amat Il fiore ama la ragazza. Puellam flos amat È la ragazza che il fiore ama. La ragazza viene por...

BLOG di Paolo Borzini Ieri stavo comunicando con un gruppo di lavoro per un progetto in cui sono impegnato da quasi due anni. Per stemperare l’atmosfera ho scritto una frase in latino, anche per spolverare un po’ i vecchi ricordi scolastici. Ovviamente, non conoscendo il latino, l’hanno data in pasto a Google Translator, che più o meno l’ha tradotta correttamente. Il latino è una lingua semplice e complicata allo stesso tempo. Ed è lì che mi è venuta in mente una domanda, ma se dovessi paragonare il latino a un linguaggio di programmazione, quale sceglierei? Io sceglierei il C. Perché il latino è compatto, poche parole, ma ciascuna porta con sé molte informazioni: caso, genere, numero, tempo verbale e via discorrendo. Il C fa qualcosa di simile, poche istruzioni, ma molto significative. È rigoroso, una declinazione sbagliata può cambiare il senso di una frase, come un ; o un * sbagliato in C può cambiare il comportamento di un programma. È una lingua fondante, dal latino derivano itali...

 BLOG di Paolo Borzini Linguaggi complicati e linguaggi semplici Ogni tanto torna fuori la solita discussione. C# e Swift sarebbero linguaggi “seri”, mentre BASIC e LiveCode sarebbero linguaggi “semplici”, quasi figli di programmatori minori ;-) Secondo me, il punto non è questo. La vera differenza non è tra linguaggi nobili e linguaggi della plebe. È tra due filosofie opposte di programmazione. Da un lato ci sono linguaggi come C# e Swift che sono pensati per progetti grandi, team numerosi, codice che deve durare nel tempo e passare attraverso molte mani. La loro rigidità ha uno scopo ben preciso ed è quello di spostare il più possibile sul compilatore il compito di fermare gli errori prima che il programma venga eseguito. Dall’altro lato ci sono linguaggi come BASIC e LiveCode, che seguono una tradizione diversa. Privilegiano accessibilità, rapidità e libertà espressiva oltre che alla leggibilità del codice. Questo però non significa assenza di controlli. Esistono BASIC compilati...

BLOG di Paolo Borzini   Ritorniamo alle origini del Blog ;-) Nel mondo del retrocomputer, tra le macchine blasonate, famose, stravendute o sconosciute, c’è una cosa che le accomuna ed è la CPU. Il processore, il cuore o meglio il cervello del computer, della macchina. Tra le CPU di questo gruppo eterogeneo spicca lo Z80, progettato da Federico Faggin dopo la sua fondamentale esperienza in Intel, dove aveva contribuito a dare i natali al primo microprocessore commerciale, l’Intel 4004, e al leggendario 8080. Lo Z80 non fu una semplice evoluzione; fu una rivoluzione in silicio. Faggin, con la sua nuova azienda, la Zilog, partì dal progetto dell’8080 per creare un processore non solo più potente, ma anche infinitamente più elegante e pratico da usare per i progettisti. Mentre il suo “cugino” Intel 8080 richiedeva tre tensioni di alimentazione diverse e un intricato circuito di supporto per funzionare, lo Z80 si accontentava di un unico, semplice +5V. Questo lo rese, fin dal suo esordi...

Questo blog era nato anni fa per parlare di computer. Anzi, di retrocomputer e di programmazione. Nel tempo si è evoluto: dopo aver scritto per anni di macchine che – chi più, chi meno – hanno segnato l’epoca informatica tra la fine degli anni ’70 e l’inizio dei ’90, e dopo aver raccontato lo stato dei miei progetti informatici (soprattutto compilatori e interpreti), ho iniziato a condividere anche pensieri, riflessioni e letture accumulate nel corso del tempo. Oggi però voglio fare un passo indietro. Anche perché, durante l’incontro “Incontra l’autore” all’interno del BissaBook, oltre alle domande sul libro, molte persone mi hanno chiesto informazioni sullo splendido Amstrad CPC 6128 Plus che avevo portato con me. E che – piccola nota d’orgoglio – ha funzionato per tutte le tre ore (e oltre) in cui sono rimasto al tavolo. Un computer con 36 anni di vita, mica uno di quei gingilli moderni che si piantano appena aggiorni il sistema operativo. E con lo stesso editor di testi che usavo al...

 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.