1 luglio 2009: chi di voi non ha mai sentito parlare di memoria virtuale, paginazione, file di swap, virtualizzazione delle risorse, ecc… scagli la prima pietra!
Sono tutte cose con cui abbiamo a che fare, utilizzamo e diamo anche per assodate da parecchio tempo. Difficile immaginare oggi un mondo senza questi utilissimi strumenti. Eppure parecchi anni fa chi smanettava coi primi computer “domestici” non conosceva nemmeno la loro esistenza, essendo relegati a sistemi parecchio costosi (mainframe, minicomputer, workstation).
Ovviamente, col passare degli anni e la continua diffusione dell’informatica, approdarono nel mercato consumer anche CPU che erano dotate di simili caratteristiche.
A metà degli anni ’80 il boom di Commodore Amiga, Atari ST e Apple Macintosh portarono alla ribalta il glorioso 68000 della Motorola (che non offriva nulla del genere), e iniziarono a proliferare anche le cosidette “schede acceleratrici”, le più economiche delle quali permettevano di montare il meno famoso fratello maggiore, il 68010…
Nato nello stesso anno dell’80286 di Intel (il 1982), ma costituito dalla metà dei transistor (e, quindi, molto più economico), questo microprocessore portava innanzitutto una dovuta correzione a un grossolano errore di progettazione commesso da Motorola col primo esemplare di questa fortunata famiglia: l’introduzione dell’istruzione MOVE CCR, facendo al contempo diventare privilegiata la già esistente MOVE SR.
Perché tutto questo? E perché è così grave questa mancanza? SR è il registro di stato della CPU, e contiene sia i codici di condizione (riporto, segno, ecc.) sia vari altri flag che rappresentano informazioni sullo stato privilegiato del processore (modalità utente/supervisore, maschera degli interrupt e abilitazione del tracing delle istruzioni).
Col 68000 era possibile modificare come si vuole questo registro e, quindi, un’applicazione aveva piena facoltà di fare il bello e il cattivo tempo sull’intero sistema (sarebbe stato sufficiente abilitare la modalità supervisore per ottenere il controllo su tutto). Questo impediva, di fatto, la realizzazione di sistemi operativi “protetti”, dove soltanto il kernel (che gira in modalità supervisore) poteva disporre l’ambiente per l’esecuzione delle applicazioni utente.
D’altra parte quella di poter accedere ai flag dei codici di condizioni era ed è un’esigenza abbastanza comune, per cui mettendo nell’ISA l’istruzione MOVE CCR, che agisce soltanto sul byte che li contiene (tralasciando il byte con le informazioni privilegiate), si salvavano, sì, capra e cavoli, ma a un prezzo piuttosto salato: l’incompatibilità con le applicazioni scritte per il 68000, che giustamente facevano uso della MOVE SR (unica istruzione disponibile per loro).
Commodore risolse il problema con l’AmigaOS mettendo a disposizione nella ROM la routine GetCC che eseguiva una MOVE SR o una MOVE CCR a seconda che fosse stato rilevato un 68000 o un processore superiore (68010 incluso). Ciò nonostante tante applicazioni e (soprattutto) giochi per Amiga non funzionarono con processori diversi dal primo, perché i programmatori erano troppo poco inclini a seguire le rigorose direttive della casa madre sullo sviluppo di software per questa piattaforma (problema comune anche oggi, purtroppo).
Per realizzare la completa virtualizzazione delle risorse del microprocessore, furono aggiunte altre istruzioni. MOVE VBR che consentiva di spostare ovunque nella memoria la tabella dei vettori delle interruzioni ed eccezioni (costituita da 256 elementi, anche se in realtà ne veniva usati di meno), MOVEC per leggere e scrivere i registri di controllo dei codici funzione, e infine MOVES per spostare dati fra spazi d’indirizzamento diversi.
I codici funzione sono utilizzati dalla CPU per segnalare in maniera precisa il motivo per cui sta accedendo alla memoria (sia in lettura che in scrittura). Sono previsti, infatti, appositi valori per indicare l’accesso al codice (fetch dell’istruzione) o ai dati, e se la modalità è quella utente o supervisore.
In questo modo le periferiche possono regolarsi servendo in maniera opportuna la richiesta. A prima vista sembrerebbe una caratteristica inutile, ma sfruttandola opportunamente è possibile isolare del tutto i dati utente da quelli supervisore. Inoltre si potrebbe anche dividere la memoria allocata per il codice da quella per i dati. Combinando entrambe le cose si arriverebbe anche a poter indirizzare fino a 64MB di memoria (16 + 16 MB per codice e dati utente, e altrettanti per quelli supervisore).
Col 68000 però c’era poca flessibilità per quanto riguarda i codici funzione, perché erano fissi e predeterminati nella CPU, e pertanto non era possibile effettuare, ad esempio, copie di dati fra aree di memoria utente e supervisore (tranne se coincidevano, come veniva fatto), caratteristica questa necessaria per un kernel.
Il 68010 introduce 2 nuovi registri (SFC e DFC, che definisco i codici funzione sorgente e destinazione) e le suddette istruzioni MOVEC e MOVES, risolvendo in maniera elegante il problema. Con la prima istruzione è possibile memorizzare appositi valori in SFC e DFC, mentre la seconda li utilizza spedendoli alle periferiche esterne rispettivamente quando legge il dato, e quando lo scrive.
Da tutto ciò rimane, però, fuori la cosa più importante: la virtualizzazione della memoria. Infatti col 68000 non era possibile implementare questa funzionalità, poiché il microprocessore, in caso di errore di bus (indirizzo non presente) o d’indirizzo (non valido), scatena un’eccezione, memorizzando però nello stack poche informazioni per il suo recupero.
Il 68010, invece, memorizza molte più informazioni (fra cui il suo intero stato interno), permettendo quindi di poter decidere in maniera precisa cosa fare a seguito dell’eccezione, e in che modo riprendere l’esecuzione dell’istruzione, arrivando quindi a emulare praticamente qualunque caratteristica “fisica” di un sistema agli “occhi” dell’applicazione che sta girando.
Inutile dire che, utilizzando uno stack frame diverso (viene chiamato così l’insieme delle informazioni di stato memorizzate nello stack a seguito di interruzioni o eccezioni), il 68010 presentava un ulteriore elemento di incompatibilità col 68000, creando ancora una volta problemi alle applicazioni “poco ortodosse”…
Di questa CPU ne venne realizzata anche una versione con bus indirizzi esterno a 30 bit (68000 e 68010 hanno, invece, un bus indirizzi esterno a 24 bit e, quindi, sono limitati come indirizzamento della memoria a 16MB), il 68012, capace pertanto di arrivare fino a 1GB di spazio d’indirizzamento, ma che non ebbe successo.
I vantaggi, però, non finivano qui: lato applicativo fu introdotta una particolare modalità “loop”, in grado di accelerare notevolmente l’esecuzione di precisi pattern di istruzioni facenti uso dell’istruzione di loop DBcc (utilissima e usatissima, che prevede il decremento di un registro e il salto se questo non è zero, oppure se la condizione non è soddisfatta).
Questo microprocessore, infatti, era dotato di una memoria interna di 3 word (6 byte), utilizzata per il prefetch delle istruzioni. Nel caso in cui la logica di prefetch incontrava un’istruzione che occupava una sola word, e la successiva era una DBcc il cui indirizzo puntava alla prima, veniva attivata questa modalità che non richiedeva il continuo caricamento degli opcode delle due istruzioni, ma la memoria era impegnata esclusivamente a trasferire i dati veri e propri.
Le stime parlavano di un buon 10% circa di guadagno fra 68010 e 68000 a parità di clock e ciò, assieme alle migliorie apportate nell’ambito della virtualizzazione, fece avere a questo microprocessore una discreta accoglienza nelle workstation economiche, ma scarsa nei computer “domestici” (principalmente a causa delle citate incompatibilità).
P.S. Ringrazio Fabio Mecchia per aver gentilmente messo a disposizione una foto della CPU.
Per rispondere alla prima domanda.. Ad es chi non sa cos’è lo swap file è la responsabile informatica di dove lavoro… E ho una perla di P4 3.2 ghz 8non male in ufficio di per sè) MA con 512Mb di Ram. Condivisa con scheda video ovviamente. E prima avevo un P4 1.7ghz con 128mega, sempre condivisi. Come prendere una ferrari e mettergli sotto le gomme della panda.
Comunque la virtualizzazione delle risorse su macchine domestiche degli anni 80-90 non l’ho mai vista.
Il file di paging già sembrava roba grossa…
Vero. Infatti, come dicevo, era roba relegata a ben altri settori, che ho conosciuto soltanto anni dopo essermi fatto le ossa sugli computer “domestici”.
@Magilla: ROTFL :D
@Giacomo
Per la memoria virtuale (se intendiamo come tale un page-to-disk a livello di SO) è comunque “necessaria” anche una MMU che, essendo un chip a parte fino al 68030 (68451 per il 68010 e 68851 per il 68020), di solito non veniva installata negli home computer (Cesare, magari ti ricorderai Gigamem ;-) )
Altro appunto, nel mondo x86 per avere una full virtualization in hardware completa (conforme ai requisiti Popek-Goldberg) si è dovuto aspettare fino al 2006 con VT e AMD-V.
Marco, la MMU non era strettamente necessaria.
Sul mio A1200 dotato di 68ec20 avevo installato un software (forse proprio Gigamem?) che implementava il file di swap via software.
No, con Gigamem serviva l’MMU.
Comunque con processori come il 68010 (e successori), non è strettamente necessaria una MMU, ma una circuiteria esterna per la mappatura delle aeree di memoria si può realizzare in maniera più semplice (ma anche molto più rudimentale, ovviamente).
Se non sbaglio il nocciolo della virtualizzazione sta nella memoria indirizzabile..
L’utilità diviene molto maggiore quando la memoria fisica diventa minore di quella indirizzabile con gli n bit del processore..e questo avviene solo in tempi relativamente recenti, quando le cpu lavorano con un numero maggiore di bit.
Forse è per questo che nei primi anni 80′ non si aveva ancora sfruttato una sorta di virtualizzazione.
Da ricordare però che prima di allora grazie al modulo mmu era possibile (con principi analoghi) indirizzare memoria di dimensioni maggiori a quella indirizzabili dalle povere cpu carenti di bit.
Il problema non era tanto l’indirizzamento (il 68012 arrivava a 1GB di spazio indirizzabile), quanto la mancanza di memoria fisica, che all’epoca si pagava a caro prezzo.
Con la memoria virtuale si potevano simulare quantitavi maggiori di memoria, sfruttando la più economica memoria di massa.
No, ricordo perfettamente che avevo trovato su Aminet un programma per emulare la memoria virtuale sull’68EC20, tant’è che con ImageFX, programma di fotoritocco e di effettistica mi divertivo a creare delle bitmap enormi, qualcosa come 10.000×10.000 e ci renderizzavo effetti.. l’hd macinava delle ore, ma alla fine il programma funzionava, pur avendo 6 Mb di RAM :D
Strano, perché su GigaMem ho trovato questo:
Se la memoria virtuale è stata implementata esclusivamente a livello software, immagino che la lentezza sarà stata mostruosa (ci sono da realizzare due context switch per ogni singolo accesso alla zona di memoria “virtualizzata”).
Infatti sul nome del programma non ci giurerei perché non me lo ricordo (dovrei andare a rispolverare l’Amiga) ma un emulatore di memory paging per CPU senza MMU esisteva, lo usavo :D
Era lento per un uso produttivo, ma per giocarci un pò poteva andare.
Se funzionava anche senza MMU, penso richiedesse quanto meno un 68010, perché, come dicevo anche nell’articolo, al 68000 mancano alcune caratteristiche per poter gestire correttamente la virtualizzazione delle risorse (in particolare la memoria).
Allora dopo molte ricerche l’ho ritrovato: si chiama VMem, si trova su Aminet.
A un’occhiata veloce ai molti docs allegati non ho trovato la cpu minima richiesta, ma immagino che ci sia scritto.
Ho scaricato il pacchetto, letto la documentazione e visionato il codice della demo allegata, ed effettivamente funziona con qualunque Amiga.
Ma non è applicabile a tutti i programmi, perché si tratta di una libreria che espone delle API per dis/allocare e lockare (quando è necessario utilizzare un certo blocco di memoria virtuale allocato) blocchi di memoria.
Quindi è necessario che i programmi siano scritti appositamente per utilizzare questa libreria, ed è abbastanza scomodo.
Tra l’altro è concettualmente simile a un progettino che avevo realizzato parecchi anni fa in Turbo Pascal per DOS, dove sussistevano gli stessi problemi (non esisteva la possibilità di sfruttare la memoria virtuale). ;)
A me pare che nell’articolo si faccia un po’ di confusione tra virtual memory (abbreviata anche con VM) e virtual machine (pure questa abbreviata con VM) e virtualizzazione X86.
La memoria virtuale come molti programmatori (di sistemi operativo oppure gente che non si limita ad usare VB) sapranno non è soltanto un modo per far percepire più RAM al PC, anzi mi sembra proprio riduttivo forse sbagliata pensarla in questi termini.
Per ciò che concerne la virtualizzazione x86 non solo il processore, ma tutta l’intera piattaforma hardware deve essere virtualizzabile per soddisfare i requisiti di Popek e Goldberg. Dunque il problema al processore è stato risolto con AMD-V e VT-x, ma ad esempio altri miglioramenti sono stati introdotti con le ulteriori VT-d.
Ai tempi della stesura dei requisiti formali per la virtualizzazione nel 1974 è nato solo un calcolatore in grado di rispettarli, successivamente i progettisti hanno preferito lasciar perdere perché i tempi non erano maturi. Quando Intel ha sfornato l’attuale architettura non c’era necessità di creare una piattaforma virtualizzabile, per questo non s’è preoccupata di implementare tali funzionalità e restrizioni.
L’articolo non riguarda la famiglia Intel x86, ma esclusivamente quella Motorola 680×0, e in particolare il 68010, successore del 68000.
Tratta della virtualizzazione in generale (ma sempre legata a questa famiglia) e, in quanto una parte di essa, anche della memoria virtuale.
Prova a rileggere l’articolo: in nessuna parte si parla di x86 né tanto meno degli ultimi rappresentanti di tale famiglia.
“Tratta della virtualizzazione in generale […] e, in quanto una parte di essa, anche della memoria virtuale.”
valent qui ha ragione, c’e’ un po’ di confusione in proposito: secondo questa affermazione (parlando sempre di implementazioni con pieno supporto hardware) la memoria virtuale sarebbe un sottoinsieme dei requisiti per la virtualizzazione, il che non e’ vero.
Fra le risorse virtualizzabili da un processore, c’è anche la memoria.
Ma per la memoria virtuale il supporto hardware per la virtualizzazione (req. popek-goldberg) non e’ necessario.
Non mi sembra di aver tirato in ballo i requisiti di Popek-Goldberg per la virtualizzazione nel mio articolo.
Ho parlato di virtualizzazione delle risorse in generale, fra cui anche la memoria.
E invece si, magari non te ne sei accorto ;-) :
“un grossolano errore di progettazione commesso da Motorola”
e
“l’introduzione dell’istruzione MOVE CCR, facendo al contempo diventare privilegiata la già esistente MOVE SR”
Il grossolano errore era proprio il non soddisfare i requisiti di Popek-Goldberg, da qui l’introduzione delle nuove istruzioni.
“The Motorola MC68000 has a single unprivileged sensitive instruction:
* MOVE from SR
This instruction is sensitive because it allows access to the entire status register, which includes not only the condition codes but also the user/supervisor bit, interrupt level, and trace control. In most later family members, starting with the MC68010, the MOVE from SR instruction was made privileged, and a new MOVE from CCR instruction was provided to allow access to the condition code register only.”
http://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements#Motorola_MC68000
Sì, questo conferma che la virtualizzazione era fallata, ma il mio obiettivo non era quello di citare i requisiti di Popek-Goldberg. Sicuramente il problema della MOVE SR riguarda anche loro, ci mancherebbe, ma ho preferito esporre il punto di vista di un programmatore. Infatti, cito testualmente:
“Col 68000 era possibile modificare come si vuole questo registro e, quindi, un’applicazione aveva piena facoltà di fare il bello e il cattivo tempo sull’intero sistema”
e anche:
“quella di poter accedere ai flag dei codici di condizioni era ed è un’esigenza abbastanza comune”
e:
“Commodore risolse il problema con l’AmigaOS mettendo a disposizione nella ROM la routine GetCC che eseguiva una MOVE SR o una MOVE CCR a seconda che fosse stato rilevato un 68000 o un processore superiore (68010 incluso).”
Questo perché, avendo lavorato per parecchi anni con questa famiglia di microprocessori, sviluppare applicazioni mi portava necessariamente a dover affrontare queste cose.
Ma ribadisco che la loro risoluzione dal punto di vista meramente di sviluppo del software nulla toglie al fatto che, oltre a un fardello in meno per i programmatori, i requisiti della virtualizzazione venivano a loro volta soddisfatti.
Comunque l’articolo aveva lo scopo di trattare non soltanto la virtualizzazione delle risorse della CPU, ma anche la memoria virtuale. Te ne puoi accorgere sia dal fatto che ne ho parlato subito all’inizio:
“memoria virtuale, paginazione, file di swap, virtualizzazione delle risorse”
sia perché poi ho trattato rispettivamente prima il tema della virtualizzazione della CPU:
“Per realizzare la completa virtualizzazione delle risorse del microprocessore, furono aggiunte altre istruzioni.”
e poi esplicitamente quello della virtualizzazione della memoria:
“Da tutto ciò rimane, però, fuori la cosa più importante: la virtualizzazione della memoria.”
di cui ho parlato subito dopo aver esaurito il primo.
Se c’è qualcosa di “ambiguo” è sicuramente il titolo (dove ho parlato esclusivamente di “virtualizzazione”), ma qui da articolista devo fare di necessità virtù, poiché ho bisogno di qualcosa di estremamente sintetico (basti vedere la lunghezza tipica dei titoli che utilizziamo).
Infatti l’articolo e’ un po’ un calderone. Valent ha correttamente fatto un distinguo fra le “due VM”, che hanno requisiti hardware differenti.
L’articolo parla del 68010.
Per quanto riguarda virtualizzazione e memoria virtuale, sono state trattate entrambe e ognuna ha avuto precise parti dedicate nell’articolo, com’è possibile vedere anche dalle frasi che ho riportato.
Non vedo in che altro modo avrei dovuto parlarne, considerato che l’argomento era il 68010 e le innovazioni che ha portato rispetto al 68000.
Avrei dovuto scrivere un articolo in cui parlo della virtualizzazione col 68010, e poi un altro per la memoria virtuale implementabile sempre con lo stesso?
Non mi sembra la soluzione corretta, e non ne vedo altre.
Secondo me l’articolo cosi’ com’era creava confusione e si, andava scritto meglio. Just my 2 cents, tutto qui. Sono contento che nella discussione si sia fatta piu’ chiarezza.
I suggerimenti sono benvenuti. Anche perché di CPU ne dovrò parlare tante altre volte, e capiterà spesso di dover disquisire di particolari caratteristiche tecniche che potrebbero “confondersi” con altre. ;)
E io sempre a rompere le scatole, lo so che sono troppo pignolo XD
BTW apprezzo molto i tuoi articoli, per questo partecipo volentieri alle discussioni ;-)
Per questo ti ringrazio. :)
Le critiche, come sai, le accetto volentieri se mi possono portare a migliorare nel mio lavoro e, di riflesso, offrire un servizio migliore a chi ne usufruisce. :-P
a mio avviso l’articolo e’ scorrevole e ben fatto a patto che si abbia la dovuta elasticita’ mentale (quella per cui e’ istantaneo il distinguo fra le due “VM”, esattamente come si distinguono i diversi significati che una parola ha in un linguaggio a seconda del contesto e dei legami) e quel retobackground proprio di chi conosce un pochino gia’ a priori “come gira il fumo”
mi e’ piaciuto molto, sopratutto perche’ mi ha ricordato le magagne che son saltate fuori quando mi e’ capitata una scheda 68K in kit di montaggio (cioe’ PCB, zoccoli, quarzi, resistenze, la maggior parte di integrati), purtroppo vendutami sprovvista di cpu, ma equipaggiata con una potente eprom nella quale era contenuto il firmare tutor.v2 di motorola (e’ un monitor deassembler debugger circa padre di mon68k e similari, anzi forse e’ recensito anche su dt.dobbs annete ummm credo negli intorni del ’84).
Ecco, su quel firmware volevo compilare e far girare un kernel (scritto in assembler, quella sembrava la moda dei tempi) per far giare 4 task dimostrativi di come fosse possibile realizzare memoria protetta a basso costo su 68000
Ricordo distintamente che, la cosa mi trasse in inganno xke’ non avendo ben presente le differenze fra 68000 e 68010 acquistai proprio un 68000 DIL ceramico, ma essendo invece quel kernel scritto per 68010 (senza che pero’ fosse stato precisato nei sorgenti, grave dimenticanza!!!), si sollevarono un tot di trap inattese addizionate al fatto che SFC e DFC su 68000 non potevano lavorare come atteso.
Pensavo che il problema fosse a mio carico, chesso’ l’aver copiato male il listato (che trovai in un articolo), o l’averlo compilato male, o problemi legati all’hw (che avevo montato da me).
Impiegai 2 giorni per convincermi che le cause di quel malfunzionamento erano fra le righe dei sorgenti assembler che erano scritti per una cpu diversa da qualla che avevo acquistato
per la cronaca ero quasi propenso a non spendere altri quattrini e a cercare di “adattare” quel codice alla mia cpu; valutando se cio’ sarebbe stato fattibile decidetti di acquistare un 010 e di rimpiazzare lo 000: comprese le migliorie mi convinsi che eventuali workaround (di cui alcune patch all’hw negli intorni dei FC) compresi che sarebbero stati solo pagliativi
Finché si tratta di user space, le differenze fra 68000 e 68010 sono appianabili (è soltanto la MOVE SR il problema), ma un kernel lavora in modalità supervisore, e qui le differenze sono già abbastanza marcate.
Purtroppo Motorola ha avuto il non trascurabile difetto di cambiare dettagli della modalità supervisore in maniera non retrocompatibile (al contrario di Intel).
Quest’approccio ovviamente presenta pregi e difetti.
Il difetto è che i kernel vanno necessariamente adattati per supportare tutti i modelli (questo se utilizzano delle caratteristiche “avanzate”: function code, stack frame, MMU, ma anche la gestione della cache).
Il pregio è che si può scrollare di dosso eventuali errori o caratteristiche che possono portare problemi, migliorando le prestazioni o la flessibilità della CPU.
I guai sono saltati fuori quando ha cominciato ad applicare la stessa logica anche allo user space. :-/
eh, me ne sono accorto sul 68060 dell’altra scheda, santa polpetta
cmq, mi chiedevo: esiste un modo elegante per un cpu_detect() con rispsota {68000, 68010, 68020, 68030, 68040, 68060} ?
sui ppc e sui mips su cui ha lavorato c’e’ un apposito registro che, se interrogato, risponde proprio in questi termini “sono una cpu di classe tal dei tali, ho mmu si/no, ho fpu si/no, e altre caratteristiche”
e per m68k ?
a dirla tutta avrei il firmware “mon68k” che in qualche modo distingue tutta la linea di cpu, dal 68000 al 68060, ma mi e’ stato fornito gia’ inserito in una eprom … l’ho letta, ho il binario, dovrei cercare di disassemblarla per poi carpirne il suo segreto
ecco, prima che io mi metta in mente di fare tutto cio’: esiste un esempio ? doc o quantaltro ?
Non esiste un apposito registro, come per i PowerPC, perché si tratta di CPU molte vecchie per le quali non era ancora stata pensata una funzionalità di questo tipo.
E’ da troppo tempo che non lavoro con i 680×0 per cui non ti posso fornire un sorgente, ma soltanto alcune indicazioni su come fare.
Sfrutterei, quindi, le caratteristiche peculiari di ogni CPU. Per semplicità procederei col il riconoscimento o meno delle istruzioni non implementate, facendo puntare l’apposito vettore a una mia routine il cui unisco scopo sia settare a 1 una predefinita locazione di memoria (ad esempio $0.b: il primo byte in assoluto).
Quindi per stabilire se ho un 68000 o un successore, proverei a eseguire una MOVE CCR. Se scatta l’eccezione, è sicuramente un 68000 (è l’unica CPU di questa famiglia che non ha questa istruzione), altrimenti è un 68010+.
Per stabilire se è un 68010 o un altro, proverei a eseguire una EXTB. Se c’è l’eccezione, è un 68010 (che non ha quest’istruzione), altrimenti è un 68020+.
Per stabilire se è un 68060, utilizzerei una MOVEP (o una CHK2), che non è presente in questa CPU.
Per il 68040, eseguirei una MOVE16, che è presente in questa CPU (e nel 68060).
A questo punto rimangono soltanto 68020 e 68030. Il primo ha soltanto una cache per il codice, mentre il secondo anche una per i dati. Per cui eseguirei un’istruzione che cerca di leggere o settare i registri o i bit della cache dati per stabilire se è un 68030 (tutto OK) o un 68020 (fallimento).
I test vanno eseguiti nell’ordine indicato.
un contro articolo agli antipodi potrebbe essere “virtualizzazione ad alto, altissimo, costo”
beh, se fosse un controarticolo “storioco” allora le suonerebbe abbastanza, facendo notare di quanti anni fosse avanti IBM almeno nel concetto di memoria virtuale
ma se quelle sono grandi e pesantissime international business machine per elaborare dati e costruire informazioni utili in ambito aziendale
dove quindi vale la regola del “tanto I/O, poco calcolo”
e cio’ e’ l’opposto di quanto serve in un pc dedicato
(per esempio, ad un gioco o ad un calcolo matematico o alla grafica)
se proprio un confronto non ha ragione
allora restando in tema
e in tema circa negli stessi pesi elefantici
+ all’antitesi del concetto stesso di virtualizzazione
ovvero erodendo il concetto stesso di approccio software
ecco la “Physicalization”
– Hardware-based Virtualization – no Software Required –
ci prova, a fare le cose al contrario e in grande, SGI
-> http://www.sgi.com/products/servers/microslice/
C’è da dire che è proprio IBM che ha inventato il concetto di virtualizzazione. ;)
Quanto alla soluzione di SGI, purtroppo mancano i dettagli per capire in che modo funziona questa “fisicalizzazione”.
appunto “IBM le suonerebbe mostrando quanti anni fosse avanti”
per esempio, parliamo di “pipeline”?
si scopre che nel 1967 IBM mentre rilasciava il primo 360/91
gia’ introduceva il concetto di “pipeline”
(inventato da R.Tomasulo)
parliamo di “cache memory” ?
e il 360, con tempo medio d’accesso di 80 nano secondi, introduceva anche quella
ben 10-12 volte piu’ veloce della standard magnetic core memory
parliamo di “memoria virtuale” ?
scopriamo che nel 1970 l’evoluzione dei sistemi 360 si distingue per la gestione della memoria virtuale, fatto decisamente inedito.
La famiglia 370 portera’ negli nni a venire molti tecnici al di fuori del mondo IBM a denigrare la bassa capacita’ di memoria di alcuni sistemi IBM rispetto ad altre marche, non conoscendo le funzioni straordinarie della gestione della memoria virtuale.
Se per quei tempi il meccanismo poteva essere “visionario” i fatti “moderni” hanno incontroverbilmente dimostrato quanto costoro errassero gravemente: per poter funzionare, un programma, deve essere caricato nella memoria centrale del computer. Se la memoria e’ troppo poca il programma non gira.
Nei sistemi mainframe e mini IBM il problema e’ stato risolto con la memoria virtuale, che consente una gestione totalmente automatica di carico/scarico di parti di programma, non richieste in un determinato momento, da disco a memoria centrale.
Ma non solo!, una altra funzione molto importante e’ il “virtual storage” (come lo chiama IBM), che consente di caricare in memoria parti di dati di cui il sistema prevede il prossimo utilizzo. In questo modo la macchina non deve chiedere frequentemente i dati che le servono, perche’ questi si trovano già disponibili nella memoria centrale. In sostanza il sistema vede memoria centrale e memorie di massa come un tutt’uno.
ma la rivoluzione, quella vera, e’ nel 1978
ovvero 2 anni prima che il prototipo del PC IBM vienise estremamemente semplificato, ridisegnato da Donald Estridge, in modo che potesse entrare negli stipendi della gente comune, e poi spedito in Microsoft,
quella piccola azienda che non conosceva nessuno, ma che vendeva BASIC per macchine come l’Altair 8800, e che per IBM avrebbe invece dovuto confezionare quel sottile ed innocente sistema operativo DOS capace di far girare applicazioni assai modeste, senza pretese di affidabilita’, scalabilita’, e quantaltro ai tempi NON necessitava di timesharing, multitasking, etc, e quanto era stava per essere annunciato.
Prima di svelarlo, un attimo di suspense … per ricordare che il core business IBM ha sempre ruotato nel gestire in modo estremamente sicuro ed efficiente una rete aziendale:applicazioni multiutente di buon livello, con ampio ventaglio per tutti i settori aziendali, oltre che piena coperatura anche per le esigenze di enti pubblici.
Questi sono gli obiettivi che portarono la vera grande immensa rivoluzione segnata nel 1978 dal lancio del sistema S/38, pensato per abbattere il limite imposto dalla memoria, creando un continuo unico tra memoria e disco
era nata la memoria virtuale, l’abbiamo gia’ detto, ma non solo! Veniva anche introdotto anche il concetto di oggetti incapsulati (le fondamenta della sicurezza, quella vera, in multiutenza blindata)
e per finire, veniva introdotto anche il concetto di macchina virtuale, un meccanismo capace di rendere indipendente il layer applicativo dalla substrato hardware sottostante
shock: era francamente troppo meraviglioso!
tanto che nel ’78 quella macchina (e il suo sistema operativo) era dannatamente difficile da comprendere, ma non solo per i clienti parecchio sbigottiti, ma sopratutto per gli sviluppatori che preferirono restare coi piedi per terra
l’esperienza non segno’ tante vendite ma getto’ le fondamenta dei successivi AS400
xke’ l’obbiettivo primario era, come sempre, rendere il sistema ottimizzato per elaborare transazioni, tante transazioni, tanto, ma proprio tanto IO !
i successivi sistemi operativi si presentarono omogenei e completi, ma la grossa novita’ stava nel fatto che il software al lato applicativo, cioe’ quello vicino al cliente, era stranamente indipendente dalle evoluzioni hardware!
Pazzesco ! Del resto l’obbietto “macchina virtuale” era centrato al punto che offriva compreso nel prezzo un database relazionale integrato ai più bassi livelli di macchina!
e non solo! gran parte della virtualizzazione rendava davvero possibile operare con tecnologia Object Oriented (e siamo solo nel 1988!), in modo ampiamente scalabile, lavorando in multiprocessing, e, cosa fodamentale: progettato garantendo la massima sicurezza e riservatezza a causa della sua struttura interna (la tipicizzazione quasi richiama i concetti moderni introdotti da SUN con java)
Gli AS400 hanno cambiato parecchie volte l’archietettura delle cpu degli strati harware + bassi, questo la dice lunga non solo sulla virtualizzazione ma anche sulla filosofia (non solo) IBM circa la struttura dell’architettura di un sistema di elaborazione: ovvero che non debba gravitare completamente e solamente sulla velocita’ del processore (o dei processori) “centrali”, non devono premiare SOLO la cpu (central process …), anzi al contrario, questi sistemi dispongono diversi processori specializzati in vari compiti per ottimizzare tutto il flusso di elaborazione degli input e degli output: sono macchine per elaborare dati e costruire informazioni utili in ambito aziendale, quindi vale la regola del “tanto I/O, poco calcolo”, che e’, come detto, l’opposto di quanto serve in un pc dedicato, per esempio, ad un gioco o ad un calcolo matematico o alla grafica.
Ora, arrivando circa ai nostri anni, nel 2000 IBM presenta una nuova serie di server AS/400, chiamti “iSeries”, di classe paragonabile ai mainframe per affidabilita’ e scalabilita’, diffondendo il supporto agli open standard per lo sviluppo di nuove applicazioni e introducendo il concetto di potenza su richiesta (capacity on demand) utilissima per superare nelle aziende i picchi di necessita’ elaborativa, senza per questo ricorrere a macchine piu’ potenti.
Fra le feature e’ possibile partizionare i dischi (LPAR) in modo da rendere disponibili parallelamente sistemi operativi diversi, ma tutti sotto la garanzia di affidabilità dell’hardware ormai ultrasperimentato.
Nel 2003 arrivano anche i server serie z, fra cui lo z990 che vanta features sbalorditive:
partendo dalla tecnologia del modulo di CPU, realizzato in MultiChipModule, ai risultati, pari a 9.000 mips, 13 miliardi di transazioni al giorno, l’affidabilita’ meno di 5 minuti di downtime all’anno, e le possibilita’ di distribuire dinamicamente i workload all’interno della macchina in base alle priorita’ stabilite dal cliente.
ora, le info sono poche, il contesto e la filosofia sono diametralmente opposto, ma spannometricamente a questa idea del partizionamento hw ha lavorato anche SGI (che progetta supercomputer, cioe’ oggetti con obiettivi ben diversi da quelli di IBM, anche xke’ SGI va fiera della sua tecnologia numaflex, orientata ai cluster), andando a dividere parte dell’hardware sottostante in “isole, muclei atomici di processo” (sgi usa il nome “MicroSlice”), in modo che sia possibile ripartizionarlo, scalarlo, e quantaltro
(capire come lo faccia “esattamente” non e’ mai stato motivo di documentazione pubblica, tanto che SGI si rifiuta di rilasciare documentazione, non solo di “grosse macchine”, dove sarebbe comprensibile il mantenere il segreto, al limite concedendo qualche slide a possibili clienti (ti interessa la tech SGI ? mostrami le tue credenzialita’, fissa un appuntamento, ti invio qualcuno dei nostri), e questo fino al punto di non voler rifiutare il rilascio di documentazione anche di workstation ormai fuori produzione, cestinando possibili persino accordi di riservatezza ai fini, messi per iscrtto, di studio e riutilizzo del suo obsoleto hardware per un hobbistico “farci girare linux, per bene, senza rattoppi”)
p.s.
qualcuno ha pdf/doc elettronica di
* segment MMU mc68451
* page MMU mc68851
non riesco a trovarla in rete
Per il 68851 trovi un po’ di documentazione e la completa codifica e spiegazione delle singole istruzioni nel manuale della famiglia 68000: http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf
Del 68451, invece, non avevo mai sentito parlare e non ho trovato niente.
del mc68451 ne parla, beh, accenna qualcosa, Clements nel suo book sul 68k … pero’ mi sarebbe davvero piaciuto sbirciare la il datasheet xhe’ ho fisicamente un chip mc68451, che e’ impiegabile solo con 68010 (il 68000 no, o meglio e’ sconsibliabile)
questo xke’ sto progettando un board minimale e sto valutanto se impiegare il chip nudo e crudo che ho, oppure se sintetizzare una MMU nella CPLD che andra’ gia’ a gestire parte del board: il concetto e’ meno chip uso, + e’ facile il PCB, + sono felice
Onestamente è un campo su cui non ho mai lavorato (eccetto per il reverse engineering di alcune schede da sale giochi), per cui non ti saprei dire.
M’interessano invece i datasheet per qualunque CPU e periferiche annesse, per cui dovessi trovare qualcosa su 68851 o 68451 mi faresti cosa gradita se postassi il link.
niente da fare, non si trova + nulla
sto per acquistare doc cartacea della paged MMU mc68851, a scopo didattico (non voglio impiegarla, troppo complessa, e quel punto impigherei un 68030 con MMU, una versione semplificata proprio della mc68851, gia’ integrata)
francaemente per il kernel semplice che ho in mente una paged MMU e’ esagerata
quindi penso che, per la mia m68010 board, mi sintetizzero’ qualcosa di molti simil a quanto fu fatto per Apple Lisa
ovvero qualcosa che soddisfi l’equazione
if (!S) PA=(VA && MASK) + DISPLACEMENT
else (!S) PA=VA
Physical Addrss
Virtual Address
Praticamente un sistema di traslazione a un solo livello da VA a PA. Estremamente semplice.
Beh, certo, dipende sempre da quello che vuoi farci. Se il kernel è “semplice” (non so com’è strutturato) come dici, può andare bene.
esatto! e cosi’ posso anche rilassarne l’implementazione in VHDL, sia per complessita’, sia per risorse richieste
fra l’altro ho spulciato la documentazione tecnica di Apple Lisa scoprendo che anche la loro MMU usava un approccio simile: PA=VA + displacement!
ora, considerando che una unita’ segmente MMU mc68451 riesce a gestire solo 32 Task, considerando che aggiunge 4 cicli di clock per la traduzione, che necessita esclusivamente di un 68010, e considerando che 32Task indirizzabili rischiano di essere oggettivamente pochi al punto che sarebbe auspicabile porre almeno un paio di mc68451 in parallelo (cosa prevista, dunque fattibile) per scalarne il numero di Task indirizzabili (2×32): beh, visto che in embedded cio’ che si vende e’ 68ec/hc000, visto che della mc68451 non c’e’ documentazione (ne fornitura), ma che sopratutto queste MMU sono in fin dei conti di compromesso circuitale tanto quanto algoritmico: ma allora xke’ dunque non sintetizzare qualcosa di specifico, che riutilizzabile con core 68000 in commercio, e che concorra a semplificare ulteriormente l’intero progetto ?
detto fatto, e il picoKernel ringrazia
Immaginavo, ma io mi chiedo: non conviene buttarsi direttamente su soluzioni embedded che abbiano già integrata una MMU (magari più semplice, come quella presente nel 68030 o nel 68060)?
Così si eviterebbe di dover progettare parte di una circuiteria, per quanto sia di gran lunga più semplice il modello PA=VA+Offset.
Non sono un esperto di sistemi embedded, per cui non riesco a capire quali vantaggi possa portare una soluzione custom (che richiede maggiori costi di progettazione, e relativa perdita di tempo) rispetto a una preconfezionata.
Mi sfugge il dominio applicativo nel suo complesso.
in campo embedded si diventa maniacali, meno codice si scrive meglio e’ (a volte meno memoria dinamica, malloc per capirci, si usa, meglio e’)
ne consegue che si tende a fare sistemi con task statici, memoria statica, poco codice e molto diretto al “problem solution”: questo xke’ impiegare una MMU (paged oriented) costa MOLTO in termini di codice!
nel mio caso, a maggior ragione, il problem e’ … general purpose avocation, cioe’ hobby & learn for research
sicche’ il primo punto e’ stato capire le differenze fra una segment MMU e una paged MMU, per poi farsi una idea di cosa altro si possa fare (‘case we want to reinvent the wheel) per limare al massimo il codice da scrivere senza scendere al compromesso dei task statici
ora, dagli studi e’ emerso che usare la MMU mc68851 e’ pari ad usare la MMU integrata in mc68030,40,60,..: stessa filosofia (paged MMU handling), stessa complessita’ (anzi la mc68851 e’ un filo + complessa, + transistor, qualche funzioncina in +, delle MMU integrate)
il punto allora e’:
* il progetto e’ nato per scopo hobbistici
* quindi ha poco man power e poco tempo a disposizione
* il kernel vuole essere semplice
* ma non cosi’ “castrato” da dover ripiegare sul multi-tastking statico
* le cpu target sono tutte CPU mmu-less (tipo mc68HC000)
* quindi serve supporto MMU hw, esterno, per realizzare “memoria virtuale a basso costo”
* (che poi e’ il titolo di questo thread)
* dove “costo” e’ espresso in termini di man power, si: proprio tempo e codice da scrivere (nonche’ bug, nella filosofia the more lines you write the more bugs you have to find)
una volta studiato cio’ che esiste, visti pregi e difetti, e relativi compromessi, si e’ pensato ad un possibile riutilizzo del nuovo know/how: quindi se prima ha avuto senso pensare (e studiare come) stare leggeri col codice impiegando una MMU sempliciotta come la mc68451, ora (anche, ma non solo, xke’ e’ un chip obsoleto, sprovvisto di doc) si pensa di riutilizzare quanto appreso in campo per confezionare qualcosa di nuovo che possa essere benissimo infilato in un progetto di sintesi di + ampio respiro
gia’, non e’ troppo complesso infatti recuperare il codice VHDL della “picoMMU” (che massimizza al massimo i compromessi circuitali ma anche e sopratutto di codice al lato OS) ed aggiungerla (proprio come blocco funzionale) al progetto di una cpu (e magari anche RISC) in sintesi: tutto OnChip, tutto semplice, tutto gestibile con poche risorse “umane”, senza dover scomodare soluzione “preconfezionate”, che sono, in tutta franchezza “grasso che cola”
chiudo lasciando intendere che il progetto della picoMMU e’ un filo + complesso di quanto ho riassunto prima come linee (o meglio bozza) base:
quanto ho implementato, infatti, modella lo spazio virtuale (VAddr) di un task in 4 blocchi distinti
1) stack
2) data
3) text (codice eseguibile)
4) shared memory
la traduzione VAddr –> PAddr passa dunque per 4 comparatori di area if (min
(c’e’ un limite di caratteri per risposta, asd)
dicevo
1) stack
2) data
3) text (codice eseguibile)
4) shared memory
la traduzione VAddr –> PAddr passa dunque per 4 comparatori di area
if (min
no, c’e’ un problema con le graffe
ri-dicevo (poi mi arrendo)
la traduzione VAddr –> PAddr passa dunque per 4 comparatori di area
if (min
ahhh, il problema e’ un segno di minore fra parentesi ?
ri-dicevo (poi mi arrendo)
la traduzione VAddr –> PAddr passa dunque per 4 comparatori di area
if (x in min..max) in_range=true
if (!S) switch (Vaddr) // user space address
(
range stack: PAddr=VAddr+stack.displacement;
range data: PAddr=VAddr+data.displacement;
range text: PAddr=VAddr+text.displacement;
range shared: PAddr=VAddr+shared.displacement;
default trap picoMMU_address_error;
)
else PAddr=VAddr; // superuser space address
la picoMMU si compone di 4 registri che necessitano di aggiornamento ad ogni context switch
32bit stack.displacement;
32bit data.displacement;
32bit text.displacement;
32bit shared.displacement;
tot 4x32bit=4x4byte=16byte OverHead
(si, il 68000 ha 24bit di addr esterni, volendo si possono risparmiare 4byte spillando 1 byte per ogni registro: si hanno 12byte al posto di 16byte)
restano altri registri
* da inizializzare al kernel_mmu_init
* oppure per “task” particolari
32bit stack.range.min stack.range.max;
32bit data.range.min data.range.max;
32bit text.range.min text.range.max;
32bit shared.range.min shared.range.max;
un modello molto semplice ma efficace!
No, ti prego, non troncare gli indirizzi a 24 bit anche tu: è una cosa che ho sempre odiato dai tempi dell’Amiga (e del famigerato AmigaBASIC che utilizzava gli 8 bit superiori degli indirizzi per memorizzare flag e informazioni varie). -_-
Comunque ho capito le finalità, ma a livello di costi, per un hobbista, c’è comunque così tanta differenza fra una soluzione già bella e pronta (come la serie 683xx di Motorola/FreeScale) e una basata su 68HC000 + logica ad hoc?
Per il resto è evidente, da quel che scrivi, che paragonata alla tua soluzione custom, una PMMU classica è un mammuth. :D
assolutamente si!
in termini di codice da scrivere, in termini di riutilizzo di codice (specialmente vhdl), in termini di possibilita’ di impiego su altre cpu!
per esempio oggi ho dotato anche una m68hc11-board (si, un core 6800, 2 zeri, leggete bene), di picoMMU per non dover + avere a che fare con task statici: su uno 00 c’e’ il grosso problema di non avere istruzioni privilegiate ne 2 stati S/U, salta il paradigma delle strutture necessarie al multitasking (il kernel in stato privilegiato, i task in stato utente, qui e’ tutto sullo stesso piano), tuttavia anche ricorrendo a trucchi il disegno della picoMMU (in questo caso scalata dati ad 8bit, addr a 16bit) ha aiutato parecchio nel confezionare un kernel capace di muovere task dinamici
ora, questo obiettivo e’ “sfizioso”, ma immagina cosa si puo’ dunque fare sintetizzando tutto, per un core RISC, magari picoRISC, entro una fpga: per l’hobbista finale, anzi non solo per l’hw-rista, ma anche per colui che dovra’ scrivere e gestire il kernel, sara’ una pacchia!
addr di 24 o 32bit ? eleganza e linearita’, salvo o non salvo il package, si chiese motorola
se la picoMMU e’ memorymapped in supervisior data area, allora aggiornare i suoi registri significa muovere 4 byte sul bus dati (ne + ne meno di una periferica qualsiasi, cosi’ e’ vista in supervisor data area). Ora, muovere sul package del 68000 gli addr bit son 24bit e sembra essere vantaggioso risparmiarsi 1 byte, ma si scopre invece che costa SEMPRE di meno una move.l di 4 byte che 3 move.b che 1 move.b, o da una move.w di 2 byte seguita da 1 move.b da 1byte. Costa di meno in termini di istruzioni e di cicli bus. Vero, non c’e’ nessun vantaggio =P
p.s. ah, dimenticavo di specificare che, come nel caso della mc68451, anche questo approccio di traduzione da VA a PA per essere “stabile” costa (purtroppo) 4 stadi sincroni al clock della cpu. Costa dunque 4 cicli di clock, e bisogna tenerne conto.
Mi sembrano tanti 4 cicli per un’implementazione così semplice: è un limite dell’FPGA (so che ne esistono diverse versioni; più o meno economiche, più o meno performanti)?
Il 6800 lo conosco (ho realizzato anche un articolo su di esso) e nella sua incarnazione migliore, il 68HC11, è un vero gioiello (pur essendo un microprocessore a 8 bit).
4 cicli di clock e’ un limite imposto dalle tempistiche necessarie a propagare in modo corretto i segnali all’interno degli stadi, non tanto limiti ditenlogia a disposizione quanto limiti di progetto superabili SOLO riprogettando in modo + furbo
(un po’ come e’ stato fatto dal MIPR2000 in poi andando a creare scorciatoie per il forwarding dell’informazione negli stadi della pipeline, che di fatto ne hanno migliorato parecchio le prestazioni)
Nel mio caso occorre attendere un tempo necessario affinche’ gli indireizzi siano stabili, campionarli poi in un latch (campo VA).
In questa fase vengono attivati i 4 comparatori dei range dei blocchi (stack,data,text,shared)
bisognera’ attendere un tempo necessario affinche’ il risultato delle 4 comparazioni vada a selezionare il registo da dare in pasto alla ALU per il “giusto” displacement (stack.disp,data.disp,text.disp,shared.disp)
a quel punto la alu avra’ 32bit stabili di address e 32bit stabili del displacemente e dovra’ sommare bit a bit
per produrre in uscita finalmente il campo PA
il disegno + semplice che posso scrivere impiega 4 stadi, “garantiti ad informazione stabile”, pertanto chiede 4 colpi di clock
Potrei ridurre i colpi di clock prendnedo + confidenza con i veri tempi di propagaziione, trovando magari scorciatoie: e sara’ il prossimo passo, di raffinamento
Ho capito. Inoltre la soluzione è generale, perché ti permette di specificare qualunque cosa come displacement.
Comunque forse potresti risparmiare un ciclo di clock eliminando il sommatore finale (e quindi anche la sua circuiteria), e sostituendolo con un selettore che preleva n bit alti dal VA, e i rimanenti m bit (bassi) dall’apposito displacement.
In pratica una volta che il VA diventa “stabile”, vengono costruiti 4 indirizzi fisici “al volo”, prelevando i suoi n bit alti, e gli m bit (bassi) dei 4 displacement. A questo punto il comparatore dovrà semplicemente scegliere fra quale di questi 4.
Quindi avresti una sorta di paginazione della memoria (soluzione meno generale / flessibile rispetto alla tua), che potrebbe anche andare bene.
Certo, bisogna vedere sempre in che modo si prevede di implementare il kernel e le applicazioni, ma potrebbe rivelarsi un buon compromesso.
il super trucco, volendo c’e’!
e’ l’asso nella manica poco elegante ma molto efficacie che vorresti non dover giocare se non proprio proprio non ci sono altre carte, xke’ costa, e costa parecchio (in termini di euro al chip)
si puo’ pensare di ricorrere ad PLL per raddoppiare la frequenza di clock interna alla CPLD/FPGA
dunque, il clock CPU e’ di 12.5Mhz, con un PLL posso raddoppiarlo 2X in locale per una logica programmabile che regge tranquillamente fino a 50Mhz (con tempi di propagazione delle celle garantiti essere inferiori a 1/50Mhz) anche nei modelli economici, e! cosa essenziale, e! con un corridoio di aggancio di soli 5nsec di ritardo, quindi di fatto posso comprimere 4 cicli di clock in 2 cicli di clock senza stravolgere il progetto della picoMMU restando perfettamente allineato con il clock della CPU
volevo ordinare un paio di PLL da Distrilect semi, un mc88920 ha un syncing addirittura + veloce di 5nec richiesti: aggancia in in 2.5nsec
poi ho scoperto che queste meravigliosi PLL sono gli stessi PLL montati sull’apple LC475: in Distrilect c’era una ottima fornitura, alcuni addirittura largamente superiori ai requisiti
–> MC88920 is rated at 50MHz (2x25MHz bus
–> MC88916DW70 is rated at 70MHz (2x35MHz bus)
–> MC88916DW80 is rated at 80MHz (2x40MHz bus)
il modello + semplice costa oltre 40 euro, su ebay ho trovato 2 macchine LC475 funzionanti ed intere a 30 euro + 10 di shipping.
L’hobbista si arrangia, anche dissaldando un chip SMD per risaldarlo su adattatore DIL (5 euro tutto compreso dalla Cina) =P
ROFL: mitico! :D
Comunque aumentando il clock dell’FPGA… stai barando!!! :D :D :D
Però non credo che si possano dimezzare i cicli di clock. Molto dipende dal tempo che impiega l’address bus per stabilizzarsi. E’ soltanto quando il suo valore si trova stabilmente nel latch dell’FPGA, che è possibile poi “lavorare” anche a frequenze maggiori.
eh si, giocarsi l’asso nella manica e’ barare =P
tuttavia e’ un baro efficente, cioe’ che garantisce il risultato, xke’ se esternamente alla CPLD/FPGA ci si sincronizza su valori stabili dell’Addr proprio sul /AS (address strobe) della CPI, di li in poi, una volta campionati bit e’ affare della logica programmabile, la quale internamente e’ capace di propagare informazioni fra celle in tempi inferiori a 1/5Mhz, per esempio
e dunque stringendo stringendo, se i tempi di propagazione di un agglomerato di celle (e qui dipende dai percorsi segnati dal compilatore VHDL to bitstream, ma solitamente sceglie percorsi subottimi “abbastanza” buoni sia per spazio che per tempo) reggono allora si puo’ fare l’asso nella manica ha proposto di fare: dimezzare i cicli di clock visti da tutto cio’ che segue la picoMMU
tra l’altro si possono costruire half-adder molto veloci e comodi: il punto xro’, va detto, il punto rimane il disegno a stadi strettamente sincroni, xke’ tecnicamente gia’ il disegno del 68000 rispetto al disegno del 6800 ci insegna che si possono benissimo rilassare i vincoli sincroni pur garantendo tempistiche e funzionamento: ho ancora poca malizia e poche conoscenze in campo di logiche di sintesi per poter definire meccanismi asincroni infra stadio (per ridurre gli stadi), tuttavia e’ quantomeno intuibile il poter fare altrettanto internamente alla CPLD/FPGA
ah, in caso di IRQ, la picoMMU si vede un FCR proveniente da text&data-superuser-space, quindi cortocircuita tutti gli stadi a seguire per forwardare in uscita direttamente quanto ha campionato in ingresso: PA=VA in 1 solo ciclo di clock!
Purtroppo non ho alcuna esperienza nel campo delle logiche di sintesi, anche se l’argomento mi ha affascinato da sempre.
P.S. Ovviamente stavo scherzando prima, quando parlavo di “barare”. :P
[…] consigliabile settare il fido UAE per l’esecuzione del titolo alla massima velocità, con CPU 68010 o 68020 a tutta […]
…beh magari, per quanto riguarda la virtualizzazione negli anni 90 (su AMIGA), potremmo parlare di Fusion e Shapeshifter come i primi ad averla realizzata…
In quel caso non si può parlare propriamente di virtualizzazione a livello di CPU, quanto a livello strettamente software.
Si tratta di programmi che patchano opportunamente le ROM del Mac per simulare l’esecuzione su una macchina di quel tipo, sfruttando AmigaOS (e il Blitter).