Parlare di un microprocessore in maniera non banale richiede un certo sforzo. Bisogna infatti andare a caccia di documentazione adeguata, con lo user o reference manual in qualità di prima scelta (anche se in genere si tratta di tomi di centinaia e centinaia di pagine) poiché riportano le informazioni più dettagliate sul suo funzionamento.
Ciò è tanto più difficile quanto più vecchio e/o raro è il pezzo di silicio in questione, e riuscire a trovare qualcosa di decente diventa spesso un’impresa notevole. Capita, infatti, tante volte di perder più tempo a cercare che a studiare il materiale trovato.
Potete immaginare, quindi, cosa possa comportare dover recuperare fonti su un processore che… non è mai stato rilasciato! E di cui, com’è possibile intuire, non ci sono manuali né recensioni o altro che possa anche far pensare a cosa poteva essere.
Internet da questo punto di vista non è più un’amica a cui rivolgersi nel momento del bisogno, e una ricerca può non fornire nulla, oppure portare anche a centinaia di migliaia di risultati ma che sono per lo più inutili.
E’ quel che è successo col Motorola 68050, CPU a cui stava lavorando Motorola dopo il fenomenale 68040, che ha cancellato in corso d’opera per concentrarsi su quel che sarà poi stato un altro capolavoro, il 68060.
Pochi e quasi sempre senza fonti i dati presenti in giro, per lo più frutto di speculazioni o di voci che, sembra, circolassero all’epoca. Wikipedia è su questa linea, anche se alcune cose sono condivisibili (e ne parlerò meglio dopo).
Una fonte che sono riuscito a recuperare cita una prestigiosa e rinomata rivista del settore, Microprocessor Report, etichettando il 68050 come “aggiornamento minore” che è stato sacrificato dalla casa madre per concentrare le risorse sulla versione a basso consumo (e costo) del 68040 (sarà poi il 68EC040/V) e sul nuovo progetto in lavorazione (il 68060) che avrebbe dovuto garantire ben più alte prestazioni (addirittura migliori dei primi PowerPC).
Non faccio fatica a crederlo, perché uno dei grossi problemi che ha avuto il 68040 è stato proprio quello dell’eccessivo consumo, che ha avuto come conseguenza anche quello di limitarne fortemente la scalabilità in frequenza, che si è fermata a soli 40Mhz (per confronto, l’80486 dell’acerrima rivale Intel è arrivato a 100Mhz). L’architettura particolarmente complicata ha sicuramente contribuito a questo grosso limite, e ne riparleremo in un futuro articolo.
D’altra parte con la “serie dispari” Motorola ha sempre proposto dei bug fix rispetto alla versione precedente, con qualche miglioramento atto a non stravolgerne il progetto. Lo è stato il 68010, che ha corretto un grosso bug, introdotto la virtualizzazione, e aggiunto un meccanismo per accelerare l’esecuzione di piccoli loop, rispetto al 68000.
Il 68030 ha portato molte più innovazioni (MMU integrata, bus con nuove e veloci modalità di accesso alla memoria, cache dati e architettura parzialmente Harvard), ma la base rimane sostanzialmente quella del suo predecessore, il 68020, con la pipeline a tre stadi e l’overlapping delle istruzioni.
Lecito attendersi che il 68050 fosse basato sul 68040, cercando di eliminarne alcuni problemi (fra questi sicuramente il calore dissipato e clock più elevati; qui sono d’accordo con Wikipedia) e migliorando qualche parte dell’architettura per ottenere qualche vantaggio in termini prestazionali.
Gli scarsi risultati su quest’ultimo fronte potrebbero aver dato il colpo di grazia al progetto, come in parte è possibile rilevare da un’altra fonte, la NeXT di Steve Jobs che costruiva workstation grafiche basate sul 68040 e che, quindi, intratteneva rapporti commerciali con Motorola.
D’altra parte attendersi significativi aumenti di velocità quando il predecessore era già in grado di erogare l’impressionante valore di 20MIPS a 25Mhz è poco plausibile, se non si decide di stravolgere l’architettura.
Le innovazioni avrebbero potuto essere fra le seguenti:
- aumento della dimensione delle cache
- integrazione di una logica di predizione dei salti
- utilizzo di un push buffer e/o di uno store buffer
- address generator ottimizzato anche per modalità più complesse
- ALU ottimizzata anche per istruzioni più complesse
- FPU più avanzata e/o ottimizzata
La via più facile è sempre la solita: aumentare le cache. Quindi portare la cache codice e/o dati da 4 a 8KB. Non considero tagli “intermedi”, quindi non potenze di due, perché complica leggermente l’implementazione e Motorola all’epoca ha sempre prediletto la soluzione “intera” (niente frazioni di potenze di due).
Non è però quantificabile il beneficio ottenibile, perché dipende dall’ISA e da come venga sfruttata dalle applicazioni. Di certo, però, avrebbe aumentato sensibilmente i costi, perché la cache occupa una parte consistente del chip. Inoltre aggiungere altre centinaia di migliaia di transistor avrebbe fatto aumentare anche i consumi e il calore dissipato. Quindi non credo che Motorola avrebbe percorso questa strada.
L’inclusione di una sezione di predizione dei salti avrebbe comportato notevoli vantaggi prestazionali (nel caso di predizioni corrette), ma avrebbe richiesto delle modifiche consistenti alla pipeline, oltre a dover fare i conti sempre coi consumi, considerato che si tratta di un’unità particolarmente stressata.
Push buffer e store buffer sono meccanismi che aiutano le operazioni di scrittura in memoria (di cui parleremo meglio nell’articolo sul 68060), e avrebbero potute essere ragionevolmente inclusi nel chip. Il primo avrebbe comportato una leggera modifica alla struttura della cache dati, ma niente di trascendentale.
Uno dei talloni d’Achille della famiglia 68000 è rappresentato dall’introduzione di modalità d’indirizzamento indirette, che sono sicuramente utili, ma particolarmente complicate da decodificare ed eseguire.
Quando l’unità di esecuzione del 68040 ne trova una nello stadio di calcolo dell’indirizzo, è costretto a stallare la pipeline fino a quando non riesce a recuperare dalla cache o dalla memoria il puntatore da utilizzare successivamente per il calcolo dell’indirizzo finale.
Una soluzione sarebbe potuta essere quella di aggiungere ai 6 già presenti un ulteriore stadio dedicato allo scopo, ma questa modifica della pipeline non è banale, e avrebbe comportato un’ulteriore penalizzazione di 1 ciclo di clock nelle istruzioni che prevedono un cambiamento nel flusso dell’esecuzione.
In ogni caso avrebbe risolto a metà il problema, perché un’istruzione MOVE permette di specificare due indirizzi di memoria, e ognuno di essi può tranquillamente prevedere l’uso di una modalità indiretta. Le istruzioni, in questo modo, possono essere lunghe fino a 22 byte!
I miglioramenti all’ALU sono sicuramente possibili, ma indirizzati alle istruzioni più usate. Il 68040 aveva già fatto un ottimo lavoro da questo punto di vista, difatti i 20MIPS si ottenevano proprio tenendo conto di tutto ciò.
Personalmente avrei gradito una velocizzazione nella manipolazione dei campi di bit, che ritengo particolarmente utili, anche se non si tratta di istruzioni comuni e/o frequenti, e il cui uso va “ricercato”.
Non vedo margini per l’FPU, visto che aggiungere altre istruzioni (considerato che ne mancano parecchie, in particolar modo quelle trascendentali, che devono essere emulate via software) è una strada esattamente opposta a quella che ormai aveva intrapreso Motorola.
Mentre ottimizzarne le circuiterie deputate ai calcoli veri e propri non so quanto fosse fattibile; in ogni caso, non essendo del ramo, non mi sento di poter esprimere nulla a riguardo. Sottolineo soltanto l’idea che mi sono fatto, cioè che la casa madre ha sempre privilegiato l’unità di esecuzione intera anziché quella in virgola mobile.
Non ci sono informazioni per capire quali scelte aveva effettuato Motorola per il 68050, ma spero che le riflessioni fatte risultino ragionevoli e plausibili. Alcune di esse le ritroveremo nel 68060, e in generale valgono anche per l’intera famiglia; si capirà più facilmente, quindi, perché potevano essere presenti nel progetto cancellato da Motorola…
