Architettura x86

[AnonimoVeneziano]

x86 ha avuto successo perchè Intel è praticamente l'azienda che , col suo 4004, ha inventato i microprocessori a transistori su un chip .

Successivamente ha prodotto l'8080 , il suo primo processore a 8bit implementato nell' MITS Altair 8800 (il 4004 era a 4bit) , e poi ha inventato l'architettatura x86 su processori 8088 e 8086 usati da IBM nei suoi PC, l'architettatura x86 ha iniziato a prendere piede da qua , tanto che nel 1983 , quando uscì l'80286, era già il motore per molti PC diffusi nel mondo.

Il rivale Motorola 68k era superiore, ed era già un processore 16/32bit (una specie di ibrido con registri a 16 e a 32 bits) , al contrario della serie x86 che era ancora a 16 bit, ma nel 1979 , quando uscì era ormai stato già "fregato" dall' x86 che era stato scelto da IBM per i suoi PC . (8088 è uscito un po' prima ) .

Da qui la scalata al successo .

Nel complesso l'architettatura x86 non è una cattivissima architettatura , certo non tiene il passo dei PPC o dello stesso Motorola 68k , questo però + per motivi di legami col passato .

8088/8086 ha legami col vecchio 8080 a 8 bit , come 80286 ha legami con il 8086 e l'80386 con il 80286 e così via per motivi di compatibilità .

I nostri AthlonXP/64 o Pentium 4 oggi sono ancora in grado di far girare i programmi di 25 anni fa , e questo legame col passato ne impedisce un netto miglioramento .

L'architettatura PPC era un architettatura riprodotta da zero e progettata al meglio , quindi è ovvio che venisse fuori un ISA superiore a quello di Intel .

L'architettatura x86 è stata ritoccata da 25 anni a questa parte, ma per creare un vero e proprio miglioramento bisogna bruciare tutto e ripartire da 0 , anche l'x86-64 è un ritocco, e per questo non sarà mai al livello di un architettatura ex-novo che non centra nulla con l'ormai vetusto x86 , ma se si tiene l'x86 lo si fa solo per motivi di compatibilità con i programmi esistenti.

Ciao

[jappilas]

Originariamente inviato da AnonimoVeneziano
x86 ha avuto successo perchè Intel è praticamente l'azienda che , col suo 4004, ha inventato i microprocessori a transistori su un chip .

Successivamente ha prodotto l'8080 , il suo primo processore a 8bit implementato nell' MITS Altair 8800 (il 4004 era a 4bit) , e poi ha inventato l'architettatura x86 su processori 8088 e 8086 usati da IBM nei suoi PC, l'architettatura x86 ha iniziato a prendere piede da qua , tanto che nel 1983 , quando uscì l'80286, era già il motore per molti PC diffusi nel mondo.

Il rivale Motorola 68k era superiore, ed era già un processore 16/32bit (una specie di ibrido con registri a 16 e a 32 bits) , al contrario della serie x86 che era ancora a 16 bit, ma nel 1979 , quando uscì era ormai stato già "fregato" dall' x86 che era stato scelto da IBM per i suoi PC . (8088 è uscito un po' prima ) .

[altre cose tutte vere]

se solo ibm all' epoca non avesse cosiderato il 68k "troppo potente" per il target del PC originario...

[Pappy19]

Originariamente inviato da DioBrando
peccato la discussione sia degenerata

avevo visto un pò di tempo fà i filmati esplicativi sull'ultimo Cray ed erano ben fatti.

E architettura degli elaboratori è uno dei corsi + interessanti perlo- del 1° anno...peccato si siano fermati al- da me al PII e l'AMD n è manco citato

tanenbaum?

[ev8]

Originariamente inviato da jappilas
sì è la versione attuale della HP-PA Risc, più estesa (la 1.x era a 32 bit di indirizzamento)
la conditional execution sarebbe proprio associare a una istruzione una condizione, piuttosto che mettere quella istruzione in un branch (magari dopo un jump) ... per cui, dalla valutazione della condizione: se T -> eseguire l' istruzione ; se F -> l' operazione viene nullificata (saltata)
sembrerebbe che la PA applichi questa come una di 4 modalità(tra cui ANCHE i salti) a qualsiasi istruzione, a differenza di altre ISA (alpha e il set i586 ad es, la usano solo per la MOVE -CMOV)... Itanium invece va oltre coi predicati , ma già lo saprai...
per questa differenza, le dispense datemi all' epoca dal mio prof di calc. elett. II la chiamavano "full"

sul context switch sto approfondendo ...
sono anch'io un po' dubbioso, però da quelle pagine di powerpoint mi è arrivata una "pulce" abb interessante ..

sembrerebbe ci siano sti 8 registri "shadow", che vengono copiati (salvati/recuperati) in un singolo ciclo di clock ...

I PaRisc2 possono replicare in hardware i registri multipli di 8 ed i loro omologhi dispari ( 1,8,9,16,17,24,25 ).
Il mercato cmq non ha mai dato molto peso a questo genere di cose, perchè dal punto di vista procedurale non sono un gran chè costEffective.

http://h21007.www2.hp.com/dspp/tech/...IDX/1,1701,959!12!244,00.html
http://www.cs.umass.edu/~weems/CmpSc...5lecture4.html

sull' architettura 680x0 :

[cdimauro]

Originariamente inviato da jappilas
sì è la versione attuale della HP-PA Risc, più estesa (la 1.x era a 32 bit di indirizzamento)

Quindi HP continua per la sua strada, nonostante Itanium...

la conditional execution sarebbe proprio associare a una istruzione una condizione, piuttosto che mettere quella istruzione in un branch (magari dopo un jump) ... per cui, dalla valutazione della condizione: se T -> eseguire l' istruzione ; se F -> l' operazione viene nullificata (saltata)

Interessante: un po' più rozzo di quanto fa Itanium, appunto.

sembrerebbe che la PA applichi questa come una di 4 modalità(tra cui ANCHE i salti) a qualsiasi istruzione, a differenza di altre ISA (alpha e il set i586 ad es, la usano solo per la MOVE -CMOV)...

Ho capito meglio. C'è anche l'ARM di Acorn che prevede da tempo l'utilizzo dell'esecuzione condizionale per qualunque tipo di istruzione.

Itanium invece va oltre coi predicati , ma già lo saprai...

Già.

per questa differenza, le dispense datemi all' epoca dal mio prof di calc. elett. II la chiamavano "full"

Non si trovano online?

sul context switch sto approfondendo ...
sono anch'io un po' dubbioso, però da quelle pagine di powerpoint mi è arrivata una "pulce" abb interessante ..

sembrerebbe ci siano sti 8 registri "shadow", che vengono copiati (salvati/recuperati) in un singolo ciclo di clock ...

Questo però si potrebbe sfruttare soltanto nel caso in cui sei sicuro di effettuare il passaggio ad un thread ben preciso (e di cui conservi, appunto, qualche registro). Oltre a ciò, dovresti pure essere sicuro che le prime istruzioni ad essere eseguite usino proprio uno di quei registri "backupati", e ciò non sempre si verifica...
Insomma, mi puzza un po'.

http://h21007.www2.hp.com/dspp/tech/...IDX/1,1701,959!12!244,00.html
http://www.cs.umass.edu/~weems/CmpSc...5lecture4.html

sull' architettura 680x0 :

Il primo link non funziona, purtroppo. Il secondo è interessante, anche se non condivido assolutamente alcune informazioni (dà per scontato che i RISC sono migliori dei CISC...).

P.S. Sull'architettura 680x0 ho conservato vagonate di libri e informazioni varie...

[cdimauro]

Originariamente inviato da repne scasb
Mi rendo conto che stiamo discutendo di due cose sostanzialmente diverse; ossia la logica di connessione al bus dati del 68020 gli permette di fare richieste disallineate senza produrre eccezioni indipendentemente dalle caratteristiche del bus dati. La richiesta viene indirizzata al "dispositivo 1" che comunica la piu' o meno disponibilita' del dato al 68020; questa comunicazione avviene solo dopo che il "dispositivo 1" ha comunicato al "dispositivo 2" la richiesta del dato e la necessita' di convertirlo in un indirizzo fisico.

Cos'e' il "dispositivo 2"? E' una MMU che "NONE E'" un 68851 ma e' per esempio un MTEL 936S. [...]

OK, adesso è tutto più chiaro: effettivamente parlavamo di due cose completamente diverse.

Ora, per esempio l'MTEL 936S, ha soltanto 23 linee di indirizzamento per le conversioni e si differenzia per due revision: prima di C0 e dopo o uguale a C0. Prima di C0 accade la seguente cosa: "dispositivo 1" comunica l'indirizzo da 32 linee all'MTEL 936S, le linee da 23 a 31 e la linea 0 vengono semplicemnte "tagliate" senza provocare alcuna eccezione.

Anomalo che venga tagliata anche la linea 0, visto che nel 68020 serve per specificare l'allineamento dei dati. Evidentemente sarà presente qualche circuito PLA che si occupa di "riconoscere" e "gestire" questi casi...

Ossia MOVE.L ($1001),D0 e' uguale a MOVE.L ($1000),DO MOVE.L ($80000002),D0 e' uguale a MOVE.L ($2),D0 "indipendentemente" dalla CPU utilizzata perche' e' un "limite" delle caratteristiche di conversione della MMU.

Sì, è chiaro: anche nell'Amiga alcuni spazi d'indirizzamento eseguono il mirroring di zone di memoria o I/O.

Dopo o uguale alla revision C0 viene generata un'eccezione "esterna" della MMU (INVALID_ADDRESS), e quindi il "dispositivo 1" non comunichera' nulla al 68020 (il sistema pianta prima che il 68020 si riprenda (l'MMU comunica le eccezioni esternamente forse attraverso un PIC ma non ne sono sicura (quindi forse queste eccezioni si potrebbero riprendere)).

Il 68020 genera degli stack frame molto più "ricchi" di informazioni rispetto al 68000 (anche rispetto all 68010, che già permetteva gestire la memoria virtuale), per cui è sicuramente possibile riprendere l'esecuzione dell'istruzione "incriminata".
In teoria si potrebbe anche "emularne" il funzionamento in caso di indirizzamento "disallineato", effettuando il fetch dei dati per conto dell'istruzione, inserendoli nelle opportune locazioni dello stack frame, e facendo "ripartire" l'esecuzione dell'istruzione saldando la fase di fetch dei dati (facendo assumere alla CPU che sia stata completata con successo). Probabilmente.

Diciamo che stiamo in effetti discutendo di due cose diverse: tu di un dispositivo 68020 classico (p.es. Motorola MVME133), io di un dispositivo industriale moderno, in cui il 68020 viene "castrato" da esigenze di costi e di sviluppo.

Sì, adesso è tutto chiaro.

Per esempio a causa di tali limitazione la mia libreria di sviluppo per 68020 non accede "mai" ad un indirizzo dispari, anche se "so" che il 68020 sarebbe in grado di accedervi; per lo stesso motivo non accedo a nulla di piu' alto di $FFFFFC (pensa che su alcune MMU MOVE.L ($FFFFFE),D0 genera un eccezione esterna (BOUNDARY_LIMIT));

Giustamente, IMHO. D'altra parte in un sistema siffatto, dopo $FFFFFF non dovrebbe esistere nulla, no?

ancora a causa dei liniti sopracitati quando devo accedere a dei registri MMIO disallineati sono costretta ad utilizzare una MOVEP al posto di una MOVE.W.

Ma non era è più veloce eseguire:
MOVE.B D0, (A0)+
SHL.W D0, 8
MOVE.B D0, (A0)
?
L'istruzione MOVEP è troppo lenta, e se non ricordo male comporta l'utilizzo del clock "E", che viaggia a 1/10 di quello della CPU, utilizzando la modalità "compatibile" con le vecchie periferiche a 8 bit della serie Motorola 6800.
O forse non puoi proprio accedere a nessun indirizzo dispari, neppure nel caso si tratti di un byte?

Per quanto riguarda una MOVE.B ad indirizzo dispari credo che se ne occupi "dispositivo 1" ma non so come (forse chiede una word da cui ricava un byte).

Probabile. La CPU ha un multiplexer collegato al bus dati per gestire questi casi di letture/scrittura di byte, qualunque sia l'offset.

Diciamo, ancora, che nel mio primo intervento in questa discussione ho deficitato in chiarezza; nel momento in cui ho parlato di necessita' di allineamento di <EA> per un 68020, lasciando pensare che il 68020 non fosse in grado di indizzare dati disallineati. Quindi ritengo corretti e sensati i tuoi interventi successivi; da parte mia, nel mio primo interveno, o avrei dovuto esimermi dal citare l'ultima frase, o avrei dovuto chiarirla come spero di aver fatto in questo nuovo intervento.

Adesso tutto chiaro. Grazie per le informazioni che hai scritto.

[cdimauro]

Originariamente inviato da AnonimoVeneziano
Il rivale Motorola 68k era superiore, ed era già un processore 16/32bit (una specie di ibrido con registri a 16 e a 32 bits),

Non era un ibrido: l'architettura interna era/è a 32 bit (tutti i registri erano a 32 bit, eccezion fatta per il registro SR). Solamente il bus dati ESTERNO era a 16 bit.

I nostri AthlonXP/64 o Pentium 4 oggi sono ancora in grado di far girare i programmi di 25 anni fa , e questo legame col passato ne impedisce un netto miglioramento .

L'unico problema è con le istruzioni legacy, che sono molto complesse (quindi "pesanti" da emulare e far funzionare). L'architettura x86-64 ha rimosso tutte queste "vecchie" e quasi mai utilizzate istruzioni.
Comunque, anche con la loro presenza, l'architettura x86 è migliorata sempre...

L'architettatura PPC era un architettatura riprodotta da zero e progettata al meglio , quindi è ovvio che venisse fuori un ISA superiore a quello di Intel.

Come tutte le ISA realizzate ex-novo, ovviamente.

L'architettatura x86 è stata ritoccata da 25 anni a questa parte, ma per creare un vero e proprio miglioramento bisogna bruciare tutto e ripartire da 0,

Di quali miglioramenti parli? A cosa vorresti arrivare?

anche l'x86-64 è un ritocco, e per questo non sarà mai al livello di un architettatura ex-novo che non centra nulla con l'ormai vetusto x86 , ma se si tiene l'x86 lo si fa solo per motivi di compatibilità con i programmi esistenti.

Ciao

Non sono assolutamente d'accordo: dati alla mano, l'architettura x86 è quella che offre mediamente le migliori prestazioni a costi molto bassi rispetto a tutte le altre esistenti e non. L'età non c'entra nulla con la bontà e la scalabilità presente e futura di un'architettura.

[AnonimoVeneziano]

Originariamente inviato da cdimauro
Non era un ibrido: l'architettura interna era/è a 32 bit (tutti i registri erano a 32 bit, eccezion fatta per il registro SR). Solamente il bus dati ESTERNO era a 16 bit.

Non solo . Nella prima versione del 68000 i registri indirizzi erano a 32bit , ma solo 24bit erano utilizzabili , inoltre non tutte le istruzioni dell' ISA potevano lavorare a 32bit, ma molte lavoravano solo a 16bit , nonostante ciò è vero che l'M68k era + 32 che 16 bit, ma non era completamente 32bit , perlomeno non nelle sue prime versioni (che sono quelle che si sono scontrate con il 8086

L'unico problema è con le istruzioni legacy, che sono molto complesse (quindi "pesanti" da emulare e far funzionare). L'architettura x86-64 ha rimosso tutte queste "vecchie" e quasi mai utilizzate istruzioni.
Comunque, anche con la loro presenza, l'architettura x86 è migliorata sempre...

Non volevo certo dire che l'architettatura x86 non sia migliorata in passato , anzi , il fatto che dopo 25 anni sia ancora in uso significa che può resistere , ma certamente i legami col passato non gli hanno permesso comunque di potersi migliorare liberamente

Come tutte le ISA realizzate ex-novo, ovviamente.

Di quali miglioramenti parli? A cosa vorresti arrivare?

Intendo che è abbastanza ovvio che l'architettatura PPC sia superiore alla x86, semplicemente perchè gli studi sulle ISA che sono stati portati avanti negli anni sono state impiegati per creare un architettatura ex-novo migliore dell' x86, creata quando certi concetti (tipo CISC-RISC) non erano ancora stati chiariti .

Non sono assolutamente d'accordo: dati alla mano, l'architettura x86 è quella che offre mediamente le migliori prestazioni a costi molto bassi rispetto a tutte le altre esistenti e non. L'età non c'entra nulla con la bontà e la scalabilità presente e futura di un'architettura.

Non metto in dubbio, e sono ank'io convinto che x86 sia buono in questo , ma io intendevo un altra cosa.
x86 è un architettatura vecchia, che ha subito molti defacements negli anni , miglioramenti e cose varie , la sua complessità è cresciuta molto . Quando si arriva a un livello di complessità simile iniziano a mostrarsi i primi limiti dell'architettatura , ed essendo x86-64 ancora legato per molti versi all'architettatura progettata +di 25 anni fa è ovvio che AMD sia stata costretta a compromessi nella sua progettazione.

[cdimauro]

Originariamente inviato da AnonimoVeneziano
Non solo . Nella prima versione del 68000 i registri indirizzi erano a 32bit , ma solo 24bit erano utilizzabili,

La colpa non era dei registri indirizzi, ma del bus indirizzi esterno, a cui mancavano gli 8 bit superiori: difatti la memoria era in "mirroring" (si ripetevano i 16MB di memoria).

inoltre non tutte le istruzioni dell' ISA potevano lavorare a 32bit, ma molte lavoravano solo a 16bit ,

Al contrario, a parte quelle "legacy" (BCD, et similia), lavoravano tutte a 8, 16 e 32 bit. L'unica assenza era dovuta alle istruzioni di moltiplicazione e divisione, che erano presenti solamente nella forma 16x16->32 bit e 32/16 -> 16+16 bit rispettivamente; quindi niente 32x32 -> 64 e 64/32 -> 32 + 32, introdotte poi a partire dal 68020.

nonostante ciò è vero che l'M68k era + 32 che 16 bit, ma non era completamente 32bit , perlomeno non nelle sue prime versioni (che sono quelle che si sono scontrate con il 8086

Internamente lo era, e questo dal punto di vista dell'ISA, e quindi del programmatore: non aveva nulla a che spartire con i processori a 16 bit presenti al momento della sua introduzione.

Non volevo certo dire che l'architettatura x86 non sia migliorata in passato , anzi , il fatto che dopo 25 anni sia ancora in uso significa che può resistere , ma certamente i legami col passato non gli hanno permesso comunque di potersi migliorare liberamente

Se consideri le modifiche introdotte prima col 286 (la modalità protetta ha praticamente rivoluzionato il modo di lavorare, sia a livello utente che supervisore), poi col 386, e infine con l'x86-64 di AMD, IMHO ci troviamo a un'architettura che è stata decisamente rivoluzionata rispetto al progetto originale. E non di poco.

Intendo che è abbastanza ovvio che l'architettatura PPC sia superiore alla x86, semplicemente perchè gli studi sulle ISA che sono stati portati avanti negli anni sono state impiegati per creare un architettatura ex-novo migliore dell' x86, creata quando certi concetti (tipo CISC-RISC) non erano ancora stati chiariti.

Beh, all'epoca era la filosofia CISC a dominare. Comunque bisogna anche vedere cosa intendi tu per architettura superiore/migliore: in base a quale misura giudichi la bontà di un'architettura, e decidi che PPC è migliore di x86?

Non metto in dubbio, e sono ank'io convinto che x86 sia buono in questo , ma io intendevo un altra cosa.
x86 è un architettatura vecchia, che ha subito molti defacements negli anni , miglioramenti e cose varie , la sua complessità è cresciuta molto. Quando si arriva a un livello di complessità simile iniziano a mostrarsi i primi limiti dell'architettatura,

Guarda, fino a prova contraria sono proprio i RISC che hanno accusato i limiti della loro architettura: difatti molti nomi, anche prestigiosi, sono spariti dal mercato o lo faranno da qui a breve. E sono proprio i RISC che stanno cercando dei sistemi per sopravvivere.
Prendi, ad esempio, l'architettura Power di IBM: per poter scalare in frequenza ha dovuto allungare a dismisura le pipeline (si va da 16 stadi per le istruzioni più semplici, a fino a 26 per quelle più complicate: arriva a superare persino il P4 Northwood), e addirittura ha dovuto introdurre una specie di RISC semplificato al suo interno, per cui alcune istruzioni PPC vengono "scomposte" in altre più semplici per poter essere eseguite. Insomma, è esattamente l'approccio che Intel ha adottato col P4 per raggiungere delle frequenze elevate. Nonostante ciò, il P4 col processo a 0,13u (e senza SOI) ha raggiunto i 3,4Ghz, mentre Power4/5 è fermo a 1,7Ghz e il PPC970 (la sua versione semplificata) è a quota 2Ghz...

ed essendo x86-64 ancora legato per molti versi all'architettatura progettata +di 25 anni fa è ovvio che AMD sia stata costretta a compromessi nella sua progettazione.

Indubbiamente qualcosa è rimasto, ma è anche vero che tante cose sono cambiate. Difatti, come ti dicevo, tante istruzioni legacy sono state completamente eliminate (vedi AAA, BOUND, ecc.), l'architettura è stata resa più ortogonale (non esistono più i registri a 8 bit alti e bassi, caratteristica di una sola parte dei registri; adesso tutti i registri sono dotati dei soli 8 bit bassi), è stato introdotto qualche altra utile modalità d'indirizzamento (relativa al PC), ecc.
Insomma x86-64, invece di appesantirla, ha alleggerito e semplicificato molto l'ISA x86. E di questo te ne puoi rendere conto facendo un confronto fra l'ISA degli Athlon e quella presente in modalità nativa a 64 bit per questi nuovi processori...

[repne scasb]

[repne scasb]

[cdimauro]

Originariamente inviato da repne scasb
Scusa, non prendermi per pignola, ma:

Non ti preoccupare: spesso lo sono pure io...

1) Non devi shiftare a sinistra ma a destra.
2) SHL non esiste (mi sembra che hai fatto un mix tra 80x86 e 680x0) forse cosi' e' meglio:

MOVE.B D0,(A0)+
LSR.W #8,D0
MOVE.B D0,(A0)

E' si, forse sono proprio pignola.

Hai ragione: SHL è x86; si vede che è passato un bel po' di tempo da quando ho smesso di programmare con i 680x0.

Comunque se shifti a destra perdi completamente gli 8 bit che avevi appena letto. Per la lettura di una word in big-endian serve una LSL.W #8,D0; per una in little endiang, o si aggiunge una ROL.W #8,D0 (o ROR, tanto è uguale), o si fa a meno del postincremento e si legge prima il byte alto e poi quello basso...

Per il messaggio precedente è tutto chiaro. D'altra parte, se l'hardware funziona in quel modo, non hai alternative. Comunque odio i progettisti che mappano i registri a 16 o 32 bit ad inizi che non siano allineati a 16 o 32 bit...

P.S. I flip-flop li conosco, anche se nella pratica non li ho mai usati...