Newsgroup: it.comp.hardware.cpu
Titolo: Sotto Stress!!!

Qual'è la cpu che mettendola sottopressione, tipo 24 ore di mp3 costanti,
risulta più affidabile....spiegandosi a scapito delle performance ad ogni
costo, qual'è cpu che non da rogne. Parto dall'esperienza che avevo un k6
400 e di tanto in tanto impallava, poi sono passato ad un celeron 550@850 e
lo posso forzare anche mettendoli un phon caldo e funziona sempre come un
orologio svizzero.
AMD o INTEL come affidabilità?

Premetto che non voglio sentire discorsi, tipo che se ci metti una turbina
d'aereo per raffredarlo o dentro un freezer non ha problemi, spendere 50k
per una ventola o di + significa già che il progetto della cpu è carente!!

 AMD o INTEL come affidabilità?
Ne` uno, ne` l'altro, what about PowerPC?
bye,
-- 
  Piergiorgio Sartor


intel

 per una ventola o di + significa già che il progetto della cpu è carente!!
Su quali basi puoi giungere a un'affermazione come questa? "Scalda, quindi
il progetto è carente"... equivale a dire che tutte le CPU x86 dai 486 a
oggi hanno avuto un progetto carente. Si va in questa direzione: le CPU, per
produrre performance sempre più "estreme", devono sviluppare tanto calore.
Un buon progetto può tenere il calore dissipato entro certi limiti, ma in
linea di massima, all'aumentare delle prestazioni deve aumentare il calore
dissipato. E ti dirò di più: il calore dissipato aumenta anche all'aumentare
della scalabilità in prestazioni; con questa frase, intendo che un P4, che
può scalare decentemente in prestazioni fino grossomodo al 2004, a parità di
prestazioni scalda più di un P3 (confronta, ad esempio, un P3 1 GHz con un
P4 1.3/1.4 GHz, che va più o meno veloce uguale)!!!
Senza tecnologie radicalmente diverse dalle attuali, non si può fare a meno
di potenti dissipatori.
Saluti. Uno Xelloss polemico.
--
    \\//                      Wilmer Ricciotti (da Bologna)
    //\\ e  l  l  o  s  s     
wirix...@libero.it
                              (elimina il DEMONE per rispondermi)
/---------------------------+----------------------------------------\
| ICQ: 3233084              | No one was born to be servant or slave |
| IRC: Xelloss @ AzzurraNet | Can you tell me the color of the rain? |
\---------------------------+----------------------------------------/

 risulta più affidabile....
In generale vanno bene tutte, anche se le CPU per server come gli Xeon o gli
Athlon MP sono testati per il massimo dell'affidabilità.
Anche un VIA C3 forse ha una stabilità superiore alla media, ma le
prestazioni sono da incubo.
Saluti.


 intel
Io non sono troppo d'accordo, direi che come affidabilità si equivalgono (a
patto di installazione corretta, naturalmente). Notare che non si è parlato
di stabilità dei chipset.
Inoltre, va da sé che uno scenario molto più probabile è l'instabilità del
software. Ovvero: andare a sottilizzare sulle minime differenze di stabilità
che possono esserci tra diverse CPU (ammesso che ci siano) e poi, magari,
utilizzare come sistema operativo come Win9x/ME è un'idiozia.


...


Notevole, devo dire, il buon senso celato dietro a quest'affermzione.....
Ciao
Andrea

 oggi hanno avuto un progetto carente. Si va in questa direzione: le CPU, per
Ma questo e` vero!
Non mi dirai che gli x86 sono un "buon" progetto, vero?
bye,
-- 
piergiorgio

Ho letto le Vs. risposte, riprendo il concetto intel-chipset ed Amd-chipset,
quale tra i  2 sistemi portati allo stremo, sono piů sensibili alla
variazione della temperatura....quale delle 2 cpu ha portato il "parametro
tolleranze" ad una soglia minima....se overclock non puo significare
parametri tolleranza alti..?

 Non mi dirai che gli x86 sono un "buon" progetto, vero?
L'ISA x86, ma soprattutto l'x87, fa cagare. Ma le attuali architetture x86
sono progetti dal buono all'ottimo...
E in particolare, spremere certe prestazioni da un'ISA del genere richiede
progetti complessi e ingenti investimenti.
Saluti.



{cut}
e meno male!!! minghia! :-O
^___°
--
Cain
- - -
"Imagination is more important than knowledge."
A.Einstein

orologio svizzero.
si vede che il tuo k6 aveva un dissipatore sottodimensionato e montato
su un case male areato.
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

 progetti complessi e ingenti investimenti.
Complesso e` diverso da buono che e` diverso da costoso, potrei
dire, anzi, che sono in contrapposizione, per qualche verso.
bye,
-- 
  Piergiorgio Sartor

 su un case male areato.
Oppure la scheda madre aveva qualche problema nell' i/o col processore o
nella cache. Ad esempio, il mio pc si impallava a random, soprattutto
usando BeOS o Linux, poi ho provato a tenere il bus a 95mhz invece che a
100, e tutto funziona perfettamente, anche overcloccando il processore.
Non e' un problema di ram, perche' anche tenendola a 66mhz il problema
persiste.
-- 
"Windows 95 is a 32-bit shell for a 16-bit extension to an 8-bit
operating system designed for a 4-bit microprocessor by a 2-bit
company that can't stand one bit of competition."
La mia (penosa) homepage: 
http://digilander.iol.it/burton666

 dire, anzi, che sono in contrapposizione, per qualche verso.
Pregasi dare definizione di "buono". Sicuramente sono il meglio che si possa
avere sotto x86.
Faccio anche notare che per superare le performance negli interi di un XP
1900+ occorre un IBM Power4 1.3 GHz...


il subject parla solo:
1) I processori d fascia bassa (intel: celeron p3 p4 - Amd athon athlon xp
duron) sono tutti equistabili, il problema è sul chipset! (NO VIA) (si
intel, si amd) (SiS e Ali poco performanti)
2) Se prendi una cpu intel, prendi chipset intel [per p3 e cell t consiglio
l' 815E] per amd, prendi chipset amd [amd non è compreso nelle mie
competenze]
3) una cpu che scalda è una cpu che va forte è FALSO!... i k6/2 scaldano un
casino e vanno lentuccii!!!
4) per raffreddare un AMD non è vero che c vuole un freezer... ma aiuta! :)
[i dissy certificati fanno il loro dovere, se la cpu nn è in overclock)
5) Se vuoi overcloccare molto, prendi AMD...
per overclock leggeri, prendi Intel...
6) se vuoi overcloccare e avere un sistema stabile, non overcloccare!
per il resto il consiglio ke t posso dare, è quello d fare i conti con le
tue tasche! intel costa d più d amd e, DICONO, vada più lento dell'economico
AMD...
a te l'ardua sentenza!

 1900+ occorre un IBM Power4 1.3 GHz...
Gia`, ma come siamo messi ad altri parametri?
Ad esempio consumo?
bye,
-- 
  Piergiorgio Sartor

AMD...
a prezzi comparabili si..  in assoluto .. se mi regalassero un 2Ghz me 
lo terrei eccome!!
Ma NON lo comprerei.
ciao r.d.

100, e tutto funziona perfettamente, anche overcloccando il processore.
vabbe', stai parlando di un guasto, non di problemi di architettura...


G4 tower powerpc ( doppia cpu ) a 800 mhz  e voli .......................
voli poco, visto che non ti restano soldi per il biglietto... ^____^
e poi volare di questi tempi e' poco sicuro :-)


Ne` uno, ne` l'altro, what about PowerPC?
conosci qualche produttore di powerpc che li faccia pagare il prezzo
_giusto_ e non quella truffatrice di apple? 
per la cronaca, qualche tempo fa Motorola si vantava di poter produrre
i g4 a 5$ l'uno quando Intel stimava di spendere 30$ a p3... quanto li
fa pagare i suoi computer apple, partendo da questi presupposti?
 senza parlare che sul sito apple 256mb di memoria sdr pc 133 non
buffered un mese fa costavano 200$...)


Maurizio Mugelli wrote:
[cut]
E che mi dici del 6502 :-)
bye,
-- 
piergiorgio

 _giusto_ e non quella truffatrice di apple?
Si parlava di "affidabilita`".
Direi che in questo specifico settore i PPC siano
superiori a qualunque x86.
Poi, sempre in termini di processore, costano anche
meno, il problema, come fai notare, e` che l'unico
che ti fornisce anche il resto attorno e` solo
Apple (o IBM), ma questi sono fuori mercato...
bye,
-- 
piergiorgio

AMD...
Dicono bene :)
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
Tessera #008 B.A.G., #000 DPPSJ, #013 B.A.T
"Il Grande Fratello? Non lo farei mai vedere ai miei figli."
(Giovanni Modina, direttore di Canale 5)

]
» Ho letto le Vs. risposte, riprendo il concetto intel-chipset ed Amd-chipset,
» quale tra i  2 sistemi portati allo stremo, sono più sensibili alla
» variazione della temperatura....quale delle 2 cpu ha portato il "parametro
» tolleranze" ad una soglia minima....se overclock non puo significare
» parametri tolleranza alti..?
Una CPU nata per vivere ad una certa frequenza ha parametri di 
tolleranza alti qualsiasi essa sia.
Io il mio PC con Athlon TB 1000Mhz (addirittura Overclockato a 1.2Ghz 
con FSB300) lo tengo acceso 24 ore su 24, 7 giorni su 7 senza 
problemi... se non quelli che crea l'Alcatel SpeedTouch USB quando uso 
un programma di FileSharing tipo eDonkey e WinMX.
Se il tuo problema sono prestazioni e temperature... sappi che un AMD 
non si fonde e lavora comunque, al contrario un Intel se pensa di essere 
troppo caldo castra le prestazioni.
Il tutto adeguatamente raffreddato... ovvero con una ventola da 15-20k e 
pasta termoconduttiva.
-- 
+ > Piersandro Guerrera <-> PaRRoT <-> 
par...@edengames.net
  < +
+ > ICQ: 8372114 <--> Eden.Games - 
http://www.edengames.net
  < +
+ > Risorse per Windows XP <---> 
http://winxp.edengames.net
  < +
+ > News Hardware and Games <---> 
http://news.edengames.net
  < +

 vabbe', stai parlando di un guasto, non di problemi di architettura...
Chissa'... ho sentito varie schede con chipset mvp3 avere problemi di
questo tipo...


 <"\(-: 
EuGeNiO :-\)" è una bestia...
» il subject parla solo:
» 1) I processori d fascia bassa (intel: celeron p3 p4 - Amd athon athlon xp
» duron) sono tutti equistabili, il problema è sul chipset! (NO VIA) (si
» intel, si amd) (SiS e Ali poco performanti)
Non esageriamo con il NO VIA.
Io potrei anche dirti "fanculo Creative" che ha anche le sue colpe in 
merito alle incompatibilità. :o)
I chipset Via hanno pro e contro...
Per il resto tutto oki.



di recente ho visto un derivato a 30mhz...
terrificante ^____^


 terrificante ^____^
Chissa se riesco ad overclockare il buon
vecchio C64, con questo...
bye,
-- 
piergiorgio

 Ad esempio consumo?
Rispetto al Power4? Vorrei saperlo anch'io...
Saluti.
--
    \\//                      Wilmer Ricciotti (da Ancona)


 meno facile per diversi processori raggiungere le loro prestazioni di picco?
Quanto difficile e` scrivere codice che si avvicini
ai benchmark.
Ad es. usare MMX o simili e` difficile, ma aumenta
le prestazioni.
Processori ben fatti sono anche facili da usare.
bye,
-- 
piergiorgio

 Processori ben fatti sono anche facili da usare.
In questo senso, tutti sanno che RISC e EPIC sono un incubo per i
programmatori in assembler...


 programmatori in assembler...
Gia`, ma il compilatore C e` molto piu` facile
da scrivere, data l'estrema ortogonalita` di
queste CPU moderne.
Mentre un x86 non solo e` _difficilissimo_ da
programmare in assembly, ma e` pure difficile
scrivere un compilatore C decente.
Questo e` il senso a cui mi riferivo, quando
parlavo di "architettura" non buona, non agli
aspetti interni del HW, ma al modello di
programmazione, che faceva pena gia` all'epoca
del MC68000, una signora CPU.
bye,
-- 
piergiorgio

vecchio C64, con questo...
e' roba per controller industriali, ma mi pare che dei folli
produssero delle schede di espansione per c64 con questi processori,
anni dopo che il c64 era gia' andato nei celesti pascoli...


 del MC68000, una signora CPU.
Sul fatto che x86 non sia una gran ISA siamo d'accordo, ma allora che
dovremmo dire di IA64?


 dovremmo dire di IA64?
Come ho scritto sopra, non lo conosco, pero` PPC
e` di gran lunga piu` "lineare" ed uniforme.
bye,
-- 
piergiorgio

programmatori in assembler...
Non e' vero, i RISC di solito hanno un set d'istruzioni molto pulito e
ortogonale e per questo si programmano piu' facilmente.
-- 
Lorenzo
(address rot13 encoded)

 ortogonale e per questo si programmano piu' facilmente.
Effettivamente ammetto che, mentre ho una leggera infarinatura di assembler
x86 e ho dato un'occhiata di sfuggita all'assembler IA64, gli assembler risc
non li ho visti mai nemmeno da lontano.
Ma avevo sentito dire che l'utilizzo di assembler risc è molto laborioso, e
che in effetti tale architettura è pensata per l'utilizzo di compilatori di
livello medio-alto.


 normali e registri FP, per non parlare del resto.
Torniamo sulla FPU? Ma allora tagliamo la testa al toro e chiediamoci: chi č
quel deficiente che ha inventato la FPU basata su stack?


 Non conosco IA64, per cui non posso dire.
Io per curiosita mi sono scaricato i pdf con la descrizione dell'ISA
degli IA64.
Ha un sacco di "features" che per roba non banale sono utilizzabili bene
solo con un compilatore ultra-furbo che sappia come bilanciarne 
costo-beneficio secondo schemi assai diversi da quelli utilizzati
sulle cpu x86 e RISC, oppure richiedono *molto* tempo ad un programmatore 
che codifica a mano con il supporto di tool di analisi e profiling.
L. Micheletto

 quel deficiente che ha inventato la FPU basata su stack?
Era solo un esempio, forse una delle ultime eredita`
del vecchio modello di programmazione.
bye,
-- 
piergiorgio

 che codifica a mano con il supporto di tool di analisi e profiling.
Se e` un VLIW, come ho scritto nell'altra news,
esistono metodi per trovare soluzioni ottime
al problema.
Tipicamente si trasforma il C in informazioni un po'
piu` ampie, assembly, ma anche l'albero decisionale.
Poi lo "scheduler" SW riordina le istruzioni, tenendo
conto del tipo di CPU e dell'albero decisionale,
producendo l'assembly finale.
Per fare questo esistno tecniche e metodi piu` o
meno esaustivi. Un problema potrebbe essere che,
nel caso di alberi decisionali particolarmente
lunghi, la compilazione puo` richiedere molto
tempo e memoria (dell'host dove si compila).
Certo scrivere a manina il codice e` quasi
impossibili (ma non del tutto).
bye,
-- 
piergiorgio

 livello medio-alto.
Il punto chiave del RISC e` che si puo` avere
sempre una compilazione "ottima".
Cioe`, se prendiamo un CISC, ci accorgiamo che,
certi programmi scritti con linguaggio ad alto
livello (C, per esempio), possono essere compilati
seguendo diverse strade ed il compilatore non
ha modo (nessun modo) di sapere quale sara` la
compilazione migliore (relativamente alle
prestazioni run-time). Ovviamente a meno di
non produrre tutti i tipi di codice, fare
delle valutazioni run-time e tenere il migiore,
come fa FFTW.
Per i RISC le cose cambiano un po', cioe` il
compilatore non ha molte scelte (equivalenti)
per produrre un eseguibile, quindi una volta
stabilito un concetto di "minimo", questo sara`
anche l'ottimo.
Certo, questo non tiene conto dell'impatto di
altri fattori, quali la cache, per esempio.
bye,
-- 
piergiorgio

 Quindi il compilatore non e` proprio cosi` difficile
Io non metto in dubbio che esistano delle tecniche per fare ciò. Dico solo
che itanium, specialmente in ALU, non ha queste grandi prestazioni - ed è
equipaggiato con tanta di quella cache!
Spesso allora si dà la colpa ai compilatori. Ricordo una notizia di un paio
di anni fa in cui si diceva che intel aveva rimandato al mittente il
compilatore C++ per IA64 della MS perché generava del codice tremendo...
ecco: se ancora i compilatori per IA64 non sono capaci di ottimizzare il
codice, si vede che non è poi così facile implementare un compilatore C++
per quell'ISA.


 per quell'ISA.
Ehm, MS? Non si saranno impegnati abbastanza... :-)
Piuttosto, riguardo IA64, io ancora non sono convinto
che intel lo spinga piu` di tanto.
Secondo me non hanno interesse alcuno a farlo,
guadagnano abbastanza con i P4.
bye,
-- 
piergiorgio

]
» Piuttosto, riguardo IA64, io ancora non sono convinto
» che intel lo spinga piu` di tanto.
» Secondo me non hanno interesse alcuno a farlo,
» guadagnano abbastanza con i P4.
Fino al 2005 Intel ha progetti di evoluzione del Pentium 4...
Itanium e soci resteranno processori di nicchia per server o, per meglio 
dire, di quei pazzi che vogliono passare a server a 64bit senza che ci 
sia software :o)
Aggiungi che, a quanto leggo, ogni settimana si scopre un bug nuovo di 
Itanium...


livello medio-alto.
Puo' essere laborioso perche' e' piu' generale e non tratta i casi
speciali. Es: lo stack con x86 lo gestisci con push e pop, con un RISC
lo gestisci con le normali istruzioni load&store dove pero' devi
specificare il registro puntatore dello stack.
Comunque nella maggior parte dei casi tutte queste difficolta' sono
superate con l'uso delle macro dell'assembler.
A parte questo hai un set d'istruzioni piu' pulito, con timing di
latenza e throughput piu' precisi e prevedibili.
Istruzioni a tre operandi non distruttive, x86 al massimo puo' usare
"lea eax, [ebx + ecx]" ma e' un trucco :) invece un RISC decente non ha
problemi ha fare l'equivalente di lea, cioe' "add r1, r2, r3".
Con x86 hai meno spazio di manovra perche' hai meno registri general
purpose, 6 per l'esattezza (esp e ebp in pratica non puoi usarli) con in
piu' il fatto che il 99% delle istruzioni x86 sono a 2 op. distruttive
vedi chiaramente che se vuoi implementare un algoritmo non banale allora
il codice tende a diventare meno efficiente e anche meno leggibile.
Anche le regole di pairing su architetture superscalari sono piu'
semplici (in genere) con i RISC.


maniera di eliminare tutti i salti, specie quelli condizionati.
Questa e' parte piu' difficile.
Ogni istruzione ha associato un predicato, vero o falso, e in base a
quello e' eseguita o meno. Roba per compilatori, non per umani..


E` un VLIW, dunque.
No, EPIC non e' un VLIW.
O se vuoi, e' un VLIW ma _estremamente_ complesso e dato che i VLIW sono
semplici per definizione non credo che EPIC si possa definire un VLIW.
EPIC ha tutta una serie di features che lo allontanano da un VLIW, come
la predication, la speculation su codice e dati etc.


 nel messaggio
news:lq920ugnfv8pvt5p3...@4ax.com
 ha tenuto un'interessante
lezione sugli assembler RISC...
Molto interessante... in effetti le istruzioni triadiche me l'ero
completamente dimenticate... è un vero peccato che AMD non abbia più voluto
implementarle nella FPU degli hammer. D'altra parte pare che il progetto
iniziale degli hammer fosse radicalmente diverso da quello che è stato
presentato ultimamente, quindi magari non le hanno cancellate, ma solo
rimandate al K9...


 impossibili (ma non del tutto).
Li il problema e' scrivere codice con prestazioni quasi ottimali, per
routine "corte" e' fattibile, ma anche li se non si hanno buoni
strumenti di supporto per il profiling si rischiano brutte sorprese
in termini di prestazioni.
L. Micheletto

 sia software :o)
Con gli Hammer che inizieranno a picchiare duro gia dal 2003 ?
Tanto vale che i dirigenti Intel facciano bungee jumping senza l'elastico
se hanno veramente intenzione di non fermare in qualche modo AMD.
Inoltre il software c'e' gia da tempo, tutto quello che gira gia sugli
Alpha e sui Mips a 64bit per esempio.
Certo, per ora e' roba da server "grossi", ma gia il video editing lineare
trae grosso beneficio dai 64bit (quindi ci saranno come minimo
gli hobbisti "avanzati" che si interesseranno alle prime cpu a 64bit
abbastanza economiche che giungeranno sul mercato).
L. Micheletto

 Se ad esempio vorranno renderlo SMT ci sara' da sudare (per Intel)
C'è qualcosa che mi sfugge. Mi sembra che non ci sia modo di trasfomare in
SMT un processore la cui architettura è nata per riempire tutti i cicli di
clock, visto che il SMT si avvale dei cicli di clock inutilizzati da un
thread per riempirli con le istruzioni di un altro thread. A meno di qualche
porcheria, ritengo che un processore IA64 con SMT sia una contraddizione in
termini...


 quello e' eseguita o meno. Roba per compilatori, non per umani..
Aspetta, se ho capito bene, per ogni istruzione hai
un "flag" che ti dice se questa (istruzione) deve
essere eseguita oppure no.
Cioe` un esecuzione condizionata o "guarded".
Per la mia esperienza questo non e` un problema,
dato che la cosa non e` usata cosi` spesso come
potrebbe sembrare, ma solo in casi particolari,
utili, ma particolari.
Cose tipo:
(a > b) ? c : d
Tanto per capirci.
bye,
-- 
piergiorgio

  tende a rimarcare fin troppo spesso).
Veramente strano. Secondo me lo fanno apposta,
non posso credere che siano cosi` tontoloni.
Ho letto come viene progettato un VLIW, e` una
cosa veramente sistematica e scientifica.
Tutto viene valutato _senza_ avere nessuna CPU,
ma solo con simulazioni SW e si riesce ad
ottimizare per costi o per prestazioni, a
piacere, come piu` interessa.
Il compilatore dovrebbe essere disponibile _prima_
di avere la CPU. Diverso codice dovrebbe essere
testato (cioe` compilato) per vedere quanto
bene si adatta al modello di CPU previsto e,
in caso di problemi, si puo` procedere a
cambiamenti nella CPU.
Di fatto il compilatore dovrebbe produrre codice
basandosi su di una descrizione della CPU,
descrizione in linguaggio formale.
Tale descrizione puo` essere modificata (cosi`
come il compilatore, ovviamente) per valutare
la migliore configurazione possibile, a seconda
degli scopi (costo vs. prestazioni).
Strano...
bye,
-- 
piergiorgio

Tanto per capirci.
E' usata per implementare _tutti_ i salti condizionati e non.
Da "IA-64 Application Intruction Set Architecture Guide - Revision 1.0"
2.8 Predication
Predication is the conditional execution of instructions. Conditional
execution is implemented through branches in traditional architectures.
IA-64 implements this function through the use of predicated
intructions. Predication removes branches used for conditional execution
resulting in larger basic blocks and the elimination of associated
mispredict penalties.
To illustrate, an unpredicated instruction
	r1 = r2 + r3
when predicated, would be of the form
	if (p5) r1 = r2 + r3
In this example p5 is the controlling predicate that decides whether or
not the instruction executes and updates state. If the predicate value
is true, then the instruction updates state. Otherwise it generally
behaves like a nop. Predicates are assigned values by compare
instructions.
Predicated exectution avoids branches, and simplifies optimizations by
converting a control dependence to data dependence. Consider the
original code:
	if (a > b) c = c + 1
	else d = d * e + f
The branch at (a > b) can be avoided by converting the code above to the
predicated code:
	pT, pF = compare(a > b)
	if (pT) c = c + 1
	if (pF) d = d * e + f
The predicate pT is set to 1 if the condition evaluates to true, and to
0 if the condition evaluates to false. The predicate pF is the
complement of pT. The control dependence of the instructions c = c + 1
and d = d * e + f on the branch with the condition (a > b) is now
converted into a data dependence on compare(a > b) through predicates pT
and pF (the branch is eliminated). An added benefit is that the compiler
can schedule the instructions that write predicates in different manners
including unconditional compares and parallel compares.


con le ottimizzazioni valide per le cpu precedenti).
Infatti.
Il SMT doveva implementarlo l'Alpha 21364, se ricordo bene.
Certamente sarebbe stato molto piu' facile..


rimandate al K9...
C'e' un modo standard per indirizzare registri/memoria in x86 (come del
resto in ogni architettura).
Romperlo a favore di uno piu' esteso sarebbe forse possibile ma
bisognerebbe prendere un altro prefisso (l'ennesimo) e dire "tutte le
istruzioni che hanno questo prefisso usano i nuovi campi reg/mem".
Questo significa come minimo raddoppiare la complessita' del
decodificatore, gia' abbastanza complesso.


No, EPIC non e' un VLIW.
e' costruito intorno ad una architettura vliw, ma ci hanno appoggiato
sopra tante di quelle impalcature che non ci capiscono niente piu'
nemmeno loro... ^____^
e' il motivo principale di tutti i ritardi e del fatto che lo sviluppo
sia diventato un pozzo di investimenti senza fondo.
e' il solito problema di intel, il design lo fanno fare al reparto marketing
invece che agli sviluppatori. poi gli sviluppatori si trovano con richieste 
assurde e cercano di risolverle come meglio possono.


         else d = d * e + f
...e questo pure.
Questi sono casi banalissimi, molto limitati in codice
reale, spesso gli "if-else" sono molto piu` complessi e
non e` possibile evere questo tipo di codice "guarded".
Di solito si usano due alberi decisionali, con jump,
uno per l'"if" ed uno per l'"else".
Nei casi semplici si usa il flag di guardia...
Se loro usano _solo_ la guardia, allora sono messi
proprio malino...
bye,
-- 
piergiorgio

proprio malino...
No no, la vecchia "branch" e' ineliminabile :)


 Strano...
E' parso strano anche a me, secondo alcuni il Merced e' da considerarsi
un prototipo "per la messa a punto finale" che il marketing ha voluto
lanciare sul mercato per tenere buoni quelli che avevano deciso di puntare
su IA64.
Ma il fatto che sia cosi "sbilanciato" (sul floating point in effetti
e' fenomenale per il clock che ha, ma sugli interi lascia perplessi)
potrebbe anche essere indicativo che chi ha fatto la "messa a punto"
del modello virtuale ha privilegiato quelle che venivano considerate
le applicazioni a cui adibire l'IA64 (supercomputing ed elaborazione
di grosse moli di dati DSP-like, ma non roba "classica" da pc).
L. Micheletto

 termini...
Spingendo all'estremo il concetto SMT (tanti thread simultanei
e decoder ridotti all'osso che erogano una sola istruzione per ciclo da
ogni thread) ovviamente non ci sono vantaggi applicandolo ad un VLIW.
Ma se ci sono abbastanza NOP nel codice, anche un VLIW puo trarre vantaggio
da una implementazione SMT, scala meno di un x86 o di un RISC attuale, ma un
certo vantaggio lo si ha (e se non hanno altre vie per alzare le prestazioni
prima o poi lo faranno).
Attualmente gli IA64 prevedono "pacchi da 3" di istruzioni da eseguire
simultaneamente, un IA64 SMT dual thread potrebbe essere utile per 
ottenere prestazioni equivalenti o superiore ad un IA64 con "pacchi da 6"
senza dover ricompilare e magari senza dover raddoppiare pure
le unita di esecuzione (ma aumentandole di quanto basta per non rallentare
l'esecuzione rispetto ad un sistema IA64 dual processor).
L. Micheletto