Comunque, il termine CRISC non è proprio da buttar via: suggerisce l'idea di un ibrido tra le due filosofie nel tentativo di unirne i pregi, che è il modo in cui mi piace pensare ai moderni CISC.
L'ISA, nel suo complesso, mi piace pensarla come CISC (non voglio uscire dal campo delle mie opinioni personali, nell'esporre il mio pensiero, perchè non ho la competenza necessaria per presentarle come una visione obiettiva e definitiva: mi limito a concordare con la "visione CISC" ), poichè le caratteristiche dell'instructin set sono quelle di un CISC e determinano il modo in cui il processore viene visto e trattato dall'esterno: il modo in cui verrà programmato, la cache dovrà essere gestita, ecc. - la conoscenza dell'implementazione interna, a mio avviso, può determinare un diverso riordino delle istruzioni o la scelta di workaround per evitare di incappare nell'esecuzione del microcodice, ma non, in generale, a uno stravolgimento totale nelle scelte inerenti la programmazione e l'ottimizzazione del codice: in generale, penso più a una
influenza sulle scelte effettuate, scelte comunque
possibili e
valide a prescindere (le istruzioni e i possibili algoritmi sempre quelli sono), ma che possono assumere un diverso rilievo in un diverso contesto: dettagli su cui giocare per lavorare di fino, insomma, piuttosto che una "condicio sine qua non".
Di conseguenza, volendo assumere come punto di partenza nella progettazione l'idea suggerita in precedenza di un'ISA basata sulle applicazioni e un hardware esposto al compilatore, ritengo che l'instruction set x86, con le sue caratteristiche di "complessità", opcode a lunghezza variabile, ecc., non possa che essere la base imprescindibile nella progettazione dell'architettura interna, pur prevedendo, questa, un'implementazione RISC-like: ben più di una interfaccia "macroscopica", magari con funzioni di retrocompatibilità, come si potrebbe pensare dando troppo risalto alle caratteristiche RISC dell'implementazione interna. Tuttavia, proprio l'implementazione interna fa da "ponte" verso un instruction set ridotto e un'architettura "simil-RISC" che ha la sua importanza, pur non avendo ragion d'essere al di fuori del suo contesto: l'implementazione e l'esecuzione ottimizzata e veloce delle istruzioni x86 (mi piace molto il termine RISC-86, in riferimento ad una unità d'esecuzione RISC di per sé, ma creata e ottimizzata sulla base delle esigenze
specifiche dell'ISA x86 da implementare: chi lo ha coniato?).
In questo senso, non mi dispiace il termine "CRISC", come
tipologia implementativa o comunque
variante in seno alla famiglia dei CISC che abbraccia in parte la filosofia RISC per trarre il meglio di entrambe. Un appunto: se R sta per Reducible può suggerire l'idea di una qualche modifica all'instruction set per farlo si rimanere di tipo "complex", ma al contempo renderlo, per l'appunto, "riducibile", sacrificando qualche istruzione o modificando in qualche modo l'opcode, o in qualunque altro modo, per facilitarne la "riduzione": che io sappia, nulla di tutto ciò è avvenuto, il tutto si riduce all'implementazione dell'architettura, o sbaglio? Personalmente troverei forse più attinente parlare di "Complex-to-Reduced Instruction Set Computer" - sperando di non fare pasticci con l'Inglese
(ok, sto cercando il pelo nell'uovo
).
Quanto a EM64T, beh, se c'è di mezzo il marketing ogni verità diventa opinabile... [acid-avoidable-mode on] poi, magari, l'indirizzamento è l'aspetto che hanno implementato meglio di AMD64 e fanno bene a metterlo in risalto, anche nel nome [acid-avoidable-mode off]
X repne scasb
Qualche tempo fa dicevi che negli A64 in modalità 64 bit è possibile che si manifesti un miglior riordino delle istruzioni e che l'uso di istruzioni "miste", in dipendenza delle dimensioni effettive dei dati contenuiti nei registri, o dei registri effettivamente utilizzati, potrebbe non portare ad un decadimento nelle prestazioni e anzi migliorarle, in alcuni casi: hai avuto altri riscontri in merito?