Computational Design (https://arkenidar.com/docs/comp-design.php) -- La progettazione dei computer richiede dei tradeoff, cioè sacrificare qualcosa per permettere qualcos'altro, come in un trading dove ogni cosa ha un costo da pagare, per cui non la si può avere o aumentare o migliorare senza pagare dei costi in qualcosa. Un tradeoff che vorrei presentare al lettore è il sistema ARM per strutturare quella che viene chiamata l'architettura dei processori d'informazioni di tipo ARM (ARM è un produttore, Intel è un produttore). Lo si può confrontare con le altre architetture commerciali quali Intel (ampliando si veda il campo delle GPU). Il tradeoff è ad esempio sul numero dei tipi d'istruzioni circuitalmente supportati, cioè supportati da specifici circuiti piuttosto che via emulazione software magari con un programma in una memoria RAM. La memoria RAM è un traguardo rispetto agli antichi sistemi ad esempio a nastro magnetico, in quanto il nastro permette accessi contigui alla posizione corrente del cursore sul nastro, mentre una RAM (Random Access Memory) è Random Access in quanto permette anche accessi non contigui, supportando l'accesso a una qualunque porzione di memoria numericamente indirizzabile (ogni parte di memoria ha un suo indirizzo di riferimento e la numerazione solitamente è progressiva). La macchina di Turing storica (della storia dell'informatica) oltre a essere a nastro magnetico e non Random Access conseguentemente, non permetteva nemmeno operazioni di basso livello sulle memorie quali i puntatori del linguaggio di programmazione C e PEEK/POKE del linguaggio di programmazione BASIC (due linguaggi ad esempio usati nei microcontrollori, dei computers ridotti sia come requisiti sia come performances). Oggi mattina leggevo di Assembly per processori con architettura ARM e loro vulnerabilità, Assembly ARM (conoscevo l'Assembly Intel, ma ho curiosato in campo ARM). Risulta che i processori ARM sono una serie di cose insieme, di vari compromessi e tradeoff. Un processore ARM usa meno silicio, meno potenza elettrica magari a favore della durata della carica della batteria. Fa meno cose in Hardware e più cose in Software, emulando quello che potrebbe essere un hardware più complesso, qualora lo si volesse (GPU come hardware estremamente complesso e specializzato in questo caso per la grafica). Un processore ARM è ad architettura di tipo RISC (Reduced Instruction Set Computer), è ridotto ed è economico. Riducendo il numero di tipologie d'istruzioni si semplifica qualcosa. Ed è questa semplicità apprezzabile che cercavo di ottenere con i "miei" design di macchine di calcolo computazionale, tra cui Arkenidar's RESM una quasi macchina di Turing che usa una memoria elettronica RAM al posto di un nastro magnetico. È una soluzione conosciuta, strada chiaramente già percorsa in lungo e in largo. Ma a me serviva imparare così mi sono cimentato. Ieri volevo estendere il design di RESM (questa macchina di Turing a RAM) per supportare l'accesso indiretto alla memoria, ovvero usare una porzione di memoria per contenere non un dato immediato bensì un indirizzo variabile al quale un dato può essere acceduto (sia per scriverci che per leggerci i dati contenuti in memoria). Chi conosce l’Assembly o il linguaggio C sa che questo lancia la possibilità di avere array (costrutti piuttosto fondamentali), magari usabili anche per un modesto stack non infinito basato su un array e un indice (o un indirizzo) al quale/dal quale si leggono/scrivono i dati in cima allo stack (che infatti significa "pila" di elementi in memoria, stack di memoria, e quindi cose come gli stack pointers, puntatori di memoria). Un campo di applicazione degli stack come strutture di memoria è il call stack, ovvero quando una sottoparte di programma viene attivata viene posta in cima alla pila dello stack e quando termina viene rimossa in modo da tornare da dove si era venuti prima dell’attivazione di quel sottoprogramma corrente. RESM usa solo due istruzioni (bit copying+program jump) e ha RAM e ROM separate (la ROM Read Only in quanto il programma non muta, la memoria di lavoro RAM invece si). Potrei usare forse un unificato sistema di memoria, ma già questo presenta tradeoffs dilemmatici. Ma la cosa che volevo dire dopo queste premesse (e condivisioni spiegate) è che la flessibilità di un sistema meno hardware e più software (nel suo equilibrio) diventa: economia di transistors necessari ai circuiti, flessibile nonostante ma a costo di una velocità ridotta rispetto a un CISC Intel, e non ultimo presenta problemi di sicurezza, perché più un sistema è flessibile più è anche abusabile e sfruttabile (infatti sfruttabile nel bene e nel male). Questi sono anche problemi di sicurezza hardware e vulnerabilità hardware (campo nuovo per me, per cui scrivo questi appunti, tra exploit per ARM (per me scoperta di oggi 11 Maggio 2021) e vulnerabilità già note d'Intel quali Meltdown e Spectre). Per approfondire si può vedere l'architettura delle GPU (graphic processing units) variamente programmabili (e direi anche vulnerabili!). Perché l'interesse verso i programmi software? Mi dedico allo studio di come costruirli, tra combinazioni di piacere e dovere e lavoro e servizio restituito agli altri per il fatto di esistere su questo pianeta (cerco di rendermi utile e lasciare buone tracce storiche). Perché l'interesse verso l'hardware? Perché senza una qualche fisicità i computer non potrebbero messi in esistere. E le scelte hardware diventano condizioni impattanti chi scrive la parte software che dà loro "vita" e comportamento utile. E l'hardware da adottare determina anche le possibilità e i limiti, le risorse e i costi con cui un programmatore deve fare i conti (nonostante si cerchi di alleggerire i programmatori da questi oneri, ma questi non sono soltanto oneri ma anche possibilità di comprensione). Ignorare o sapere?, far ignorare o fare sapere? Dilemmi su dilemmi. Open Source per il software e Hardware opensource? Flessibilità? Sicurezza? Costi? Performances? Etc