68000 vs. 65C816
Quando si fanno discorsi su quale prodotto hardware sia meglio o peggio di un altro, si finisce puntualmente per inoltrarsi su un terreno accidentato. Spesso due dispositivi di una stessa categoria (ad esempio due processori o due chip sonori, o soprattutto due computer) sono talmente diversi da non permettere un verdetto definitivo. Anzi, la maggior parte delle volte, l’unico verdetto possibile è che i due ammennicoli sono – per l’appunto – diversi. Quando a questo dovesse aggiungersi il fanboyismo di alcuni soggetti particolari, strenui difensori di questa o quella architettura, il flame sarebbe inevitabile. Tralasciando le possibili implicazioni psicoanalitiche di quest’ultimo fenomeno, di cui un giorno o l’altro mi piacerebbe discutere con un esperto in materia, vorrei approfondire il confronto venuto fuori ultimamente tra i processori 68000 e 65C816.
Non essendo io un programmatore assembly, ho reperito su Internet le informazioni necessarie, principalmente da queste due fonti:
http://www.faqs.org/faqs/motorola/68k-chips-faq/http://gilgalad.arc-nova.org/junk/65816/65...ogrammanual.zip65C816
- Bus indirizzi: 24 bit (max 16Mb indirizzabili)
- Program counter a 16 bit: gli indirizzi di programma a 24 bit sono ottenuti tramite concatenazione con un apposito registro a 8 bit (Program Bank Register)
- Stack pointer a 16 bit
- ALU a 16 bit
- 3 registri programmabili (accumulatore e registri indice (X, Y)) a 16 bit; Gli indirizzi a 24 bit per i dati sono ottenuti concatenando ai registri a 16 bit gli 8 bit del Data Bank Register
- Bus dati a 8 bit
- Interrupt non prioritizzati
- Istruzioni su operandi a 8 e 16 bit
68000
- Bus indirizzi: 24 bit (max 16Mb indirizzabili) ma la memorizzazione e il calcolo degli indirizzi sono effettuati internamente a 32 bit, in modo che si possano scrivere programmi capaci di utilizzare il bus a 32 bit previsto per le future versioni della CPU (foreward compatibility)
- Program counter a 32 bit, senza paginazione o segmentazione
- Stack pointer a 32 bit
- ALU a 16 bit
- 8 registri programmabili a 32 bit
- Tutti i registri di indirizzo interni sono a 32 bit
- Bus dati a 16 bit
- 7 livelli di priorità per gli interrupt (il livello 7 è non mascherabile, cioè NMI)
- Istruzioni tipo "byte", "word" e "long", tramite suffissi aggiunti ai codici mnemonici (ad esempio sub.l, move.w)
- 2 livelli di privilegio, ognuno col suo stack pointer, permettono di creare ambienti multitasking con poca RAM
Il 65816, stando ai risultati delle comparazioni tecniche che ho trovato in alcuni forum, dovrebbe essere sensibilmente più veloce del 68000 in termini di cicli macchina necessari per le istruzioni. Ma questo dislivello è compensato (o forse superato) grazie alla gran quantità di registri del 68000, che aiutano a limitare di molto la necessità di continui accessi alla RAM. Quello che veramente rendeva inadatto – a mio avviso – l’uso del 65816 in un computer di una certa complessità e prospettiva di evoluzione, è il fatto che questa CPU rappresentasse sostanzialmente il capolinea di una vecchia architettura (il 6502 a 8 bit), mentre il 68000, seppure non dotato di eccezionale velocità “pura” (almeno nella sua incarnazione iniziale), aveva altri pregi. Possedeva 2 livelli di privilegio, ognuno col suo stack pointer, il che permetteva di creare ambienti multitasking anche con poca RAM e aveva 7 livelli di priorità per gli interrupt. Ma soprattutto “guardava avanti”, con i suoi registri interni a 32 bit, il suo supporto nativo alle istruzioni aritmetiche a 32 bit e specialmente la sua predisposizione a un bus indirizzi a 32 bit, che infatti arrivò con il 68020. Il 68000 è stato il punto di partenza di una gamma di processori che si è evoluta negli anni sotto molti aspetti, tra cui la frequenza di clock: potrei sbagliare ma non mi risulta che il 65816 abbia mai superato i 20 MHz, mentre uno '060 funziona tranquillamente a 50 MHz (75 nelle versioni senza FPU e/o MMU) e un ColdFire (tuttora in produzione e recentemente impiegato in
un super-clone dell'Atari ST) arriva fino a 300 MHz. Non mi addentro nei discorsi sulle cache, sul pipelining e altro, ma anche queste caratteristiche hanno avuto un impatto sulle prestazioni dei modelli più avanzati: posso bene affermarlo nonostante la mia scarsa preparazione in materia, per avere osservato il calo di prestazioni che sopraggiunge quando queste vengono disattivate.
Amiga: le premesse, il successo, le cause della “fine”
Ogni problema ha le sue soluzioni e quindi non ha senso affermare (ad esempio) che il ferro è meglio del legno: ognuno è adatto per una certa gamma di impieghi. Allo stesso modo credo che il 65816, adattissimo a console per videogiochi come il Super Nintendo, non fosse adeguato ai requisiti di complessità, versatilità ed espandibilità che un computer commercializzato in quell’epoca doveva possedere. Non sono affatto d’accordo con chi dice che l’errore della Commodore, che l’avrebbe poi portata al fallimento, sia stato proprio l’acquisizione e commercializzazione di Amiga. La Commodore da un bel pezzo andava a tentoni con risultati pessimi (C16/Plus4, C128, C900, C65) per incompetenza strategica ma anche tecnica (i cervelloni erano scappati durante la progettazione della linea 264). Decisero di realizzare un progetto di terzi che, se gestito diversamente, avrebbe potuto garantire una sopravvivenza molto più lunga all’azienda.
Il già citato 68020, secondo il mio parere, doveva essere adottato come entry level già nel ’92, se non prima. Invece l’uscita dell’Amiga 1200 con il 68EC020 (quindi ancora un bus indirizzi a 24 bit, come nel 68000 originario) e un chipset audio/video assolutamente obsoleto per l’epoca, convinsero molti sviluppatori che il destino della piattaforma fosse ormai segnato, vista anche la scarsa diffusione di sistemi A3000 e A4000 dotati di schede grafiche e acceleratrici al passo con la concorrenza.
Secondo me bisognava smetterla con i computer “incorporati nella tastiera” e vendere (a prezzi contenuti) SOLO i desktop e i tower, incoraggiando in tal modo la commercializzazione di schede audio, video, di rete ecc. Il chipset audio / video nativo, che era stato determinante nel decretare il successo iniziale di Amiga, andava coraggiosamente abbandonato, cedendo il passo alle controparti su slot Zorro. La Commodore avrebbe dovuto sobbarcarsi l’onere di sviluppare delle API standardizzate per il funzionamento delle schede aggiuntive, senza aspettare che terze parti proponessero i vari AHI, Picasso96, CybergraphX ecc. Bisognava fornire un bello scandoubler di serie per non perdere la possibilità di usare il vecchio software, schede acceleratrici (in un secondo tempo anche PPC) a prezzi competitivi e si doveva escogitare una campagna pubblicitaria atta a presentare queste macchine come ottimi strumenti di lavoro, alla stregua, se non meglio, di PC e Mac. Credo che in tal caso l’Amiga e la Commodore sarebbero durate molto di più, ma ovviamente non sapremo mai se ho colpito nel segno o se ho preso una gran cantonata.
Un successore compatibile per il Commodore 64
In questo ed altri thread si è spesso parlato di un computer che la Commodore avrebbe potuto / dovuto commercializzare quale “erede” del C64 e se questo dovesse o meno mantenere la compatibilità con il suo antenato. Io credo che questa strada sarebbe stata percorribile nel periodo in cui la Commodore si concentrava invece sulla serie 264: in quel momento aveva senso tentare di ampliare le possibilità del 64 mantenendo la compatibilità con il vecchio software (e quindi, inevitabilmente, con le vecchie periferiche). Ma attorno al 1985 cominciava l’era dei 16 bit e, come ho avuto modo di dire in precedenza, il gap tecnologico diventava talmente ampio che non aveva più senso spendere risorse e tempo per inseguire la compatibilità con il passato: le vecchie applicazioni potevano essere, per la maggior parte, riscritte in un linguaggio evoluto come il Basic e ciononostante offrire prestazioni migliori. I videogames di un tempo potevano essere tranquillamente accantonati dal giocatore medio, rapito dalle superiori possibilità tecniche delle nuove macchine. Per l’appassionato più incallito, restava comunque la scelta di tenersi il vecchio computer, a cui affiancare il nuovo.
Tornando all’ipotetico successore del Commodore 64, nonostante sia questo un discorso in cui la fantasia fa da padrona, volevo precisare che nel 1985 lo standard SCSI non era ancora stato formalizzato (
http://www.pcguide.com/ref/hdd/if/scsi/over-c.html - «The first "true" SCSI interface standard was published in 1986») e che sempre a quell’epoca 16 Mb di RAM per il mercato consumer erano fantascienza. Infine, ritengo che il supporto agli undocumented opcodes da parte di questo computer "virtuale" doveva essere necessariamente fornito dal processore, non essendo possibile un’emulazione software (su questo punto resto in attesa di smentite o conferme da parte degli esperti di assembly).
