di  -  mercoledì 3 marzo 2010

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…

28 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    D
     scrive: 

    Ai tempi quale mercato avevano queste cpu ?
    Sale giochi e home computer o anche soluzioni workstation e server di fascia alta ?
    Lo 050 non aveva bisogno di essere rivoluzionario per continuare la tradizione, avrebbe potuto benissimo essere un progetto intermedio per tirare a campà ma è ovvio che se non c’era il mercato dove impiegarlo…

  • # 2
    Cesare Di Mauro (Autore del post)
     scrive: 

    Workstation in primis (vedi il link a NeXT) e server.

    Ma anche soluzioni desktop di fascia alta.

    Non penso agli arcade, perché si tratta di CPU particolarmente costose. Diciamo che dopo un po’ di anni sarebbero state abbordabili come prezzo.

  • # 3
    MetalMork
     scrive: 

    Ricordo una leggenda metropolitana dell’epoca, che dava il 68050 come prodotto solo a uso militare e quindi non commercializzato dalla Motorola…

  • # 4
    Warfox
     scrive: 

    Pensa che c’e’ un gruppo che sta’ sviluppando un 68070 basato su un moderno FPGA programmabile.. :)

  • # 5
    Cesare Di Mauro (Autore del post)
     scrive: 

    Ho già previsto un articolo, infatti. :-P

  • # 6
    Warfox
     scrive: 

    A dirti la verita’ non vedo l’ora che rilascino la motherboard pubblica.. la comprerei anche solo per l’impegno messo sul progetto.. :) Poi vuoi mettere. tornare a programmare in assembly 680×0 su una macchina 100/200 volte + veloce dell’amiga originale? :D

  • # 7
    Cesare Di Mauro (Autore del post)
     scrive: 

    Bisogna vedere come lo portano avanti questo progetto. Ci sono delle cose che non mi piacciono.

    Ne parlerò meglio nell’articolo, così vediamo cosa ne pensano i vecchi volponi che lavoravano in assembly con queste fantastiche macchine. :)

    P.S. Sulle prestazioni è tutto da vedere, ovviamente.

  • # 8
    Warfox
     scrive: 

    Ovviamente concordo, almeno sulla parte prestazioni..anche perche’ non e’ chiaro il clock dell’fpga che verra’ usato.. ne per la parte 070 ne per il superAga. In ogni caso ti assicuro (visto che ogni tanto la uso) che il povero vecchio A1200 con 060 fa’ vedere tutto il peso dei suoi anni e soprattutto di Aga. Soprattutto sulla parte grafica con il workbench a 640×512 ad esempio si vede tutta la limitatezza della banda passante.. Beninteso.. io la sto’ cercando di usare come una macchina moderna.. :)
    Poi per paciugare con il chipset invece e’ ancora una goduria.. l’ultimo algoritmo di chunky2plane che ho scritto per lo 060 gira a 40 fps.. :) e avanza ancora 2/3 di schermo raster (e scommetto che sai cos’e’.. ;) )

  • # 9
    Warfox
     scrive: 

    sorry.. 50 volevo dire.. :)

  • # 10
    Schianto
     scrive: 

    Ci sarebbe anche da aprire un capitolo sulla nuova famiglia Coldfire, che è una reingegnerizzazione della famiglia 68K…

  • # 11
    Cesare Di Mauro (Autore del post)
     scrive: 

    @Warfox: parliamo la stessa lingua. :D

    E prima o poi ci sarà una serie (spero lunga) di articoli in cui parlerò di ogni singolo aspetto dell’hardware dell’Amiga, di come si programmava, e di com’era una goduria spremere come un limone il 68000 e la roba mappata alle locazioni da $DFF000 in poi (e qui scommetto che anche tu sai cos’è :D).

    Limiti inclusi, ovviamente (e credo che questa sarà la parte più interessante, perché si tratta di roba rara e poco nota).

    @Schianto: è in programma una serie di capitoli pure per quella famiglia. Ho scaricato tonnellate di user manual su ColdFire e DragonBall (c’è anche questa famiglia) che aspettano soltanto di essere divorati e i relativi articoli. ;)

  • # 12
    iva
     scrive: 

    A parte Natami (il progetto con il 68070) recentemente c’e’ stato anche un aggiornamento al minimig, c’e’ un video dove e’ dimostrato il supporto AGA:
    http://www.amiga.org/forums/showpost.php?p=544283&postcount=8

    ps nell’altro post avevo detto di aver deciso per un 68030 con 1200, pero’ ho trovato l’occasione su ebay con A4000 con 68040 e non ho resistito :)

  • # 13
    Warfox
     scrive: 

    @iva
    Beh.. natami vorrebbe andare oltre AGA… un po’ quello che avrebbe dovuto/potuto essere hombre.

    @Cesare.
    Chesso’.. tipo $dff058? oppure i registri dal 180 in poi :D

  • # 14
    D
     scrive: 

    “Workstation in primis (vedi il link a NeXT) e server.”

    Beh NeXT non è certo un campione commerciale molto ampio da giustificare chissà quale impegno in ricerca e sviluppo. Ci sono altri nomi che hanno goduto di un successo commerciale accettabile ?
    Lo chiedo perchè a conti fatti la strategia di motorola semplicemente si riassumeva in: “realizzo il processore figo -> sego fpu ed mmu e vendo la versione low cost”, mentre invece se avesse avuto un peso notevole sul lato pro avremo avuto una strategia del tipo “realizzo il processore figo -> me ne frego di costi e consumi realizzando il fratellone super figo con cache doppia/quadrupla, fpu migliorata e magari pure una versione MP” e adesso staremo a parlare di 68k grossi come dei Power 6 infilati in cluster da N migliaia di nodi.

  • # 15
    Warfox
     scrive: 

    Workstation Unix HP basate su 680×0 bastano?
    Sun 1/2/3.. poi decisero di farselo in casa..

  • # 16
    Cesare Di Mauro (Autore del post)
     scrive: 

    @iva: minimig è un altro progetto che andrebbe analizzato.

    Comunque dal link che hai postato noto un errore che si continua a commettere: limitare la chip ram. Va bene che gli AGA avevano come tetto massimo 2MB, ma personalmente avrei esteso almeno a 8MB questo tipo di memoria, perché è estremamente importante in un’architettura come quella dell’Amiga.

    Hai fatto bene a prendere il 4000, ma spero non ti sia costato molto. :)

    @Warfox: concordo. I 680×0 era usatissimi all’epoca. NeXT era soltanto l’ultima arrivata.

    @D: le versioni MP in realtà sono gli stessi 68040 che col bus snooping permettevano di realizzare sistemi multiprocessore a basso costo ed elevata efficienza.

  • # 17
    iva
     scrive: 

    @Warfox: si Natami “dovrebbe” andare oltre AGA, infatti il chipset su cui stanno lavorando mi pare l’abbiano chiamato superAGA, pero’ e’ un progetto chiuso e di cui ancora non e’ affatto chiara una data di rilascio – il loro obiettivo e’ molto ambizioso, speriamo bene…

    @Cesare: si, infatti da qualche parte avevo letto di un tetto di 48 MB di chip, adesso non trovo il link pero’ :(
    Il 4000 non e’ costato tanto, solo un poco di piu’ di un 1200 in buono stato piu’ una scheda con 68030… adesso sono in attesa di trovare una Picasso IV e poi sono a posto almeno fino a Natale :)

  • # 18
    josehalapeno
     scrive: 

    @Warfox

    Prepara anche un algoritmo per scrivere in italiano, visto che Fa, verbo fare presente terza persona singolare si scrive senza apostrofi o accenti, idem per sto sta eccetera. Inoltre ne si scrive nel tuo contesto né specialmente se ripetuto e sorvoliamo sull’uso dell’apostrofo invece dell’accento.
    Puoi anche essere bravo in programmazione dell’Amiga ma quando leggo certe cose cadono le braccia…

  • # 19
    Warfox
     scrive: 

    Non credevo di essere tornato a scuola, ne tanto meno che il mio italiano fosse oggetto del post. In ogni caso c’e’ gente che usa la tastiera inglese e non quella italiana e che magari mentre risponde ad un blog sta facendo moolto altro e quindi non ha ne tempo ne voglia di correggere e/o scrivere in italiano corretto. Ad ogni modo quando avro’ tempo per ripetizioni di italiano ti chiamo.. ok?

  • # 20
    D
     scrive: 

    “Workstation Unix HP basate su 680×0 bastano?”

    Poi anche loro hanno mollato la barca e se le sono fatte da soli.
    La domanda adesso è: il cambiamento è avvenuto dopo lo 060 o prima ?

  • # 21
    Warfox
     scrive: 

    Molto prima credo di aver visto le ultime Hp con lo ‘030. Lo 060 era ormai sulla dead-line di motorola. L’ultimo processore ad aver avuto successo commerciale e’ stato lo 040. Credo ci siano ragioni anche storiche per l’abbandono di Sun e HP che sono saltati sul carro dei risc. La convinzione era che solo i risc avrebbero potuto garantire le prestazioni per i grossi mainframe Unix di allora e questo ha spinto entrambi a progettarsi in casa il PA-Risc e i vari SParc. 060 era invece la dimostrazione che un core risc con un unita’ di traslazione delle istruzioni poteva dare ottimi frutti (come del resto sono gli intel x86 attuali). Ma ormai era tardi, motorola puntava e lo diceva da tempo su PPC. Quindi non aveva senso per nessun produttore investire sull’ultimo 680×0.
    La cosa triste e’ che il PPC 601 a 60Mhz era piu’ lento di uno 060 a 50Mhz e nemmeno di poco.

  • # 22
    D
     scrive: 

    Ah bhè se la prima che non credeva nel progetto 68k era proprio motorola non ha senso continuare questa discussione.

  • # 23
    Marco
     scrive: 

    “Ai tempi quale mercato avevano queste cpu ?”

    Oltre ovviamente ad una discreta fetta del mercato desktop con Apple, Atari e Amiga, a livello di workstation vorrei ricordare anche Apollo e le prime Silicon Graphics (fino allo 030 almeno).
    In ambito “mini” Bull e Honeywell fino a 8 CPU (grazie alla logica glueless SMP integrata), i sistemi MVME in ambito industriale (diffusissimi ancora oggi!!!) e con le serie EC nell’embedded fra PBX, automotive, networking, stampanti, fax e quant’altro.
    Dello 040 e 060 esistono anche versioni CMOS statiche che sono state utilizzate anche in ambito aerospaziale.

    @Warfox
    “vuoi mettere. tornare a programmare in assembly 680×0 su una macchina 100/200 volte + veloce dell’amiga originale?”

    Per quello ti basta UAE xD

  • # 24
    Marco
     scrive: 

    “La cosa triste e’ che il PPC 601 a 60Mhz era piu’ lento di uno 060 a 50Mhz e nemmeno di poco.”

    Hai dei dati per supportarlo? Sembra quantomeno bizzarro, dato che il 601 era già OOO (sebbene con una instruction window piuttosto ridotta) e soprattutto in FP mi sembra di ricordare che avesse prestazioni veramente al top.

  • # 25
    warfox
     scrive: 

    Ai tempi si usava misurare la potenza di calcolo in MIPS.. sebbene molto rozzo dava un idea delle prestazioni. Il 68060 a 66 Mhz era accreditato di 88 Mips..
    http://en.wikipedia.org/wiki/Instructions_per_second

    Il ppc 601 a 66 Mhz era accreditato di 63 Mips.

    http://homepage.virgin.net/roy.longbottom/mips.htm

  • # 26
    Cesare Di Mauro (Autore del post)
     scrive: 

    Domani tocca al 68060 e ci sarà qualche numero. ;)

  • # 27
    Marco
     scrive: 

    @warfox
    Purtroppo i MIPS di per sé non vogliono dire granché, le istruzioni potrebbero essere tutte NOP. Cmq, stando così le cose il vantaggio starebbe ancora di più dalla parte dello 060, visto che un ipotetico mix di operazioni 68k farebbe ben più cose del corrispettivo ppc.

    Aspettiamo fiduciosi Cesare ;-)

  • # 28
    warfox
     scrive: 

    @Marco
    Ovviamente non erano tutte Nop.. :) C’era una suite di test che si usava ed era un mix delle istruzioni piu’ utilizzate. Concordo che i MIPS non sono un metodo affidabile ma quello si usava ai tempi.. Tanto piu’ che poi sono passati a qualcosa di piu’ affidabile come la suite spec. Non ho numeri invece in merito alle unita’ FP.

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.