Se il primo amore non si scorda mai, il secondo può essere quello di tutta una vita…
No, non avete sbagliato a digitare e non siete finiti nel sito ufficiale della collana Harmony : siamo sempre su Appunti Digitali e, anche se l’inizio non sembra in linea con l’argomento “tecnologia”, dipinge piuttosto bene la storia e lo stato d’animo di chi, avendo iniziato la propria carriera di programmatore smanettando su un glorioso MOS 6510, è rimasto letteralmente folgorato (in tutti i sensi, dopo quello che avete appena letto) dal successivo microprocessore su cui ha lavorato (considerato da molti anche il successore).
E non credo di sbagliare se affermo che un posto nel cuore (e nella storia dell’informatica) l’ha sicuramente lasciato quel gioiello tecnologico che Motorola lanciò nel lontano 1979 e a cui diede il nome di 68000.
Questo, ovviamente, se vi sentite già con un piede nella fossa: chi è troppo giovane non ne ha mai sentito parlare e magari pensa che al mondo siano esistiti soltanto i Pentium di Intel…
Intel che, col suo 8086 uscito appena un anno prima, aveva cominciato ad acquisire popolarità, ma letteralmente sfigurava di fronte a un 68000 che, da qualunque punto di vista lo si guardasse, era di classe nettamente superiore. Ma lo era anche nei confronti del resto della concorrenza.
D’altra parte era piuttosto imbarazzante confrontare dei processori a 8 o 16 bit con un “mostro” a 32 bit. Già, perché questa “bestiolina” permetteva di manipolare dati a 32 bit, e tali erano anche gli indirizzi (quindi la memoria teoricamente indirizzabile era pari a 4GB lineari, quindi senza paginazione né segmentazione).
Purtroppo Motorola presentò il 68000 con bus dati esterno dimezzato (16 bit; erano pertanto necessarie due operazioni per trasferire dati a 32 bit), mentre il bus indirizzi esterno fu brutalmente “troncato” a 24 bit (quindi la memoria massima indirizzabile scendeva a 16MB; quantità comunque enorme per quei tempi).
Tutto ciò si rese necessario per ridurre i costi del package, che già coi suoi 64 piedini era “mastodontico” paragonato ai 40 o 48 tipici dei prodotti della concorrenza. Questo perché Motorola non volle scendere a compromessi utilizzando soluzioni basate sul multiplexing delle linee dati e indirizzi, che avrebbe penalizzato ulteriormente i tempi d’interfacciamento con la memoria e le periferiche.
Sempre per cercare di economizzare (questa volta sul numero di transistor impiegati), l’ALU era a 16 bit, quindi le operazioni aritmetiche a 32 bit necessitavano internamente di due “passaggi” alla medesima per essere completate. Quindi le istruzioni di questo tipo risultavano più lente, anche se Motorola fornì delle versioni “quick” per somma e sottrazione (e per il caricamento di valori immediati) per cercare di “mitigarne” il decadimento prestazionale.
Finora abbiamo parlato esclusivamente di soluzioni tecniche che non riguardano direttamente l’ISA (Instruction Set Architecture), in quanto prescindono da essa e sono relative esclusivamente alla specifica implementazione. In parole povere, non si tratta di “difetti” che si porta dietro l’architettura, ma soltanto il singolo modello di processore. Altri processori della stessa famiglia elimineranno tutti questi problemi senza intaccarla minimamente.
Come ho affermato in un precedente articolo, l’ISA era fortemente ispirata a quella del PDP-11 di Digital, altro gioiello da cui hanno attinto molti, e di cui Motorola ha tratto a piene idee e soluzioni tecniche, seppur rielaborandole in base alle sue esigenze.
Vediamo, quindi, che ci troviamo davanti a un’architettura che è “abbastanza ortogonale”, cioé che buona parte delle istruzioni è in grado di sfruttare le stesse modalità d’indirizzamento. Questo facilita la scrittura dei compilatori, ma ovviamente sono presenti delle eccezioni di cui tener conto.
Infatti a differenza del PDP-11 e del TMS 9900, e a causa dell’organizzazione degli opcode all’interno della word principale a 16 bit, purtroppo l’unica istruzione che è in grado di utilizzare una qualunque modalità d’indirizzamento per l’operando sorgente e quello destinazione è la MOVE, che come dice il nome serve a “muovere” (in realtà copiare) dati da un posto a un altro.
Tutte le altre istruzioni a due operandi non godono di questa caratteristica, fatta eccezione per somma, sottrazione e confronto che possono accedere a entrambi gli operandi in memoria, ma soltanto per particolari modalità d’indirizzamento. Per il resto, l’accesso alla memoria è generalmente consentito a un solo operando, mentre l’altro dev’essere un registro. Alcune istruzioni, poi, prevedono soltanto l’impiego di registri.
Forti limitazioni? Non tanto, perché Motorola ha preferito tralasciare la piena ortogonalità e la simmetria, concentrandosi esclusivamente sui pattern più frequentemente utilizzati, e ciò le ha permesso di organizzare meglio i 16 bit dell’opcode principale, riuscendo anche a lasciare ampii spazi che in futuro verranno riempiti dai successori del 68000.
Potrebbe sembrare una difesa “a oltranza”, ma in realtà avendo lavorato per parecchi anni con svariate architetture, quante volte c’è capitato di dover eseguire lo XOR di due dati presenti in memoria? Evento molto raro, e infatti non è un caso che l’istruzione di gran lunga più utilizzata sia la MOVE, e che le operazioni aritmetico-logiche siano eseguite generalmente fra registri, al più andando a pescare un operando in memoria.
Pattern tipici che sono pienamente rispettati nell’ISA del 68000, che pur supportando anche diversi tipi di dati (fra cui gli allora famosi e utili numeri BCD packed), mettendo a disposizione comodissime istruzioni per manipolare i singoli bit, e addirittura fornendo un’istruzione per il controllo di entrambi i limiti di un array, contava stranamente soltanto 56 istruzioni.
Quindi un’architettura semplice da padroneggiare, per la quale era necessario conoscere il funzionamento di poche istruzioni, ma anche delle ben 14 modalità d’indirizzamento che annoveravano, tra l’altro, anche la possibilità di incrementare o decrementare automaticamente i registri indirizzo utilizzati (“prestito” anch’esso del PDP-11).
Sì, perché anche qui ci troviamo davanti a una pregevole trovata di Motorola: affiancare ai registri dati (8) che troviamo tradizionalmente, dei registri appositamente dedicati per gli indirizzi (altri 8, di cui uno, A7, dedicato allo stack) che in altre ISA o erano registri indice, oppure normalissimi registri.
In questo modo il 68000 si ritrova con 16 registri utilizzabili, sebbene pensati con scopi differenti, ma per i quali la codifica interna generalmente richiede 3 bit (per gli 8 valori) in quanto l’uso di un registro dipende generalmente dal contesto in cui viene utilizzato (operazioni aritmetiche -> registro dati; indirizzamento della memoria -> registro indirizzi).
Questo ha permesso a Motorola di sfruttare in maniera sapiente lo spazio a disposizione all’interno della word a 16 bit che mappa opportunamente gli opcode e i relativi parametri delle istruzioni. Infatti architetture che hanno 16 registri “general purpose” sono indubbiamente più generiche e flessibili (oltre che totalmente ortogonali), ma richiedono ben 4 bit per specificare un qualunque registro, e quando si ha a che fare con 2 di essi, ad esempio, si arriva a saturare velocemente lo spazio riservato all’opcode, lasciando poco spazio per specificare altre informazioni.
La separazione netta fra dati e indirizzi sicuramente può far storcere il naso ai “puristi”, ma nella pratica si rivela poco rilevante e, anzi, abbastanza comoda (leggendo il codice a colpo d’occhio si capisce su quali elementi si sta lavorando), oltre che efficiente (ed economico, in termini di transistor).
L’efficienza deriva anche dal fatto che è possibile specializzare il processore, riservando delle aree specifiche per il solo calcolo degli indirizzi (che in gergo tecnico si chiamano AGU, cioé Address Generation Unit), quindi delle “ALU” altamente specializzate e molto veloci, che possono anche non condividere le eventuali limitazioni dell’ALU “ufficiale” (quella che si occupa delle operazioni aritmetiche).
Infatti, sebbene l’ALU del 68000 fosse a 16 bit, il calcolo degli indirizzi non era particolarmente penalizzato, se consideriamo che anche il Program Counter, essendo anch’esso a 32 bit, richiedeva l’uso di un sommatore a 32 bit per il calcolo dell’istruzione successiva.
Andando a controllare la tabella dei tempi di esecuzione delle istruzioni troviamo conferma di ciò: mentre l’esecuzione di una somma a 32 bit richiede 2 cicli di clock aggiuntivi rispetto alla medesima operazione a 8 o 16 bit, l’uso della modalità di autoincremento di un registro indirizzo (che è sempre a 32 bit) non comporta nessuna penalizzazione.
Segno, questo, che non soltanto l’incremento viene effettuato parallelamente all’esecuzione dell’opcode “principale”, ma che non ci sono ricadute a causa sua. In sostanza si tratta di un’operazione aggiuntiva e… gratuita (l’autodecremento, invece, comporta una penalizzazione di 2 cicli di clock), abilmente sfruttata dai programmatori dell’epoca.
Altre caratteristiche interessanti del 68000 erano la possibilità di eseguire il tracing delle istruzioni (per il debugging), il supporto al multiprocessing (grazie alla presenza di una speciale istruzione atomica di “test-and-set“), e i ben 7 livelli di interrupt a disposizione per le periferiche.
Molto più interessante era, però, la presenza di una modalità utente e una supervisore (dotata di un suo stack), che consentiva quindi un’altra separazione: quella dell’esecuzione del codice del sistema operativo da quello delle normali applicazioni.
Purtroppo non c’era ancora il supporto alla gestione della memoria virtuale (che arriverà soltanto col 68010) né meccanismi di protezione della memoria per impedire l’accesso indicriminato alle strutture dati del s.o., ma volendo era possibile realizzare un sistema in cui codice e dati della modalità supervisore erano completamente isolati rispetto ai medesimi di quella utente, sfruttando particolari segnali presenti nel bus di controllo della CPU (i poco famosi “function code“).
Un microprocessore estremamente flessibile in diversi campi, quindi, che non a caso continua ad avere un posto d’onore nel cuore di chi ha avuto modo di poterci lavorare, generando schiere di appassionati e “fedeli”. Era, infatti, talmente comodo che l’uso dell’assembly per sviluppare applicazioni anche complesse era molto comune (quasi tutte le applicazioni che ho realizzato per l’Amiga erano scritte in questo linguaggio).
Purtroppo questo è stato anche il suo tallone d’Achille, perché a una grande facilità di fruttamento da parte dei programmatori s’è contrapposta un’architettura interna molto “pesante” e “complicata” (non è un caso se questa famiglia è considerata fra le “più CISC“), che col tempo ha limitato fortemente la possibilità di aumentarne le prestazioni, complice soprattutto la successiva estensione dell’ISA da parte di Motorola col 68020.
Il fallimento di Commodore prima, la chiusura della linea ST di Atari poi, e infine il colpo di grazia dell’abbandono di Apple (che s’è rivolta ai PowerPC) ha segnato la fine di una delle più “belle” architetture della storia dei microprocessori, che continua a vivere in nicchie di mercato dei dispositivi embedded / microcontrollori, ma soprattutto nel ricordo di chi ha avuto il piacere di conoscerla e poterci lavorare…
Che ricordi … Fu il mio secondo processore, dopo l’altro mito: lo Z80. Quando lessi il manuale dell’assembler non riuscivo neppure più a spiegare ai miei alunni l’assembler Z80. Un vero mito!
Mi piacerebbe però trovare in un futuro articolo le sue evoluzioni: pare infatti che dopo il 10 arrivarono il 20, 30 e 60. Voci incontrollate davano il 50 esclusivo per applicazioni militari … Ed un confronto con la famiglai Intel. Si insomma il 68000 è paragonabile al 386sx e via discorrendo.
Complessità a parte sono convinto che se Amiga in primis non avesse mollato Motorola non avrebbe dismesso questo micro, ed oggi avremmo delle belle CPU: sono sempre state avanti anni luce (bisestili) rispetto a Intel. Finchè la casamadre ha potuto.
Sì, sono previsti articoli anche per i successivi modelli, e anche confronti coi rivali di sempre, gli x86.
Lo 050 non fu usato per scopi militari, ma fu “abortito” da Motorola in favore dello 060, perché non portava sufficienti innovazioni per contrastare quello che sarebbe stato poi il Pentium di Intel.
Purtroppo l’Amiga è “deceduto” causa fallimento di Commodore, altrimenti penso che Motorola avrebbe avuto ancora non poco da dare con quest’architettura. E’ il passaggio di Apple ai PPC che, purtroppo, è stato fatale.
Ricordo ke verso il ’94 ’95 avevo calcolato di avere un numero di 68000 in casa veramente assurdo, uno nell’Amiga 600, uno nel 3000, uno del sega megadrive e due nel modem ZyXEL!
Ciao Cesare! Grazie mille intanto per i tuoi articoli!
Hai quindi intenzione di analizzare le CPU x86 come 286, 386, 486 e Pentium?
Grazie ancora!
Sarebbe interessante sapere se quella che poteva essere la “via Motorola” all’evoluzione di Apple, ossia l’88000, avrebbe offerto o meno dei vantaggi rispetto alla famiglia PPC. E pensare che anche Alpha era fra i candidati a rimpiazzare il 680×0, se i suoi manager non fossero stati così ottusi da non credere nel mercato dei personal.
@Mendocino89: figurati. E’ un piacere anche per me parlare di queste cose che mi piacciono particolarmente. :)
Il 286 l’ho già analizzato qui: http://www.appuntidigitali.it/3381/intel-80286-fra-protezione-della-memoria-e-call-gate/
386, 486, ecc. li tratterò in seguito.
@Alessio: toccherà anche all’88000 prima o poi, e ai relativi confronti. :D
Grazie Dr. di Mauro per rinverdire questi fasti “dei tempi” che furono…sigh…
Io di 68000 (intesi come circuiti integrati) né ho una ventina (tra montati in Amiga 500 e “disponibili” come integrati che all’epoca ordinavo per posta con ordini scritti a mano).
Li produceva Hitachi,Motorola ecc. ecc.
La “M” racchiusa nel circolo però mi piaceva di più…
La serie 683xy vive e sopravvive tutt’ora in molte incarnazioni..soprattutto embedded in centraline per motori di auto tra l’altro…
Quando ero sempre all’I.T.I.S locale di Lucca non perdevo occasione per consultare il manualone della Motorola…68012 incluso…
Mi dispiacque non poco quando Motorola decise di non implementare in hardware tutte le funzioni trascendenti del 68882 all’interno della f.p.u del 68040…
Vi ricordate del programma G.O.M.F (che io ho in versione 3.0) che intercettava le tristemente famose guru meditation…quelle generate dal 68010 (che ho nella mia piccola santabarbara) incluse ?
Grazie.
Marco71.
@Marco: Get Out My Face. Chi può dimenticarlo?
Ho porgrammato anche io sui microcontroller derivati dal 68k. Era il ’95.
@Cesare.. Come detto sono estimatore dell’architettura 680×0. Nulla a che vedere con Intel. Vorrei ricordare che l’ultimo della famiglia 680×0 lo 060 era superscalare e con la sola frequenza di 50 Mhz era in grado di fare calcoli piu’ velocemente dei pentium 100 di allora. Tutto dimostrabile.. :)
Comprai un Mac proprio per questo procio (anzi il 68030) e per MacsBug. Gran bel processore. Anche io all’ITIS ho avuto modo di programmarlo direttamente in assembler prima di acquistare l’SE30. Vi rimando, a chi puo’ ancora interessare a questo articolo:
http://www.mactech.com/articles/develop/issue_26/semchishen.html
proprio notevole. Aspettavo un Quadra (ne avevo uno, montava il 68040) con 68060 ma non fu mai realizzato.
che ricordi! quante giornate passate a programmarlo sul mio fido amiga :)
L’assembly per il Motorola 68k era veramente avanti rispetto a quello dell’Intel 8086 dell’epoca.
Non a caso quel poco assembly che ho visto in università era per M68k. ;)
grande Cesare, finalmente l’hai fatto? Intendo dire, un articolo sul 68000.
Ciao
Stefano
@Marco: e col 68060 andò anche peggio, perché furono rimosse altre istruzioni dall’ISA, e rimpiazzate tramite emulazione.
@Alberto: non ricordo bene i benchmark di allora, ma anche il Pentium, con opportuna compilazione del codice non era male. Ma di una cosa sono sicuro: il 68060 a parità di clock aveva mediamente prestazioni ben superiori.
@Lobo: per manipolare interi a 64 bit preferivo scrivere direttamente codice assembly. :)
Ho visto il link che hai postato, e l’impressione che ho è che la persona che ha scritto la routine Wide_DivideU non conosceva bene l’architettura 68000, perché questa routine di divisione utilizza istruzioni abbastanza lente (CLR) e, comunque, si poteva ottimizzare molto meglio.
@sirus: io continuo ad apprezzarlo anche oggi. :)
@Yoss: non vedevo l’ora. E non è certo finita qui. :D
Scusate tutti per il ritardo, ma ho avuto un po’ di cose da fare e non ho potuto rispondere prima.
Grazie comunque per gli apprezzamenti: è motivo di orgoglio e linfa che mi spinge ad andare avanti. :)
[…] bit” (o come “32 bit”, se considerassimo l’ISA, come ho scritto in un articolo a lui dedicato), ma a mio avviso sarebbe riduttivo perché ha diversi altri elementi “significativi”. […]
con la prima cpu 68000 ho in comune una cosa: la leva, il 1979
e mi piace cosi’ tanto che per hobby in cantiere ho ancora alcuni progetti m68k
come gentoo(gnu/linux) su macLC475 (68040)
http://www.elinux.org/Flameman/mac68k
come riutilizzare un palmare a base di 68328 (core 68000)
http://www.elinux.org/Flameman/m105
come sperimentare un core per usi microrobotici, il 68332
http://www.elinux.org/Flameman/mrm
ho anche una board 68060-25Mhz, ma va “finito” ed ammodernato sia l’hw che il firmware
funziona il commento o si e’ perso il precedente ?
ok, funziona, si e’ perso
nulla, dicevo che ho in comune con il 68000 la leva: siamo entramvi del 1979
e che mi piace cosi’ tanto questa architettura che, per hobby, ho in cantiere ancora alcuni progetti m68k, spaziando da derivati in salsa “microcrontroller oriented” come il 68328 (core 68000), il 68332 (core 68000?), a cpu di ultimo ramo di famiglia, come il possente 68060 montato su una scheda di sviluppo motorola del 1993 (forse a qualcuno dice qualcosa “idp68ec0x0 board”)
fra i progetti meno esoterici c’e’ il riutilizzo di un apple-68k-modello-LC475 (68040) in salsa “workstation unix/68k)
(linux-gnu) gentoo/m68k http://www.elinux.org/Flameman/mac68k
C’è il filtro antispam che a volte si mangia i commenti che ritiene (bontà sua) “indigesti”.
Capita spesso se metti tanti link, o link a siti che ritiene spam.
Se l’hai conservato, puoi provare a sistemarlo riducendo all’osso i link e ripostarlo.
Purtroppo i modelli più diffusi di 680×0 sono quelli privi di MMU…
non c’e’ problema: oggi ci si puo’ affiancare ad unita’ a logica programmabile per confezionare non solo quanto possa servire del supporto MMU ma anche per fornire alla CPU quel supporto circuitale esterno di cui ha bisogno
ogni 68k infatti ha fra le prime magagne il dover spostare dinamicamente la rom in posizione 0x0000 al bootstrap, o quantomeno fornire un valido vettore, gia’ solo per questo fatto occorre circuiteria esterna che vada a rimappare la rom negli spazi della ram, escludendo momentaneamente quest’ultima. Altre rogne sono la gestione del bus in politica /dtack (cosa che su certe board come la mia idp68ec0x0 richiede addirittura una macchina a stati finiti per giostare un complesso protocollo) ecc
poi, per come la vedo io, avere una mmu non ha troppo senso per la questione della memoria virtuale, perche’ per m68k ha + senso confezionare sistemi operativi che lavorino con task statici piuttosto che con processi dinamici (che abbisognando di costrutti come la fork, quindi strettamente di qualcosa che mappi indirizzi virtuali in indirizzi logici) … ha + seno la questione della memoria protetta in modo da garantire che nessun task possa minimamente intaccare gli spazi vitali di altri task
ho assistito alcuni progetti in cui “semplicemente” si caricavano ad ogni context switch vettori di inizio-fine memoria task in un comparatore di indirizzo e si utilizzavno fc0,fc1,c2 per stabilire lo stato S/U della cpu e in caso di stato=U e violazione di indirizzo (si sta accedendo/lettura/scrittura in spazi di memoria di non competenza del task in eseguzione) alzate trap
il tutto confezionato con un 68EC000 (che vanta, oltre al basso consumo, anche la possibilita’ bus dynamic 8/16bit, mentre la versione 68HC000 funziona solo a 16bit) e una cpld xilinx particolarmente ricca di I/O e celle
E’ per questo che ho apprezzato (e continuo a farlo) AmigaOS. ;)
Pur essendo la maggior parte degli Amiga non dotati di MMU, era presente della circuiteria esterna per mappare al reset la ROM all’indirizzo 0, come giustamente hai riportato.
L’MMU, per chi ce l’aveva, era impiegata per lo più per bloccare i tentativi illeciti di indirizzare la parte bassa della memoria (NULL pointer dereferenziati).
pero’ c’e’ anche da dire che amigaOS sia un OS a scopo generale, confezionato a scopo desktop O.S., con processi dinamici (scritti, ma non ci giurerei, scritti grazie al potente metodo dell’indirizzamento relativo fornito dall’ISA 68k, in modo che ogni porzione di codice entro un certo range, quindi diciamo tutto il corpo eseguibile di un processo, sia “rilocabile” circa a piacere su di una memoria piatta e lineare) e senza criteri mission critical: quindi poteva benissimo, ai suoi tempi, fondare il suo “buon funzionamento” sulla fiducia e sulle ottime capactia’ di programmazione dei suoi coders (coders che e’ risaputo fossero i migliori perche’ prima di tutto appassionati, innamorati fino al perfezionamento continuo delle loro capacita’ di programmazione). Io non ho mai avuto la fortuna di avere fra le mani un amiga (nemmenl la A1200), xro’, da quanto ho appreso credo che sia questo, in soldoni, il karma dell’amighismo.
Ad ogni modo per applicazioni mission critical in senso moderno dove ha senso usare ancora core m68k, allora non ci si puo’ permettere tale fiducia sulle capacita’ umane, anzi siccome “per i colletti bianchi del time to market (sempre + breve)” “il primo bug e’ proprio il coder” allora si vanno via via a rimuovere tutte le possibili fonti di possibile errore. Si comincia rimuovento la malloc dinamica per rimpiazzarla con una malloc static, e via via si prosegue finendo per eliminare persino l’ipotesi di processi dinamici, anzi li si rimpiazza proprio con task statici (questo anche per meglio garantirsi l’ipotesi di “real time deterministico”) … e via via ancora si prosegue per erodere tutto il kernel in salsa G.P. per confezionare al suo posto qualcosa di molto + blindato che valga le certificazioni di “kernel embedded a prova di errore, ovvero un qualsiasi errore in un qualsiasi suo task non verra’ mai propagato in nessuna parte vitale perche’ il kernel in questione non puo’ permettersi di panicare per nessun motivo”. Ora, a parte la circuiteria per la memoria protetta (giusto per essere paranoici fino in fondo), tutto il resto della circuiteria della MMU francamente non serve. Per questo motivo si preferisce vendere CPU per scopi embedded di questo taglio prive di MMU.
C’e’ una altra questione che forse potrebbe tagliare la testa al toro: prima ho accennato al fatto che si possa sintetizzare tutta un circuiteria (dalla semplice logica combinatoria sequenziale a oggetti + complessi come posso essere le macchine a stati finiti che governano i bus) in un semplice unico oggetto chiamato o CPLD (per piccole applicazioni) o FPGA (per grandi applicazioni), ebbene allora perche’ non sintetizzate anche la circuiteria interna della CPU ? CPU e suoi intorni tutto bello ritagliato in 1 solo chip da inserire in 1 comodissimo socket ? Con la possibilita’, in caso di errore di progettazione, o “cambio di direzione del cliente –> occorre ridefinire qualcosa, e in hw e’ dura, di aprire un editor di testo e cambiare “al volo” quanto occorre senza la scocciatura di dover alzare il telefono per chiamare il “gerberboy” ovvero colui che si occupa dello sbroglio e della realizzazione della scheda PCB o di patch della stessa ? (parliamo di studi prototipali, raffinamenti fino al confezionamento della soluzione finale che andra’ poi prodotta in grandi numeri … pero’ come detto oggi il time-to-market e’ sempre + con l’acqua alla gola e … le commesse tendono ad essere sempre meno riciclabili da progetti general purpose perche’ sempre + custom) Dunque questa ideona nuova moda degli anni 2000 (esisteva da tempo, ma era utopia, oggi inizia ad essere quasi possibile confezionare applicazioni di questo tipo) incarna il sogno di ogni progettista hw
E pensandoci e’ davvero naturale che sia comodo il potersi ritagliare una soluzione tutta OnChip, in 1 solo chip, con al + solo un quarzo esterno: ebbede, come detto questa utopia futuristica si e’ sempre scontrata e ancora si scontra con il fatto che CPU CISC complesse come il 68000 male si prestano ad essere integrate su supporti a logica programmabile. Primo perche’ occupano ed esauriscono questi tutte le risorse del chip di sintesi, secondo perche’ nella complessita’ della sola logica di decodifica non si riesce a travore validi compromessi fra il dover garantire impeccabili sincronismi interni (con probabilita’ d’errore circa nulla) e al contempo spingere al massimo le prestazioni andando a ridurre i cicli necessari per la temporizzazione.
In poche parole se si prova a sintetizzare un 68000, anche con metodologia a microcodice (come fu di fatto realizzato il 68020 su ASIC) non si riesce a sfornare qualcosa di
* su unico chip FPGA (CPLD e’ assolutamente impensabile)
* performante (escono soluzioni lente, molto + lente di un 68000 su ASIC)
* che rendano ragione dello scopo per cui ci si e’ imbarcati in questa non facile impresa
* ovvero non si riesce a ritagliare un core 68000 in meno del 90% dell’area di una FPGA
va da se che invese soluzioni RISC siano “circa” (cioe’ con riserva, ma spesso e’ cosi’) perfettamente sintetizzabili, una fra tutte il RISC MIPS R2000 che spesso xilinx cita fra le demo invitando a scriverne le “poche” righe di codice VHDL che ne descivono i 3 layer, dall’interfaccia, al modello esecutivo, all’implementazione su dispositivo fisico.
Da cio’ ne consegue che forse, forse, sempre con riserva, forse fra tutti i CISC/m68k sono i coldfire (non strettamente compatibili, fra l’altro) che hanno qualche possibilita’ di riuscita nell’impresa.
Applicazioni “mission critical” come quelle che hai descritto sono molto particolari e decisamente più rare rispetto al panorama delle soluzioni embedded.
Tutte le modifiche al s.o. per renderlo “a prova di errore” si possono comunque applicare anche ad AmigaOS.
Anzi, penso sia anche più facile perché si tratta di un kernel di dimensioni ridotte all’osso (fino alla versione 1.3 era costituito da circa 18KB di codice macchina 68000, portato fino a poco meno di 40KB nelle versioni successive, cioé 2.0, 3.0, ecc.) e facilmente personalizzabile (considera che erano presenti applicazioni che cambiavano istantaneamente roba come scheduler e allocatore della memoria). ;)
Per quanto riguarda il 68000 concordo sul fatto che sia un microprocessore complesso da implementare. E condivido la scelta di Motorola, di eliminare alcuni opcode & funzionalità con la serie Coldfire, per semplificare il core.
Ci sono comunque alcuni progetti open source sfruttano gli FPGA per implementare versioni perfettamente compatibili, a costi contenuti, e molto veloci (anche più del top di gamma, il 68060.
Prima o poi ne citerò qualcuno in qualche articolo.
In ogni caso è difficile competere con la semplicità architetturale di un RISC, come giustamente sottolineavi, la cui implementazione generalmente è molto più semplice.
concordo, tuttavia volevo sottolineare il fatto che
amigaOS e’
* defunto
* relegato ad hw amiga, custom
* relegato agli amichisti
* non sfruttabile in progetti xke’ fuori produzione
* in ogni caso non certificato
* e nemmeno certificabile per i motivi che ho esposto precedentemente secondo il concetto moderno di mission critical, molto + severo oggi di anni fa
poi c’e’ anche da dire che il venduto attuale m68k motorola (anzi freescale, motorola semiconduttori e’ stata ceduta loro) e’ al contrario quasi tutto destinato al mondo embedded, quindi anche la visione e’ capovolta a livello di sistema operativo: ovvero, se si parla oggi 2009 di m68k NON retrocomputing (quindi parti di ricambio per nostalgici amighisti), allora e’ altamente probabile che si stia parlando di un qualcosa di embedded
anzi, molto spesso esiste l’accoppiata: coldfire/uc-linux (un orrore non certificabile, ma per certi versi e’ comodo e, a larghe maniche, (purtroppo) si usa)
piuttosto che, vista la tutto sommato robustezza dei m68k, altri OS di stampo veramente embedded (quindi con task, malloc statice e non pseudo processi e finte fork a malloc dinamiche), fino a finire in quelli mission critical.
ora, pero’ perdonami, ma soluzioni 68060 opencore (codice vhdl/o quantaltro in salsa open) non ne ho mai viste
esiste un core 68000 a pagamento?
Intellectual Property http://vlsi-concepts.com/V68000.html
Features : – Fully Synchronous Design; No Microcode
– All Control Via State Machines
– Simple Synchronous Interface To Memory And Peripherals
Ottenuto sicuramente con contrazioni progettuali degne dei migliori maestri delle logiche di sintesi, questo xke’ l’analisi tecnica di una possibile sintesi di un 68000 porta all’occupazione del 90% delle fpga.
Ora, se tutto cio’ e’ sconfortante, c’e’ da farsi nel constatare che per un 68020 una possibile implementazione sia fattibile quasi solo a patto di passare per una re-implementazione a microcodice (nanoROM, come le 2 che motorola stessa implemento’), e se questo e’ veramente scoraggiante, per un 68060 e’ ancora peggio, perche’ quella cpu e’ talmente complessa che in quel caso e’ sicuramente consigliabile il passare da un nucleo RISC ed interfacciato ad un sottonuclero CISC di traduzione opcode m68k a microcodice di natura RISC eseguita per l’appunto dalla pipeline dal nucleo … il che lascia ben intendere il bagno di sange e la quasi impossibilita’ realizzativa, “a meno di segare” gran parti di quella cpu (cosa che per altro in parte decise di fare motorola fornendo poi le relative librerie per amigaOS, riprese ed importate poi da netBSD e linux per le povere acceleratrici cyberstorm 68060 che, diversamente, si sarebbero viste una sfilza di trap per opcode non valido, proprio perche’ certi opcode non sono stati implementati nel passaggio da 68040 a 68060)
a spanne non ha troppo senso, sia per le prestazioni attese nettamente inferiori, sia per l’impossibilita’ di rendere una sintesi superscalare (dubito fortemente che la pipeline riesca a funzionare a reggime senza stalli, dubito che non servano finti NOP per mantenere coerenti i suoi stadi eseguendo quel microcodice) in un qualche senso vantaggioso, sia perche’ se si occupa tutta la fpga per il solo processore si sta sbordando palesamente dalle direttive di progetto che vorrebbero invece confezionare un sistema CPU e suo contorno onChip.
ne parlarono anche sul forum di opencores (luogo dove hanno rilasciato pubblicamente il codice vhdl del citato MIPS R2000, didattico ma non troppo) cercando di rispondere alla domanda: “xke’ non ha senso sintetizzare un 68000 ?” “si riesce a farlo ? a che prezzo ?”
a farci caso esiste la prova del 9, ovvero quel simpatico kit videoludico che vorrebbe rimpiazzare e proporre un amiga-500 rivisto e corretto in salsa “portable console”: non so chi lo commercializzi, so che nei vari filmati degli eventi Amiga c’e’ una piattaforma caruccia, piccola, compatta e moderna (per dirla tutta usa le MMC/SD al posto degli antiquati floppy giochi amiga) in cui pero’ si che vede un vero 68000 su zoccolo quadrato (per risparmiare spazio) affiancato ad un chip di logica programmabile che confeziona quanto stava a valle della CPU sulla scheda madre della A500 (si, i 3 chip custom che caratterizzavano amiga)
ecco, quel kit commerciale dimostra che non ha troppo senso sintetizzare un 68000, non per scopi che non siano puramente didattici, di ricerca, o dimostrativi della possiiblita’ di sintesi (leggasi demo)
dove hai letto della possibilita’ di sintetizzare un mostro superscalare come il 68060 ? (io confesso che riporto informazioni di 1.5 anni fa)
AmigaOS non è morto, ma è vivo e vegeto e continua a essere sviluppato (da poco è stata rilasciata la versione 4.1: http://en.wikipedia.org/wiki/AmigaOS_4.1#AmigaOS_4.1 ).
Esistono comunque versioni open source come AROS ( http://aros.sourceforge.net/ ), anche se non sono ancora compatibili al 100% con la versione 3.1 (era l’obiettivo dichiarato del progetto).
Essendo open source, è ovviamente modificabile (e in evoluzione: io aspetto il supporto per l’ARM, in modo da infilarlo nel mio Zaurus al posto di Linux, che è troppo pesante).
Non conosco esattamente i requisiti per la “certificabilità”, per cui non mi posso pronunciare in merito, ma magari lavorandoci potrebbe essere possibile ottenerla.
Questo per AmigaOS. Sul 68000, è vero e concordo: è utilizzato per lo più in sistemi embedded, nelle sue varianti “microcontrollore”, di cui il ColdFire è il rappresentante più conosciuto.
Per quanto riguarda le soluzioni “open” (o “fatte in casa” che dir si voglia), preciso che non ho mai parlato di riproduzioni del 68060, ma di implementazioni dell’architettura che sono più veloci del 68060 e che, come giustamente affermi, sono basate su un core RISC (con un decoder CISC).
Ovviamente si tratta di soluzioni non superscalari, perché altrimenti il progetto sarebbe stato troppo complesso. E nemmeno tutta l’ISA risulta “accelerata” (le modalità d’indirizzamento indirette introdotte dal 68020 in poi fanno stallare la pipeline, penalizzandone le prestazioni).
E non è nemmeno il kit videoludico di cui parli. E’ una soluzione nuova di zecca che si propone di ottenere un “superAmiga”. Quindi non soltanto una CPU molto più performante di quelle tirate fuori dalla Motorola, ma anche un chipset opportunamente aggiornato con avanzate funzionalità video e 2D, a cui si affianca anche un core 3D (questo, purtroppo, non aggiornato con ciò a cui siamo abituati a vedere ai nostri giorni).
Se hai pazienza, fra qualche mese ne parlerò espressamente in un articolo. Al momento in scaletta ho tanto altro materiale. ;)
forte, veramente forte, gran bella idea, e gran bell’articolo quello che hai trafilato per il futuro: non vedo l’ora di leggerlo!
io xro’ intendevo amigaOS/m68k, non e’ defunto?
cioe’ gli ultimi amigaOS (quelli scritti dalle powerup in poi, intendo) non dovrebbero essere solo per ppc ?
chesso’ per amigaONE o macchine ppc specifica Zico ?
ARos non conoscevo, approfondisco con piacere =P
Sì, AmigaOS per 680×0 è sostanzialmente defunto. In alternativa c’è AROS, che gira su 680×0.
Le ultime versioni di AmigaOS sono soltanto per PowerPC, purtroppo.
AROS è strano che non conoscessi: è ben noto agli amighisti. E’ uno dei progetti più vecchi e dal quale ci si aspettano grandi risultati (anche se non è completo al 100%, è abbastanza maturo ed esiste una versione live o per virtual machine; da provare assolutamente).
beh, ma non sono un amighista
come ti scrissi, non ho mai toccato con mano una amiga, purtroppo: ho iniziato su una workstation HPPA/unix con HPUX
conobbi m68k molto + tardi, e fu interesse da hardwarista (perche’ ho studiato ing.elettronica/digitale)
ARos e’ interessante, prima che mi laureassi (ottobre 2008) in ing.elettronica c’era obiettivamente poco tempo per il lato sw, e in quel poco tempo cercavo di supportare Haiku, figlio di quel BeOS che ho apprezzato ed utilizzato dal 2001 al 2005, prima cioe’ che iniziassi a supportare linux sulle + disperate architetture (non ci avevo fatto caso ma ho seguito e reso quantomeno “quasi-usabile” gentoo su apple lc475 non troppo tempo fa, come si legge sul mio sito: 11 January 2009 =P)
[…] dire il vero il gioco, sui primi Amiga con 68000 e chipset OCS, metteva il pur capace hardware alla frusta, e risultava un po’ lento. […]