PDA

View Full Version : Architettura x86


smashing
04-06-2004, 18:09
Qualcuno mi sa dire un po' di storia su come questa pessima architettura abbia avuto così tanto successo?

ps: come vedete dalla sign la utilizzo anch'io anche se nel male minore (amd a livello di architettura interna è migliore di intel almeno secondo me) anche se il corso di architettura degli elaboratori alla mia università mi ha aperto gli occhi e sono MOLTO intenzionato a migrare almeno su ppc!

Johnn
04-06-2004, 19:47
Prova a guardare qui (http://www.lithium.it/articoli.asp?p=2&arg=processori) ...
Ciao!

nakodnas
04-06-2004, 20:12
Originariamente inviato da smashing
Qualcuno mi sa dire un po' di storia su come questa pessima architettura abbia avuto così tanto successo?

ps: come vedete dalla sign la utilizzo anch'io anche se nel male minore (amd a livello di architettura interna è migliore di intel almeno secondo me) anche se il corso di architettura degli elaboratori alla mia università mi ha aperto gli occhi e sono MOLTO intenzionato a migrare almeno su ppc!


W i MIPS e gli storici ALPHA!

Guarda l'architettura di " ALPHA 21264 " 6 operazioni per colpo di clock! a 600Mhz ha le prestazioni di un pentium4 a 2400mhz ;)

http://www.lithium.it/articolo.asp?code=34

IS_Fox_
04-06-2004, 20:25
Originariamente inviato da nakodnas
W i MIPS e gli storici ALPHA!

Guarda l'architettura di " ALPHA 21264 " 6 operazioni per colpo di clock! a 600Mhz ha le prestazioni di un pentium4 a 2400mhz ;)

http://www.lithium.it/articolo.asp?code=34


Scusa ma non credo sia prorpio cosi in quanto i pentium 4 sono muniti di un bus quad pumped in grado di inviare 4 dati per ogni ciclo di clock. quindi il rapporto che hai fatto tu non si trova.

;)

nakodnas
04-06-2004, 20:53
Originariamente inviato da IS_Fox_
Scusa ma non credo sia prorpio cosi in quanto i pentium 4 sono muniti di un bus quad pumped in grado di inviare 4 dati per ogni ciclo di clock. quindi il rapporto che hai fatto tu non si trova.

;)

bus? :D sai come funziona una cpu? i dati li riceve ma poi finiscono in cache a dormire nel frattempo che li elabora uno per volta! i pentium sono processori ad una sola via 1-Way
i pentium x86 non sono vettoriali

leggi qui papà Cray X1 come funge ;) : http://www.lithium.it/dream0016p1.asp
queste cose nei DSP sono già usate da anni

IS_Fox_
04-06-2004, 21:33
Originariamente inviato da nakodnas
bus? :D sai come funziona una cpu? i dati li riceve ma poi finiscono in cache a dormire nel frattempo che li elabora uno per volta! i pentium sono processori ad una sola via 1-Way
i pentium x86 non sono vettoriali

leggi qui papà Cray X1 come funge ;) : http://www.lithium.it/dream0016p1.asp
queste cose nei DSP sono già usate da anni

e allora i 4 dati per cicli di clock cosa rappresentano?

se mi spieghi per bene te ne sarei grato visto che mi interessa come argomento ;)

p.s. l'articolo è troppo lungo :sofico:

SlimSh@dy3Ghz
04-06-2004, 21:51
Originariamente inviato da smashing
Qualcuno mi sa dire un po' di storia su come questa pessima architettura abbia avuto così tanto successo?

ps: come vedete dalla sign la utilizzo anch'io anche se nel male minore (amd a livello di architettura interna è migliore di intel almeno secondo me) anche se il corso di architettura degli elaboratori alla mia università mi ha aperto gli occhi e sono MOLTO intenzionato a migrare almeno su ppc!


:D :D :D :D e sarebbe quella pessima architettura??ma ti sei visto quella merda di procio che ti ritrovi ?? Un Xp pssssss.......se avresti avuto un athlon 64 potevi parlare ma con quel cesso dove vuoi andare.....

ev8
04-06-2004, 22:00
Originariamente inviato da SlimSh@dy3Ghz
:D :D :D :D e sarebbe quella pessima architettura??ma ti sei visto quella merda di procio che ti ritrovi ?? Un Xp pssssss....... se avresti avuto
L'italiano è una lingua morta... :rolleyes:
un athlon 64 potevi parlare ma con quel cesso dove vuoi andare.....
Il tuo "ata 133" invece ti pone di diritto nel quarto millennio... :rolleyes:

SlimSh@dy3Ghz
04-06-2004, 22:08
Originariamente inviato da ev8
L'italiano è una lingua morta... :rolleyes:

Il tuo "ata 133" invece ti pone di diritto nel quarto millennio... :rolleyes:



Ei professore del cazzo vedi che io a differenza di molti di voi non stò sempre criticare , o meglio schifare altre case produttrici ....ma le rispetto tutte. Ma quando ci sono dei cretini che non capiscono nulla di computer e credono che un Amd Xp sia migliore di p4 allora mi saltono i nervi......e poi invece di stare a criticare il mio hd perchè tu in sign non hai la tua config ??'Ti vergoni per caso :D :D :D :D

checo
04-06-2004, 22:14
Originariamente inviato da SlimSh@dy3Ghz
Ei professore del cazzo vedi che io a differenza di molti di voi non stò sempre criticare , o meglio schifare altre case produttrici ....ma le rispetto tutte. Ma quando ci sono dei cretini che non capiscono nulla di computer e credono che un Amd Xp sia migliore di p4 allora mi saltono i nervi......e poi invece di stare a criticare il mio hd perchè tu in sign non hai la tua config ??'Ti vergoni per caso :D :D :D :D


l'architettura dell' athlon è indubbiamente migliore della netbrust(sai cos'è vero?) tant'è che intel ha deciso di abbandonarla per migrare verso l'architettura del pentium-m guardacaso derivato dal p3 e molti più simile all'athlon che al p4.

se non si sa le cose meglio stare zitti ;)

checo
04-06-2004, 22:15
Originariamente inviato da IS_Fox_
e allora i 4 dati per cicli di clock cosa rappresentano?

se mi spieghi per bene te ne sarei grato visto che mi interessa come argomento ;)

p.s. l'articolo è troppo lungo :sofico:

rapperesentano i dati trasferiti dal bus di sistema alla cpu, non centrano nulla con le operazioini eseguite per colpo di clock.

per inciso, pure gli athlon64 trasferiscono 4 bit per colpo di clock sul bus, gli xp 2

SlimSh@dy3Ghz
04-06-2004, 22:19
Originariamente inviato da checo
l'architettura dell' athlon è indubbiamente migliore della netbrust(sai cos'è vero?) tant'è che intel ha deciso di abbandonarla per migrare verso l'architettura del pentium-m guardacaso derivato dal p3 e molti più simile all'athlon che al p4.

se non si sa le cose meglio stare zitti ;)


Stai zitto tu Ignorante ;) ;)

checo
04-06-2004, 22:28
Originariamente inviato da SlimSh@dy3Ghz
Stai zitto tu Ignorante ;) ;)


dunque hai dato nell' ordine

professore del cazzo a ev8
cretino a nakodnas
ignorannte a me

pensi di continuare a insultare la gente che non la pensa come te(ovvero la pensa giusta) per molto?

SlimSh@dy3Ghz
04-06-2004, 22:34
Originariamente inviato da checo
dunque hai dato nell' ordine

professore del cazzo a ev8
cretino a nakodnas
ignorannte a me

pensi di continuare a insultare la gente che non la pensa come te(ovvero la pensa giusta) per molto?


Se voi vi vomportate bene con me io lo farò con voi......se ce rispetto da parte vostra ci sarà anche da parte mia.....

1- ho risposto professore del cazzo perchè mi ha insultato per come ho scritto ( cosa che faccio velocemente e non stò a pensare gli errori grammaticali che faccio)

2- Tu mi hai detto stai zitto e io ti ho risposto stai zitto tu Ignorante.......
basta a litigare perchè non è il caso. Con questo chiudo quì la inutile polemica.

Bistonbetularia
04-06-2004, 22:48
Originariamente inviato da SlimSh@dy3Ghz
se ce rispetto da parte vostra ci sarà anche da parte mia.....



Sei stato tu il primo a mancare di rispetto......le offese e gli insulti non ci stanno su un forum come questo
:rolleyes:

Athlon
04-06-2004, 22:56
Originariamente inviato da SlimSh@dy3Ghz
Se voi vi vomportate bene con me io lo farò con voi......se ce rispetto da parte vostra ci sarà anche da parte mia.....

1- ho risposto professore del cazzo perchè mi ha insultato per come ho scritto ( cosa che faccio velocemente e non stò a pensare gli errori grammaticali che faccio)

2- Tu mi hai detto stai zitto e io ti ho risposto stai zitto tu Ignorante.......
basta a litigare perchè non è il caso. Con questo chiudo quì la inutile polemica.



si e' proprio il caso di chiudere la polemica , le offese non sono tollerate.

User Banned

SlimSh@dy3Ghz
04-06-2004, 22:56
Originariamente inviato da Bistonbetularia
Sei stato tu il primo a mancare di rispetto......le offese e gli insulti non ci stanno su un forum come questo
:rolleyes:


Lo sò...... condivido pienamente :) ;) ;) ;). Se qualcuno si offeso li porgo le mie scuse ok??;)

DioBrando
05-06-2004, 00:13
peccato la discussione sia degenerata :rolleyes:

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 :muro: e l'AMD n è manco citato

^TiGeRShArK^
05-06-2004, 01:53
il bus non c'entra assolutamente niente con la capacità di un prcio di eseguire più istruzione x clock.
con istruzioni fp sugli athlon in determinate condizioni è possibile eseguire 3 istruzioni x clock.
con le sse, x esempio sfruttando registri a 128 bit è possibile eseguire 4 calcoli in una volta, ma cmq tenete conto ke in un clock nn vien assolutamente eseguita un istruzione. Con un colpo di clock si va avanti di uno stadio nella pipeline del procio, e quindi, a regime, con pipeline completamente piena e con DETERMINATE istruzioni è possibile eseguire UN istruzione x clock. Tenete conto ke le istruzioni ke hanno bisogno di dati caricati in memoria sono molto + lente di istruzioni ke eseguono operazioni con dati sui registri. x le prime sarà necessario attendere ke i dati arrivino, e x questo ci vuole un tempo pari alla latenza della memoria (le l1 e l2 hanno bassa latenza, ma già a caricare dalla memoria su un a64 ke è velocissimo grazie al controller integrato, si sprecano 90-100 colpi di clock)

cdimauro
05-06-2004, 06:02
Originariamente inviato da smashing
Qualcuno mi sa dire un po' di storia su come questa pessima architettura abbia avuto così tanto successo?
Perché ha offerto un buon rapporto prezzo/prestazioni. Nel frattempo, dall'8086 a oggi l'architettura ha subito delle evoluzioni notevoli.
ps: come vedete dalla sign la utilizzo anch'io anche se nel male minore (amd a livello di architettura interna è migliore di intel almeno secondo me) anche se il corso di architettura degli elaboratori alla mia università mi ha aperto gli occhi e sono MOLTO intenzionato a migrare almeno su ppc!
Alla fine quel che conta sono le prestazioni, non l'architettura in sé: ormai quasi nessuno programma in assembly, e sono i compilatori a fare la parte del leone. Se un'architettura dal punto di vista strettamente tecnico è "bella" per un esperto del settore, non vuol dire necessariamente che sarà la più performante.
La realtà, adesso, è che x86 offre delle prestazioni superiori a buona parte dei RISC in circolazione, PPC inclusi. E a costi decisamente minori.
Non è un caso che SUN abbia praticamente abbandonato SPARC, l'architettura progettata anni fa da uno dei più grandi esperti mondiali in materia: non le conviene più.

P.S. Al corso ti hanno parlato anche della famiglia Motorola 68000? Una delle architetture più belle (per me la più bella in assoluto ;)) che siano mai stato create e commercializzate... :D

smashing
05-06-2004, 09:02
Ringrazio tutti per le risposte! :D se a qualcuno interessa posso consigliare il libro di testo che abbiamo utilizzato (ora è in fase di ristampa, siamo alla terza edizione).
Al corso abbiamo studiato il mips con qualche accenno ad amd e intel del 68000 purtroppo no :cry:

questo è il libro:

Computer Organization and Design, 3rd Edition

Dr. David A. Patterson , University of California, Berkeley
Dr. John L. Hennessy , Stanford University

ISBN 1558606041 · Hardback · 700 Pages
Morgan Kaufmann · Forthcoming Title (August 2004)

Price: £ 39.99

In addition to thoroughly updating every aspect of the text to reflect the most current computing technology, the third edition

*Uses standard 32-bit MIPS 32 as the primary teaching ISA.
*Presents the assembler-to-HLL translations in both C and Java.
*Highlights the latest developments in architecture in Real Stuff sections:

+ Intel IA-32
+ Power PC 604
+ Google's PC cluster
+ Pentium P4
+ SPEC CPU2000 benchmark suite for processors
+ SPEC Web99 benchmark for web servers
+ EEMBC benchmark for embedded systems
+ AMD Opteron memory hierarchy
+ AMD vs. 1A-64

New material to support a Hardware Focus

+Using logic design conventions
+Designing with hardware description languages
+Advanced pipelining
+Designing with FPGAs
+HDL simulators and tutorials
+Xilinx CAD tools

New material to support a Software Focus

+How compilers Work
+How to optimize compilers
+How to implement object oriented languages
+MIPS simulator and tutorial
+History sections on programming languages, compilers, operating systems and databases

checo
05-06-2004, 11:45
fico sto libro, io a suo tempo studia il 68k invece

^TiGeRShArK^
05-06-2004, 12:04
io oltre al 68000 ho studiato anke l'arkitettura sparc facendo una specie di emulatore embrionale ke doveva emulare le istruzioni del 68000 sulla sparc, solo ke non avendo a disposizione alcuna makkina su cui farlo girare è rimasto solo in via teorica :cry:

^TiGeRShArK^
05-06-2004, 12:06
Dimenticavo, l'arkitettura + bella x me è ovviamente la sparc con la gestione dei registri a sliding window ke era qualcosa di spettacolare.
Anke la 68000 era una bella arkitettura, permetteva di usare istruzioni molto + comlesse della x86, soprattuto riguardo le operazioni da effettuare sulla memoria, ke potevano essere eseguite con una semplicità disarmante.

Thunderx
05-06-2004, 14:29
ma io avevo letto che Athlon xp esegue 9 operazioni per ciclo di clock e il p4 6. ma è vero.Dato che io sono interessato a questo argomento ed allo studio e alla progettazione di architetture, quale facoltà dovrei fare all'Universià?
Sacusate l'OT

ev8
05-06-2004, 16:00
Originariamente inviato da Thunderx
ma io avevo letto che Athlon xp esegue 9 operazioni per ciclo di clock e il p4 6. ma è vero.Dato che io sono interessato a questo argomento ed allo studio e alla progettazione di architetture, quale facoltà dovrei fare all'Universià?
Sacusate l'OT
Ingegneria Informatica, anche se, ti avviso, molto lavoro lo dovrai fare da solo, perchè i corsi ti forniranno solo le basi.

nonsidice
05-06-2004, 17:40
Alla mia uni (ud) mi hanno fatto studiare vita morte e miracoli del 68000 e derivati (68020, 68040 se non ricordo male ecc.) + assembler e laboratorio assembler (era il vecchio corso da 5 anni) era bellissimo !! fare listatoni e dire DIRETTAMENTE alla cpu che fare da soddisfazione, c'è il controllo totale.
del' x86 invece fatta solo teoria :(
ho ancora i manualozzi in english (in italiano mai tradotti).

cdimauro
06-06-2004, 08:06
move.w (a0, $12345678, [d0 * 4, $87654321]), ([a1, d1 * 8, $43218765], $56784321)

68020+ rulez! :D

DioBrando
06-06-2004, 15:28
Originariamente inviato da nonsidice
Alla mia uni (ud) mi hanno fatto studiare vita morte e miracoli del 68000 e derivati (68020, 68040 se non ricordo male ecc.) + assembler e laboratorio assembler (era il vecchio corso da 5 anni) era bellissimo !! fare listatoni e dire DIRETTAMENTE alla cpu che fare da soddisfazione, c'è il controllo totale.
del' x86 invece fatta solo teoria :(
ho ancora i manualozzi in english (in italiano mai tradotti).

eh al- l'assembler tu l'hai studiato....a TWM parti col Java :muro::muro::muro:

repne scasb
06-06-2004, 19:10

smashing
06-06-2004, 20:12
ah, se a qualcuno può interessare qui ci sono i lucidi del prof. : lucidi (http://www.dsi.unive.it/~arcb/)

cdimauro
07-06-2004, 05:56
x repne scasb: hai ragione per l'indirizzamento. L'indirezione deve comprendere sempre il registro indirizzi, se presente.

Quanto agli EA, l'allineamento alla word (16 bit) vale solamente per i 68000, mentre dal 68020 in poi le CPU sono in grado di leggere e scrivere indifferente su indirizzi qualunque, anche completamente disallineati.

Una eccezione: l'istruzione move16 del 68040, che trasferisce 16 byte (usando il burst mode: 4 longword "a colpo") alla volta e pretende che i due EA si trovini a multipli di 16 byte.

cdimauro
07-06-2004, 06:09
Grazie per i lucidi del corso... :)

giorget1
07-06-2004, 07:47
arghhhhhh l'assembly.... da noi ci bocciavano per un nulla, ponete caso di aver premuto male invio e aver messo una ù dopo un load word ad esempio... 3 punticini solo questo errore, x 10 volte che ciclava il programma = ci vediamo alla prossima sessione, direi l'esame in cui ho sofferto di piu' :(

repne scasb
07-06-2004, 09:01

jappilas
07-06-2004, 13:15
Originariamente inviato da ^TiGeRShArK^
il bus non c'entra assolutamente niente con la capacità di un prcio di eseguire più istruzione x clock.
con istruzioni fp sugli athlon in determinate condizioni è possibile eseguire 3 istruzioni x clock.
[....]


in più mi pare che nell' athlon standard le 3 ALU intere vengano sfruttate in modo diverso a seconda che l' istruzione fosse semplice o complessa (nel qual caso ne verrebbero aggregate due per eseguire una singola operazione complessa )

PS: la mia architettura preferita attualmente è la PA 2.0 ... con la modalità full conditional execution (addio branch misprediction ... :D) ...
e il context switch in singolo ciclo di clock...
:sbav: :cool:

cdimauro
07-06-2004, 22:47
x repne scasb. Non è così: il 68020 ha una logica di controllo del bus completamente diversa da quella dei suoi predecessori, e che rimuove in toto i limiti citati.

In particolare, la lettura/scrittura di dati viene effettuata secondo i seguenti "passi":

1) Il processore comunica alla "periferica" l'indirizzo (A2-A31), la dimensione (SIZ0-SIZ1) e l'offset (A0-A1) del dato che si vuole leggere o scrivere
2) La "periferica" comunica alla CPU la dimensione dei dati che può accettare (DSACK0-DSACK1)
3) Durante il trasferimento dei dati, il multiplexer (CPU)/periferica (logica interna) associato al bus dati riceve o invia i dati (o parte di essi), usando opportune sue parti.

SIZ0/SIZ1 permettono di specificare richieste di 1, 2, 3 o 4 byte; DSACK0/DSACK1 portano a conoscenza la CPU che la periferica è in grado di poter soddisfare richieste di 8, 16 o 32 bit per volta, cosicché il multiplexer della CPU si potrà "preparare" per ricevere/spedire i dati nelle parti di bus necessarie (utilizzando A0/A1 a tal scopo).

Da ciò risulta evidente che questo meccanismo prescidende completamente dai punti 1), 2) e 3) da te citati, in quanto è la logica di controllo del bus che si occupa di effettuare quest'operazioni. In particolare, se un sistema è stato progettato per non poter accettare richieste di lettura/scrittura disallineate, lo comunicherà alla CPU utilizzando le linee DSACK0/DSACK1 (ad esempio: la lettura di una longword ad un indirizzo con offset +3 potrebbe presentare una disponibilità di porta a 8 bit, poi una di 16 bit, e poi una ancora di 8 bit).

L'MMU o la PMMU, poi, non possono assolutamente entrare in gioco in questo contesto. Difatti, se dovessero avere problemi nella gestione di letture/scritture di word o longword a indirizzi dispari, parimenti ne dovrebbero avere anche in quelle di longword a indirizzi con offset pari a 2 (A0 a 0, A1 a 1), che però sono perfettamente legittime tanto nel 68000 quanto nel 68020.
In buona sostanza, MMU e PPMU si occupano esclusivamente della conversione degli indirizzi virtuali in indirizzi fisici: difatti l'offset viene estrapolato dall'indirizzo virtuale, e "ricopiato" in quello fisico.

Per concludere, l'unico limite che rimane nei 68020+, e che risulta evidenziato nella documentazione tecnica di Motorola e non, è quello del PC che non può trovarsi ad indirizzi dispari. Limite che sarebbe stato possibile rimuovere tranquillamente proprio per il discorso di cui sopra (alla logica di controllo del bus non importa se stia leggendo l'opcode di un'istruzione o un dato qualunque),ma che è stato mantenuto per semplificare la pipeline della CPU...

x jappilas: PA 2.0 cos'è? PA-RISC di HP? La modalità full conditional execution riguarda la capacità di eseguire entrambi i "rami" nel caso di istruzioni condizionali? Comunque al context switch in 1 ciclo di clock non ci credo: magari è "mascherato" in qualche modo, ma il tempo per salvare i registri e caricare quelli nuovi c'è.

cdimauro
08-06-2004, 06:14
Dimenticavo: a motivo di quanto scritto, l'istruzione MOVEP è divenuta praticamente obsoleta. Difatti nel 68060 non è stata neppure implementata, e nel caso di utilizzo di software "vecchio", i s.o. sono tenuti a intercettare l'eccezione di istruzione illegale, ed emularne il funzionamento. ;)

P.S. Il 68EC020 montato nel mio Amiga 1200 aveva 24 linee d'indirizzamento... :)

repne scasb
08-06-2004, 10:45

jappilas
08-06-2004, 14:12
Originariamente inviato da cdimauro
x jappilas: PA 2.0 cos'è? PA-RISC di HP? La modalità full conditional execution riguarda la capacità di eseguire entrambi i "rami" nel caso di istruzioni condizionali? Comunque al context switch in 1 ciclo di clock non ci credo: magari è "mascherato" in qualche modo, ma il tempo per salvare i registri e caricare quelli nuovi c'è.

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" :D ;)

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

http://www.cs.umass.edu/~weems/CmpSci635A/635lecture4.html

sull' architettura 680x0 : :ave: :ave:

AnonimoVeneziano
08-06-2004, 18:37
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
08-06-2004, 18:42
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" :sofico: per il target del PC originario...
:muro: :muro:

Pappy19
08-06-2004, 18:50
Originariamente inviato da DioBrando
peccato la discussione sia degenerata :rolleyes:

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 :muro: e l'AMD n è manco citato


tanenbaum?

ev8
08-06-2004, 22:46
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" :D ;)

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

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/tech_TechDocumentDetailPage_IDX/1,1701,959!12!244,00.html
http://www.cs.umass.edu/~weems/CmpSci635A/635lecture4.html

sull' architettura 680x0 : :ave: :ave:

cdimauro
08-06-2004, 23:05
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" :D ;)
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 ... :cool:
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/tech_TechDocumentDetailPage_IDX/1,1701,959!12!244,00.html
http://www.cs.umass.edu/~weems/CmpSci635A/635lecture4.html

sull' architettura 680x0 : :ave: :ave:
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
08-06-2004, 23:30
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. :p
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
08-06-2004, 23:37
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
09-06-2004, 00:32
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
09-06-2004, 06:51
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
09-06-2004, 08:02

repne scasb
09-06-2004, 09:23

cdimauro
10-06-2004, 07:23
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... :muro:

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