di  -  mercoledì 1 luglio 2009

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.

59 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
    Magilla
     scrive: 

    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.

  • # 2
    Giacomo
     scrive: 

    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…

  • # 3
    Cesare Di Mauro
     scrive: 

    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

  • # 4
    Marco
     scrive: 

    @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.

  • # 5
    Giacomo
     scrive: 

    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.

  • # 6
    Cesare Di Mauro
     scrive: 

    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).

  • # 7
    Steven
     scrive: 

    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.

  • # 8
    Cesare Di Mauro
     scrive: 

    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.

  • # 9
    Giacomo
     scrive: 

    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

  • # 10
    Cesare Di Mauro
     scrive: 

    Strano, perché su GigaMem ho trovato questo:

    Gigamem is a software product that allows Amiga owners to use
    hard drive space as RAM. All that is required is an Amiga with
    a 68040/030/020 with a memory management unit (MMU) and some
    free hard drive space. Gigamem will create an area on the hard
    drive that the operating system will see as RAM. This means you
    can easily handle images and projects that are too big for your
    current memory setup. Instead of buying additional RAM to handle
    one or two projects, you can use Gigamem to get you through!

    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”).

  • # 11
    Giacomo
     scrive: 

    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.

  • # 12
    Cesare Di Mauro
     scrive: 

    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).

  • # 13
    Giacomo
     scrive: 

    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.

  • # 14
    Cesare Di Mauro
     scrive: 

    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). ;)

  • # 15
    valent
     scrive: 

    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.

  • # 16
    Cesare Di Mauro
     scrive: 

    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.

  • # 17
    Marco
     scrive: 

    “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.

  • # 18
    Cesare Di Mauro
     scrive: 

    Fra le risorse virtualizzabili da un processore, c’è anche la memoria.

  • # 19
    Marco
     scrive: 

    Ma per la memoria virtuale il supporto hardware per la virtualizzazione (req. popek-goldberg) non e’ necessario.

  • # 20
    Cesare Di Mauro
     scrive: 

    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.

  • # 21
    Marco
     scrive: 

    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

  • # 22
    Cesare Di Mauro
     scrive: 

    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).

  • # 23
    Marco
     scrive: 

    Infatti l’articolo e’ un po’ un calderone. Valent ha correttamente fatto un distinguo fra le “due VM”, che hanno requisiti hardware differenti.

  • # 24
    Cesare Di Mauro
     scrive: 

    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.

  • # 25
    Marco
     scrive: 

    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.

  • # 26
    Cesare Di Mauro
     scrive: 

    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. ;)

  • # 27
    Marco
     scrive: 

    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 ;-)

  • # 28
    Cesare Di Mauro
     scrive: 

    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

  • # 29
    flameman
     scrive: 

    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

  • # 30
    Cesare Di Mauro
     scrive: 

    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. :-/

  • # 31
    flameman
     scrive: 

    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 ?

  • # 32
    Cesare Di Mauro
     scrive: 

    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.

  • # 33
    flameman
     scrive: 

    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/

  • # 34
    Cesare Di Mauro
     scrive: 

    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”.

  • # 35
    flameman
     scrive: 

    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”)

  • # 36
    flameman
     scrive: 

    p.s.
    qualcuno ha pdf/doc elettronica di

    * segment MMU mc68451
    * page MMU mc68851

    non riesco a trovarla in rete

  • # 37
    Cesare Di Mauro
     scrive: 

    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.

  • # 38
    flameman
     scrive: 

    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

  • # 39
    Cesare Di Mauro
     scrive: 

    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.

  • # 40
    flameman
     scrive: 

    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

  • # 41
    Cesare Di Mauro
     scrive: 

    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.

  • # 42
    flameman
     scrive: 

    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

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

    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.

  • # 44
    flameman
     scrive: 

    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

  • # 45
    flameman
     scrive: 

    (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

  • # 46
    flameman
     scrive: 

    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

  • # 47
    flameman
     scrive: 

    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!

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

    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

  • # 49
    flameman
     scrive: 

    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.

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

    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).

  • # 51
    flameman
     scrive: 

    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

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

    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.

  • # 53
    flameman
     scrive: 

    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

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

    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.

  • # 55
    flameman
     scrive: 

    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!

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

    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

  • # 57
    Stunt Car Racer, acrobazie in alta quota su Amiga - Appunti Digitali
     scrive: 

    […] consigliabile settare il fido UAE per l’esecuzione del titolo alla massima velocità, con CPU 68010 o 68020 a tutta […]

  • # 58
    Lorenzo
     scrive: 

    …beh magari, per quanto riguarda la virtualizzazione negli anni 90 (su AMIGA), potremmo parlare di Fusion e Shapeshifter come i primi ad averla realizzata…

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

    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).

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.

Current ye@r *