Newsgroup: it.comp.hardware.cpu
Titolo: SPERIAMO che il mercato...

... non si lasci scappare la grande opportunità di cambiare modo di
concepire un processore...
su www.lithium è uscita l'ultima parte di un articolo sui processori
motorola "vecchio stampo", in cui viene più volta ribadito come x86 sia una
vera e propria palla al piede di tutto il mondo dei personal computer!
IA-64 potrebbe essere veramente un'occasione per rivoluzionare il mondo dei
PC, ma purtroppo anche questa volta sarà il mercato a decidere e non la
validità tecnica del progetto... certo bisognerebbe buttare tutti i vecchi
programmi e si dovrebbe "ricompilare" tutto il software, ma ho la sensazione
che il prezzo da pagare per tutti gli utilizzatori dei PC sarebbe MOLTO più
alto se non si cogliesse l'occasione di "cestinare x86"...
P.S.: Non venitemi a confrontare x86-64 con l'architettura EPIC perchè
sareste veramente patetici :-))
CIAO NTT81

 vera e propria palla al piede di tutto il mondo dei personal computer!
Io lo dico da una vita... Un processore che nasce con indirizzamento di memoria
segmentato(!) mentre già esistevano processori a 32 bit (eh già... e col PC i 
32 bit sono arrivati solo con windows 95) e che se lo trascina per generazioni 
successive è un vero PACCO!!!
Purtroppo il sodalizio intel-microsoft è duro a morire...
-- 
SCCS, the source motel!  Programs check in and never check out!" - Ken Thompson
News 2000 [v 2.06] - 
http://www.akapulce.net/socket2000

 32 bit sono arrivati solo con windows 95)
Ti ricordi del mitico OS/2?
Ricordo ancora come la mitica Warp 3 multitaskava a meraviglia sul 486DX33
(avevo speso una follia per quella CPU... e per gli 8MB di RAM...) con 8MB
di RAM, mentre gli altri erano relegati a quella schifezza di Win 3.1...
Saprai anche che ci sono state tante versioni di WinNT (ricordo la 3.5, il
Godzilla dei istemi operativi, tanto era pesante... girò decentemente solo
quando di diffusero i DX2 66 con addirittura 16MB di RAM), prima di Win95.
Senza contare le varie versioni di Unix.
Dire poi che i 32bit sono arrivati con Win95... beh... vabbè...
Se intendevi dire che i 32bit sono arrivati per il grande pubblico, allora
si può dire che siano veramente arrivati solo ora con WinXP Home...
Comunque, è tutto molto triste.

 si puň dire che siano veramente arrivati solo ora con WinXP Home...
Diciamo che i 32 bit sono stati ampiamente pubblicizzati come 'rivoluzionari' 
con windows 95.
-- 
IBM: Incredibly Big Manufacturer


 Senza contare le varie versioni di Unix.
quando e' uscito OS/2, Unix aveva gia' nel suo DNA XMotif, esecuzione
distribuita, esecuzione remota, supporto multiproc. e tante cosette che
sembrano novità ma non lo sono... lasciamo stare unix che non ha colpa ed e'
sempre stato due passi avanti a tutti!

 vera e propria palla al piede di tutto il mondo dei personal computer!
E' buffo che una persona, quando sostiene una tesi e vuole presentarla a
tutti i costi come evidente, spesso si lascia prendere la mano ed esagera,
finendo per presentare dati contraffatti anche quando la tesi da lui
sostenuta sia inequivocabilmente corretta.
Mi spiego meglio: sono andato a leggere l'articolo di Lithium da te
indicato, e ho guardato i due listati, in assembly x86 e motorola 68000.
Tesi: i processori motorola 68k sono superiori agli x86. Prova (una delle
tante, a dire il vero, e nemmeno tanto rappresentativa): in assembly 68000
ho una maggiore compattezza che in assembly 8086. E va bene, ammettiamo pure
che sia una prova valida (e di per sé non lo è, altrimenti tutti i RISC
sarebbero peggiori dei vari CISC: nel caso specifico può essere vera ma va
sostenuta con altre argomentazioni). Bene, pur di mostrare che la famiglia
68k ha una compattezza del codice maggiore che l'x86, si è fatto il
confronto tra un'architettura a 16 bit e una a 32 bit, confronto /unfair/
ovviamente, accettabile solo perché i due processori sono esistiti nello
stesso periodo, ma le cui conclusioni non possono essere estese a due
famiglie di processori. Se l'8086 è a 16 bit, è ovvio che per addizionare
due numeri a 32 ha bisogno del doppio dei passaggi di un processore a 32
bit, o no? In assembly 386 sarebbe tutto diverso, chiaramente. Vediamo il
codice di Lithium:
START:     mov  ax,[si]
           add  ax,[di]
           mov  [si],ax
           mov  ax,[si + 2]
           adc  ax,[di + 2]
           mov  [si + 2],ax
           inc  si,4
           inc  di,4
           loop START
In assembly 386 sarebbe:
START:     mov  eax,[esi]
           add  eax,[edi]
           mov  [esi],eax
           inc  esi,4
           inc  edi,4
           loop START
Cioè da 9 a 6 istruzioni, contro le 2 del 68000. Finisce qui? Non proprio,
visto che il codice è stato scritto in modo non ottimizzato (non so se
scioccamente o appositamente). Potevamo risparmiare ancora un'altra
istruzione:
START:     mov  eax,[edi]
           add  [esi],eax
           inc  esi,4
           inc  edi,4
           loop START
oppure, se proprio volessi essere cattivo:
START:     mul  ebx, ecx, 4
           mov  eax,[ebx+edi]
           add  [ebx+esi],eax
           loop START
(quest'ultimo esempio scorre l'array dalla fine all'inizio).
Tutto questo per mostrare che non è tutto oro quello che luccica.
Saluti.
--
//  Xelloss dal portatile || in real life: Wilmer Ricciotti  \\
|  
wirix...@libero.it
 (elimina il demone per rispondermi)  |
|    ICQ: 3233084        IRC: Xelloss@AzzurraNet, @ChatNow    |
| Hardware Information & Technology: 
http://hit.edengames.net
 |
\_______Like the Phoenix I rise from the ashes of life________/

 Saluti.
La tua spiegazione è molto tecnica e valida, ma tuttavia ci sono almeno due
ovvi motivi che dimostrano come le istruzioni x86 siano una vera e propria
palla al piede di tutto il mondo dei PC.
1- I processori di AMD ed Intel codificano il codice x86 in istruzioni
proprietarie "segrete", ovvero non pubblicche, diverse fra loro... e sono
queste istruzioni ad essere elaborate nei moderni processori...
2- le istruzioni x86 non sono state pensate per essere eseguite in
parallelo, ma solo in modo sequenziale, ma nei processori moderni esse
vengono eseguite in parallelo tramite complesse unità del processore che
hanno il compito di individuare quali istruzioni possono essere eseguite
contemporaneamente... queste unità oltre ad occupare molto spazio sul die
del processore, pur essendo molto complesse e difficilissime da progettare,
sbagliano a volte nel loro compito a causa della natura del codice x86 che
appunto non è nato per eseguire più istruzioni in parallelo...
Bastano questi 2 motivi, oltre al fatto che negli ultimi anni Intel ed AMD
hanno "aggiunto" nuove istruzioni oltre a quelle standard x86 ( MMX, SSE,
SSE2, 3Dnow! ormai morte ), per capire come ormai è ora di cambiare
VERAMENTE il modo di concepire il processore di un moderno PC... Più si
ritarderà questo avvenimento, più il mondo dei computer sarà svantaggiato...
CIAO NTT81

 appunto non è nato per eseguire più istruzioni in parallelo...
Su questa base, dovresti scartare tutti i processori tranne i VLIW, non solo
gli x86. E finora i VLIW non hanno dimostrato prestazioni tali da
giustificarli. Io sono convinto che l'esecuzione esplicitamente parallela (e
quindi le ISA VLIW) nei processori general purpose sia un male; come ho
scritto nel thread "di frequenze, approcci e ipc" può darsi però che i VLIW
si rivelino un male necessario. Ecco, questo male si rivelerà necessario,
IMHO, non prima di altri 10-15 anni.


sareste veramente patetici :-))
'hammer e' per il momento lo sviluppo ultimo dell'architettura x86 -
ha come punti di forza la compatibilita' x86 (il problema e' che
continuiamo a considerarlo un punto di forza... :-\ ), il modello di
memoria incredibilmente efficiente in multiprocessing ed il
(relativamente al suo segmento di mercato) basso costo produttivo -
detto questo rimane un x86 con tutto quello che ne consegue.
se invece di un'isa x86 avessero usato un'isa Alpha (tanto per dire)
sarebbe un vero mostro (oltre all'efficienza di base notevolmente
superiore, a pari mos avrebbero potuto infilare _due_ processori nel
die oppure raddoppiare la cache oppure...), ma amd puo' permettersi di
giocare soltanto con x86 purtroppo - questo rimane il suo limite.
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Il segreto per essere considerato un creativo sta nel non fare
    mai riconoscere le proprie fonti [A. Einstein]

Purtroppo il sodalizio intel-microsoft è duro a morire...
non per molto direi - in campo *nix (saltano fuori anche le prime
distribuzioni linux con questa soluzione) si tende sempre piu' verso
soluzioni stile bsd, in cui s.o. e programmi vengono compilati al volo
durante l'installazione ed ultraottimizzati per la macchina,
rendendole sempre piu' indipendenti dall'hardware.
anche microsoft con .net si muove verso soluzioni
hardware-indipendent...
il vantaggio di soluzioni x86 rimane nell'immenso volume prodotto, che
abbatte i costi notevolmente, ma la zavorra che si porta dietro
elimina gran parte di questo vantaggio, sempre piu' ad ogni
generazione...


sareste veramente patetici :-))
Nessuno vuole confrontare EPIC con x86-64 a livello di architettura.
Vogliamo solo capire qual è la soluzione più conveniente a breve e a
lungo termine. A lungo termine sembra che sia migliore IA64, a breve
termine quasi certamente x86-64, visto che non devi necessariamente
ricostruirti tutto il parco software per poterla usare, e che comunque
la soluzione AMD tende ad eliminare alcuni degli svantaggi di x86 (es:
il numero ridotto di registri GPR).
Saluti,
Mav
-- 
<==--------------=[::. Mav .::]=---------------==>
 
www9.brinkster.com/mav3rik
 | 
mav...@yahoo.com
  Mav @ 
irc.azzurra.org
      |     ICQ# 22579106
<==--------------------------------------------==>

 PC
rotfl

 (quest'ultimo esempio scorre l'array dalla fine all'inizio).
si, ma e' lento .... 
lascia che sia io cattivo: se volessimo copiare un blocco di memoria ?
rep movsd
punto
un'UNICA istruzione (e ti risparmio le 10 righe di codice 68k altamente 
non ottimizzato, col successivo commento "guardate che merda il 68k 
che ci mette 10 istruzioni!"...).
cmq complessivamente l'articolo in questione mi pare un po' 'na 
monnezza... ad esempio non descrive la gestione folle (e lenta) della 
memoria virtuale negli ultimi 68k. e non parla di quel "piccolo" 
problemino di indirizzamento che in certi casi porta a buttare almeno un 
byte per ogni elemento di array (array di struct di dimensione dispari)
"e anche se cio' puo' significare un numero maggiore di cicli per 
eseguirla, cio' ci permette, rispetto al caso x86 o ai RISC, di 
risparmiare nell'esecuzione delle dispendiose fasi di fetch delle 
istruzioni e di decodifica"
cazzata elevata al cubo: la decodifica per i RISC e' tutto tranne che 
dispendiosa (il fetch forse, ma se pialliamo le aree usate per 
decodificare 15 modi di indirizzamento desueti, ci mettiamo k e k di 
cache...).
"Siamo infatti ancora agli albori dell'informatica quando viene presentato 
il 68000 ed i processori di allora non applicavano quasi per niente il 
concetto di pipeline"
ormai non ho piu' aggettivi (albori dell'informatica ?) ... 
qualcuno gli parli dell'ibm 360 del '67 ...

 qualcuno gli parli dell'ibm 360 del '67 ...
Devo dire che queste due perle mi erano passate inosservate :-)).
Grazie mille ;-)


 sareste veramente patetici :-))
Io veramente il confronto lo farei con l'ARM (riguardo cambi radicali
a livello di architettura) oppure con i Power e gli Alpha (per quel che
riguarda le prestazioni senza compromessi).
L. Micheletto

sareste veramente patetici :-))
Gli x86 hanno seppellito pure i processori Alpha ed è tutto dire...
forse IA-64 avrà miglior fortuna, ma aspetterei a dirlo.
E' il peggiore a vincere, come dice Xellos su edengames, piaccia o no
ma è così.
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
Tessera #008 BAG, #000 DPPSJ, #013 BAT, #012 TFC
"Il Grande Fratello? Non lo farei mai vedere ai miei figli."
(Giovanni Modina, direttore di Canale 5)

quindi le ISA VLIW) nei processori general purpose sia un male; 
Ma per quale motivo un VLIW non rende  bene in applicazione general
pourpose? In definitiva, se si riesce a eseguire + istruzioni in
parallelo si possono tenere le unità di calcolo sempre attive... dov'è
il male? :-)


 il male? :-)
No, io considero i VLIW un male perché il loro assembly è umanamente
ingestibile :-).
Il motivo per cui un VLIW non rende bene... mah teoricamente un VLIW ben
fatto dovrebbe rendere bene eccome, ma finora non ne ho visto nessuno...


Gli x86 hanno seppellito pure i processori Alpha ed è tutto dire...
il lato oscuro della forza e' potente... :-)
gli x86 hanno tutta l'inerzia del mercato dietro di loro a sostenerli,
pero' l'onda si sta attenuando visto che il soft legacy diventa di
volta in volta meno rilevante (cosa voluta dagli stessi che portano
avanti il trend x86 visto che introducono nuove funzioni hard/soft che
causano sempre piu' rapidamente incompatibilita' con il passato, vedi
microsoft ed intel).


il male? :-)
l'idea di base attorno a cui ruotano le migliori implementazioni di
vliw e' l'essere altamente specializzato.
ovvero tu hai un compito da eseguire, scrivi il programma di base e ci
costruisci attorno processore e programma definitivo.
i risultati sono semplicemente fantastici, in questo modo e' possibile
creare processori minuscoli (in termini di mos) con rese (per quello
specifico compito) perfette.
un'approccio decisamente diverso ma potenzialmente molto interessante
e' quello di transmeta, con una base vliw ed un superstrato
code-morphing capace di emulare praticamente qualsiasi isa... le
attuali implementazioni non sono concorrenziali (piu' che altro per
una questione di fondi...) ma il potenziale c'e'.
epic... sono partiti bene (molto bene, i primi annunci di ia64 erano
fantastici) ma poi si sono totalmente dimenticati di cosa significhi
vliw ed hanno continuato ad appiccicargli roba inutile.


 fatto dovrebbe rendere bene eccome, ma finora non ne ho visto nessuno...
Piu che altro, con i VLIW si elimina parecchio HW "di supporto"
che non interviene direttamente nell'esecuzione delle istruzioni
e si hanno a disposizione molte piu unita di esecuzione a parita
di area disponibile, ma questo "aumenta il carico" su tutte le
altre unita (registri, decoder istruzioni, ecc. ecc.).
Inoltre se si ha codice "seriale", per vettorizzarlo si produce
codice che occupa molta piu memoria (e questo "aumenta il carico"
sulle cache).
In altre parole i VLIW presentano notevoli vantaggi sotto certi aspetti
ma la cosa ha un prezzo; mentre i "costi" dell'architettura RISC
sono ben noti, con i VLIW ed i loro derivati (es: IA64) non si e' ancora
giunti ad utilizzarli in cosi tante applicazioni e a farne un uso
cosi diffuso da capire bene "le cose da non fare".
Giusto per ricordarlo, le prime cpu SPARC "RISC duro e puro"
*non avevano* le istruzioni di moltiplicazione (avevano solo una
istruzione "passo di moltiplicazione") perche (ufficialmente) i
progettisti pensavano che l'istruzione di moltiplicazione
fosse cosi poco frequente che bastasse emularla (ed ufficiosamente
non c'era abbastanza spazio sul chip, suppongo).
Ma con la versione successiva sono corsi subito ai ripari dopo le
figuracce rimediate in alcuni bench.
Con i VLIW la progettazione di una "buona cpu"
e' ancora piu complessa perche oltre ad aggiungere una dimensione
in piu (le unita di esecuzione da gestire direttamente)
si deve dipendere molto di piu dalla bonta dei compilatori
utilizzati.
L. Micheletto

 forse IA-64 avrà miglior fortuna, ma aspetterei a dirlo.
Piu che altro, gli Alpha sono stati uccisi dai contafagioli
della Compaq.
Se Intel non avesse gia buttato un fottio di soldi su IA64
avrebbe fatto una affarone a fare degli Alpha la *sua* nuova
architettura a 64bit (piu o meno come ha fatto con gli
StrongArm che aveva acquisito da DEC e che sono divvenuti
una bella fonte di soddisfazioni).
L. Micheletto

ingestibile :-).
Vabbeh, questo è un altro discorso ^___^;;;
Ma in fondo oggi le parti di codice scritte in assembly sono veramente
poche...


 poche...
Ma qualcuno i compilatori dovrà pur scriverli...


 il male? :-)
il male e' che spesso non ti servono piu' operazioni in parallelo 
(generalmente a causa delle dipendenze di dati/di controllo). 
ad esempio l'algoritmo banale per il calcolo del fattoriale e' 
intrinsecamente  poco parallelo...
per "sfruttare" tutte le risorse il compilatore si mastica un po'  il 
codice producendo (e qui con la metafora alimentare mi fermo...) del 
codice con discreti overhead. 
il punto e' che oggi come oggi non si sa ancora bene come gestire la 
faccenda, anche per il fatto che tutto dipende moltissimo dal programma 
in fase di compilazione e dai dati su cui operera'.
 

 pourpose? In definitiva, se si riesce a eseguire + istruzioni in
Ma chi ha mai detto che non rende bene?
Nel caso _peggiore_ si comporta come un RISC.
bye,
-- 
piergiorgio

 fatto dovrebbe rendere bene eccome, ma finora non ne ho visto nessuno...
Uhm, mi verrebe da chiederti quanti VLIW hai visto...
bye,
-- 
piergiorgio

 in fase di compilazione e dai dati su cui operera'.
No, lo stesso problema e` dato dall'ottimizzazione
per le CPU superpipeline/superscalar, non vi e`
alcun problema in fase di ottimizzazione.
La risposta corretta e` stata data da Lorenzo.
bye,
-- 
piergiorgio

 Ma qualcuno i compilatori dovrà pur scriverli...
E dov'e` il problema?
Non sono mica scritti al 100% a manina...
bye,
-- 
piergiorgio

 vliw ed hanno continuato ad appiccicargli roba inutile.
Infatti...
bye,
-- 
piergiorgio

 maggiore di uno...
Il problema e` che l'esecuzione condizionata
comunque deve essere valutata, cioe` l'istruzione
deve essere presente nel codice ed "eseguita" (si
fa per dire), cioe`:
1 gtr a > b -> r2
2 not r2 -> r3
r2 add a, 1
r3 add b, 1
r2 mul a, 10
r3 mul b, 10
etc.
Occupa comunque un numero doppio di istruzioni da
eseguire, quindi se l'overhead del jump e` minore,
conviene usare quello.
Il che dipende anche dal pipeline, ovviamente...
bye,
-- 
piergiorgio

 similari).
Si e no. Dato che _tutti_ i giochi, che sono circa
il 50%~60% del SW disponibile, sono CPU intensive e
trarrebbero vantaggio da un VLIW game oriented.
Applicazioni come excel, matlab et similia anche.
L'unica cosa che non trae vantaggio e` il codice
di controllo, che pero` tipicamente, non necessita
di prestazioni elevate.
bye,
-- 
piergiorgio

 assembler un buon RISC che un qualsiasi CISC.
un vliw non e' troppo piu' complesso di un risc da programmare in 
assembler... anzi, rispetto ad un superscalare puo' essere addirittura 
piu' semplice, dato che le istruzioni le accorpi tu e sei sicuro che 
verranno eseguite in parallelo. 
ad esempio, negli x86 solitamente solo una delle due alu puo' eseguire 
istruzioni su dati 8 bit. se non fai attenzione puoi trovarti l'unita' a 8 
bit occupata da un'operazione del blocco precedente e ti saltano tutti i 
calcoli che hai fatto...
e poi in un risc duro e puro devi gestire le dipendenze inserendo tra le 
due istruzioni il numero esatto di nop, dipendente dalla lunghezza della 
pipeline.
es: ipotetico risc con pipeline a 4 stadi: fetch, decode/lettura registri, 
esecuzione/load da memoria,  scrittura nei registri/memoria 
r10 = add r1,r4
r11 = sub r10, r3
supponendo al tempo 0 il fetch della prima istruzione, r10 sara' 
calcolato e disponibile solo a t=4. 
la seconda istruzione viene caricata a t=1, ed i registri (tra cui 
r10) vengono letti a t=2: se non metti due nop tra le istruzioni, la 
seconda usera' il valore "vecchio" di r10.
la stessa cosa si ha con i salti, con la "trascurabile" differenza che in 
questo caso vengono _eseguite_ istruzioni poste dopo il salto.

 trarrebbero vantaggio da un VLIW game oriented.
in molti giochi una parte assolutamente non trascurabile e' l'IA dei bot ...
ad esempio, un gioco di corse automobilistiche con 22 partecipanti: ci sono 21 
bot che devono prendere decisioni, oltre al fatto che devono essere prese 
decisioni di altro tipo riguardo alla condotta generale della gara 
(es: riconoscere gli incidenti e far sventolare le bandiere gialle e/o 
safety car ...). poi c'e' l'interazione con la pista che deve essere 
considerata. 
senza contare che ogni macchina viene calcolata separatamente ed ha dati 
diversi, quindi la parte di calcolo intensivo e' spezzettata e non 
compatta. c'e' un overhead non trascurabile, anche peggio dei cambi di 
processo nei sistemi operativi.
e poi il fatto che quake3 risenta molto della banda di memoria disponibile, 
fa pensare che (almeno per i giochi con quel motore) non proprio tutto il 
tempo venga passato a fare calcoli ... 

 tempo venga passato a fare calcoli ...
Beh, hanno grossi problemi di rendering, senza dubbio.
Qui entriamo in un area delicata, pero`, cioe` l'interazione
con la scheda video e relativi.
bye,
-- 
  Piergiorgio Sartor

invece che in assembly...
nel caso dei Crusoe se vuoi proprio andarci pesante puoi direttamente
programmare il layer di code-morphing nelle flash interne ed infilarci
il tuo programma - un po' come andare a lavorare direttamente sul
traduttore x86-risc86... 
diciamo pero' che e' "sconsigliato"... ^___^;;


CPU e non mi piace che ciò accada di default :-)
Mannò, uno può sempre imparare quel semplicissimo assembly e fare
tutto a manina, anche la prossima versione di Win-IA64 >:D


 diciamo pero' che e' "sconsigliato"... ^___^;;
Sconsigliato, ma... estremamente interessante.. :-)


 Sconsigliato, ma... estremamente interessante.. :-)
Eh, ma qui ricadiamo in un vecchio discorso:
non sarebbe "interessante" poter aver accesso
alla programmazione RISC86 dei K6 (e K7, forse)?
:-)
bye,
-- 
piergiorgio

 alla programmazione RISC86 dei K6 (e K7, forse)?
Discorso vecchio e risposta vecchia:
SI'.
Saluti :-)
