Newsgroup: it.comp.hardware.cpu
Titolo: Ufficiale Windows x86-64

Conferma ufficiale del supporto Microsoft
ai 64bit di Hammer:
http://www.infoworld.com/articles/hn/xml/02/04/24/020424hnmsamd.xml
(al volo non ho capito se questo e` l'annuncio
vero e proprio o lo anticipa solamente)
Che dire....... ? :-|
Non ci speravo veramente....
La prima volta nella storia
che Intel sara` costretta a
subire uno standard piuttosto
che imporlo?
Ciao

 ha scritto nel messaggio news:fXAx8.84851$SR5.2...@twister1.libero.it...

Ma no......che dici :-).
Il fatto che M$ supporti un set di istruzioni, non
significa che lo stesso diventi uno standard........
Standard di che poi? un set di istruzioni diventa
standard quando tutti lo accettano di buon grado,
implementandolo nelle cpu.
Dato che Intel ha, ovviamente, altre idee in proposito,
Amd ha  resa pubblica un'architettura che solo il
mercato potrà promuovere. Certo, M$ ha agito in
modo corretto, ma nulla più...........
Se si venderanno più K8 che P4 Prescott, allora le
cose, gradualmente cambieranno, altrimenti nisba,
ovvero avremo un sistema di nicchia come se ne
sono visti tanti.
Ciao ciao.
Alberto.

 significa che lo stesso diventi uno standard........
No, infatti IA64 è tutto fuorché uno standard :-D.
Il vero problema è che male che vada Hammer venderà per un 20% del mercato
dei prossimi anni, e IMHO una percentuale del genere non può essere
ignorata. Previsione pessimistica, io credo che il raggiungimento del 25%
sia praticamente scontato, e il 30% non improbabile. Quale che sia la
percentuale, penso che difficilmente potrebbe essere ignorata come in
passato, esistendo tra l'altro il sistema operativo...
C'è poi chi sostiene che MS stia forzando Intel a passare a x86-64...
potrebbero anche fare la loro IAx86-64, superset dell'x86-64, con l'aggiunta
delle PNI (Prescott New Instructions) e certamente non sarebbero obbligati a
chiamarla "tecnologia AMD"... Intel in ogni caso ha la licenza per qualsiasi
set di istruzioni sviluppato da AMD.
Saluti.
--
//   Xelloss da Bologna  || 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________/

 PNI (Prescott New Instructions)
Ma queste PNI cosa sarebbero?
Nuove SIMD (SSE3?) o che altro?
ciao!
--
The computer was conceived as a tool to reduce complexity. Some people
found this loss of complexity unacceptable, and developed UNIX
to reintroduce it.

 Nuove SIMD (SSE3?) o che altro?
Sembrerebbero istruzioni destinate a migliorare l'efficienza di
Hyperthreading, e forse qualcos'altro. Spero veramente non altre SIMD...


 set di istruzioni sviluppato da AMD.
Ma sai benissimo che Intel non si sogna nemmeno di adottare il
set Amd, se passerà al 64bit su P4, lo farà a suo modo, fregandosene
di tutto e di tutti come a sempre fatto e continuerà a fare, vista la
posizione ampiamente dominate.
Come detto più volte K8 sarà un ottimo masticatore di codice a
32bit, l'estensione a 64 è solo un urlo per dire ''ci sono''.
Amd c'è ed è molto migliorata, ma il divario tra le due aziende
è talmente abissale, che è come dire che la Fiat impone a GM
che da ora innanzi le automobili andranno ad alcool etilico :-).
Ciao.
Alberto.

 che da ora innanzi le automobili andranno ad alcool etilico :-).
Figo... ed io che ho sempre detto: "stasera sono senza soldi, o bevo io o 
beve la macchina"...
Cosě prenderei due piccioni con una fava :-DDDDDDDD
--
Just because I don't care doesn't mean I'm not listening.
- Homer Simpson 

set di istruzioni sviluppato da AMD.
come mai c'è quest'accordo?
--
Lawrence Oluyede
rhy...@myself.com

 come mai c'è quest'accordo?
Scambio di brevetti, mi sembra che sia nato dal patteggiamento dopo il
processo Intel-AMD (ai tempi del 486). Diciamo che è un accordo che conviene
ad entrambe le aziende, e non è limitato ai set di istruzioni.


 posizione ampiamente dominate.
Nemmeno se glielo dice MS?
Nota, nemmeno io credo che MS abbia detto a Intel "abbiamo intenzione di
supportare soltanto due architetture a 64 bit: IA64 nei server e AMD64 nei
desktop", significherebbe incrinare un rapporto di amicizia durato anni
(rapporto che, tuttavia, favorisce più intel che MS, intendiamoci...), ma
ammettiamo che lo abbia fatto... credi davvero che intel sarebbe nelle
condizioni di dire di no? Se c'è una cosa che la storia delle CPU in
generale, e di quelle intel in particolare, insegna, è che non vince il
migliore, ma quello che ha più supporto.


processo Intel-AMD (ai tempi del 486). 
eh eh chi si ricorda + :)
--
Lawrence Oluyede
rhy...@myself.com

 > posizione ampiamente dominate.
Mmm.. non vedo il motivo della tua affermazione a parte una certa dose di
orgoglio.. del resto AMD ha preso in prestito da intel le MMX, SSE e SSE2 e
nessuno ha detto nulla (almeno tra gli utenti)
Anzi!

 orgoglio..
E' appunto ciò che a intel non manca.


 Scambio di brevetti, mi sembra che sia nato dal patteggiamento dopo il
Mmmmh, a me pare che sia solamente un "accordo di non belligeranza"...
-- 
Qui e' Jack Burton, del Pork-Chop Express,
che parla a chiunque sia in ascolto...
http://digilander.iol.it/burton666/index.html

 implementandolo nelle cpu.
Infatti, ma si rumoreggia che Micrososft
abbia chiesto esplicitamente ad intel di
introdurre x86-64 uguale ad AMD.
Dato che hanno anche loro la stessa tecnologia
per via dei vari scambi di brevetti.
Cioe` sembrerebbe, per qualche ragione da
verificare, che Microsoft voglia "standardizzare"
le estensioni introdotte da AMD.
Sono sicuro che sotto c'e` altro, staremo
a vedere cosa succede.
bye,
-- 
  Piergiorgio Sartor

 ha scritto nel messaggio
news:ApDx8.86166$SR5.2...@twister1.libero.it...


 migliore, ma quello che ha più supporto.
Ma no, supportare un ulteriore set di istruzioni non è un lavoro
impossibile per M$; non è detto che questo non sia già stato fatto,
in attesa dell'annuncio di Prescott.
M$ non può imporre al leader del mercato lo standard di un
outsider. Più probabile che sviluppi per tutti, dicendo:
scannatevi tra di voi :-)
Dai...... è assurdo non supportare ampiamente chi possiede la
maggioranza del mercato.
Ciao.
Alberto.

 suoi punti forti?
Continui a confondere una buona cpu (K8), con una
corazzata dedicata alla parte alta dell'elaborazione
server e dipartimentale.
Boh.........sei incomprensibile, anche perchè le due cpu
non collidono, quindi..........
Ciao.
Alberto.

maggioranza del mercato.
La maggioranza del mercato è di Microsoft, non di Intel...
Le quote sono 90% per Microsoft e 80% per Intel...
Anzi... MOLTO peggio... 2% del mercato (pure meno, anzi sicuramente) per IA64 e
20% per AMD... Inoltre Hammer venderà sicuramente una marea... Visti i prezzi
che si citano?
http://hit.edengames.net/index.php?id=EpEAZkuuZkdtxFyokM
e non solo... Giusto per farti vedere che nonostante il tuo ferreo ottimismo di
casa Intel, anche da quelle parti c'è qualcosa che non va...
http://hit.edengames.net/index.php?id=EpEAZkuAZkQdVfNyZn
Se queste notizie fossero vere allora si potrebbe capire come mai Intel abbia
premuto cosi' tanto per introdurre i 12 pollici e la produzione a .13... Se sono
false invece... tante illazioni
-- 
e-mail:dialtone#/N0SPAM/#@
aruba.it
|Non vorrei piacere a tutti
togliere #N0SPAM# per inviare     |Avrei meno stima di me stesso
Powered by Debian Woody           |Se piacessi a certa gente
Co-Responsabile Hardware Information & Technology 
http://hit.edengames.net


(ma chi e' che ha cancellato il messaggio di alberto? sul ns non si
vede...)
piu' che altro come dire che la fiat impone a chi le produce i
componenti del motore di modificare la lega usata...
imho obbedirebbero.
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

imho obbedirebbero.
oppure sarebbe come se i produttori di benzina dicessero che da oggi si usa come
combustibile lo sputo di cammello, e faranno i motori a sputo di cammello
altrimenti le macchine non vanno...
Il discorso è sempre lo stesso...


 false invece... tante illazioni
Direi che spediranno in fabbricazione gli ultimi Celeron e PIII,
tanto fra poco spariscono........................
Diverso il discorso Amd che deve mandare fuori il top della
gamma K7, a causa delle scarse rese del processo Motorola.
Ciao.
Alberto.

gamma K7, a causa delle scarse rese del processo Motorola.
Ma cosa dici? il K7 verrà prodotto per tutto il 2003... Chi manda fuori cosa?
La FAB UMC è praticamente al 100% di AMD anche se è nominalmente di UMC/AMD, la
tecnologia che ci va è totalmente AMD, fonte certa. Il K7 ha ancora 1 anno e
mezzo e mi vieni a dire che devono cessare la produzione? Non ti viene in mente
che AMD non può fornire tutte le linee di processori che è in grado di fornire
Intel per un motivo più che chiaro? Gestire 6 linee di processori e rifornire il
mercato con quantità sufficienti per ogni processore sai bene che è cosa da
ALMENO 4 FAB, AMD ne ha 3.
Questo tuo messaggio è la summa del misunderstanding o del pessimismo.


> che da ora innanzi le automobili andranno ad alcool etilico :-).
Ti rispondo da qua Alberto perchè non ho ancora ricevuto il tuo post sul mio
newsserver.
Questa è una sciocchezza bella e buona. Microsoft ha in mano il 90% del mercato
software dei desktop e la sua posizione è MOLTO più forte di quella i Intel. Se
Microsoft decide di agire in un certo modo, Intel si adatta, poche palle. Prova
a immaginare cosa succederebbe se Microsoft dice:"Da ora supporto solo AMD",
Intel si metterà a copiare, ma non perchè non sia capace di fare altro, solo
perchè è costretta, cosi' come è stata costretta a farlo AMD in tutti questi
anni. Ora la situazione è radicalmente cambiata e questo mi fa godere molto, non
perchè Intel sta perdendo mercato a vantaggio di AMD, ma perchè adesso
finalmente se ne vedranno proprio delle belle tra i due giganti con grande
vantaggio del consumatore.


come mai c'è quest'accordo?
diciamo che le varie accuse e controaccuse stavano ingrassando gli
avvocati e non portando benefici a nessuno dei due, quindi si sono
scambiati un accordo con il quale ognuno puo' usare certe tecnologie
dell'altro - con parecchi limiti ovviamente.


sono visti tanti.
ah aha h
--
Lawrence Oluyede
rhy...@myself.com

32bit, l'estensione a 64 è solo un urlo per dire ''ci sono''.
mmm io non penso sia cosi limitato il supporto a 64...ma
come asserisci anche tu..aspettiamo il responso del mercato!
--
Lawrence Oluyede
rhy...@myself.com

 ALMENO 4 FAB, AMD ne ha 3.
Io sapevo che ne aveva 2 :-).
Anzi una, per le cpu.
Ciao.
Alberto.

 sono stati colmati. Il vero problema rimane la FPU, ma a questo punto č
Scherzi vero?
Un core con istruzioni a lunghezza variabile,
uno dei piu` grandi orrori mai visti.
Senza un minimo di ortogonalita` o simmetria.
Il giro di affari intorno a x86 ha consentito
di mantenerlo in vita e spingerlo la dove
nessuna CPU e` mai stata.
Se lo stesso fosse successo ad Alpha o PPC,
oggi avremo queste CPU 10 volte piu` veloci
di un P4 di punta.
bye,
-- 
piergiorgio

 non collidono, quindi..........
Hai scelto un paragone calzante.
Hai presente le corazzate tipo Yamato ?
Erano dei mostri superblindati con cannoni di calibro
e potenza superiore a qualsiasi altro installato su navi
da guerra.
Non c'era *corazzata* in grado di tener loro testa ...
... e per questo furono fottute dagli aerosiluranti
imbarcati sulle portaerei.
Lo sanno anche i sassi che l'obiettivo di Intel
era introdurre IA64 in fascia alta e poi "calare in basso"
ed assorbire tutto il settore degli x86 compatibili.
Se ora fa dichiarazioni di tipo diverso e' perche AMD
gli ha rovinato la festa, ma per Intel non ha senso
avere una cpu "di fascia alta ma solo per quella"
che vende troppo poco (nonostante possibili margini
di guadagno elevati).
L. Micheletto

produzione per terzi...............
Se ti dico che la mia è una fonte certa non puoi venire a dire cagate... La
produzione UMC è totalmente in mano ad AMD, tecnologia compresa. Se le cose
vanno male AMD non ci rimette quasi nulla (come era stato suggerito da Mugelli
mi pare). E ripeto: fonte _CERTA_


 di un P4 di punta.
Infatti.. non oso immaginare cosa sarebbe potuto diventare il PPC con una
azienda come Intel che è la migliore per quanto riguarda i processi
produttivi o anche con una AMD che come dimostrato fin ora riesce a
competere alla pari nonostante tutto.
Purtroppo alla Motorola non hanno dato la giusta importanza alle CPU del
tipo 68xxx prima e PPC ora e spero che ne paghino tutte le conseguenze,
nessuan esclusa.
IBM invece sembra svegliarsi solo ora dal letargo (forse perchè una certa
SONY ha bussato alle porte) e si appresta progettare il succssore del PPC
per la prox PSX 3, non sto parlndo del G5 ovviamente, comunque vedremo..
sperem.
Ad ogni modo sono curioso di sapere quali saranno le estenzioni a 64bit di
Hammer, ma una cosa mi è chiara, le scelte sono solo 2, in pratica o si
estendono tutte le istruzioni x86 classiche ai 64bit (registri e memoria)
oppure si includono nell'ASM x86 nuove istruzioni totalmente diverse
specifiche per i 64 bit.
Tra le 2 ipotesi la 2 è la meglio ma necessita di sw totalmente ricompilato
atrimenti i benefici non si vedono.
Chi sa la verita?
ciauz

 almeno. Non ti basta?
Si ma stiamo parlando di amd che sforna prodotti instabili :-) mica dei
tecnici intel che sfornano solo ottimi prodotti, vedi p4 e socket 423 (per
parlare solo degli ultimissimi mesi)

gamma K7, a causa delle scarse rese del processo Motorola.
Ovvero i processori di fascia bassa, visto che quelli di fascia alta
saranno i K8 :-)
-- 
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)

 di un P4 di punta.
Questo lo dici tu, non ne sono minimamente convinto...
Pensaci bene, i concorrenti di intel e AMD hanno difficoltà a mostrare
prestazioni particolarmente superiori, pur potendo contare su architetture
migliori di diversi ordini di grandezza (**). Se si fosse imposto uno
standard migliore di x86, sarebbe stato ulteriormente più difficile per i
concorrenti raggiungere lo stesso livello di prestazioni; ne consegue che
non sarebbero stati dedicati molti fondi allo sviluppo dei processori basati
sull'ISA "standard". Forse avremmo processori più veloci, ma non così tanto
più veloci, ammesso che ce ne sia bisogno...
(*) alcuni studi mostrano come le CPU x86, che un tempo erano notevolmente
più lente delle RISC in ogni campo, ora superino le RISC nei calcoli interi
e siano sulla strada per minacciarle anche in floating-point... si direbbe
che man mano che il tempo passa, si senta sempre meno bisogno di lasciare
questa "schifosissima" ISA.
(**) non è proprio la mia opinione, comunque.
Saluti.
--
//  Xelloss dal portatile || in real life: Wilmer Ricciotti  \\


 Chi sa la verita?
Estensione a 64 bit dei registri generali, e raddoppio del loro numero.
Eliminazione di alcune istruzioni completamente obsolete. Modello di
gestione della memoria "flat". In pratica č una variante della scelta 1, che
č anche l'unica sensata per consentire l'esecuzione di codice "misto" 32/64
bit (inevitabile in ambienti multitasking).
Nota che la scelta 2 sarebbe piů o meno "painless" per AMD, basterebbe
esporre il microcodice RISC utilizzato in tutte le CPU a partire dal K6...
Saluti.
--
//  Xelloss dal portatile || in real life: Wilmer Ricciotti  \\


mi pare). E ripeto: fonte _CERTA_
Quale di preciso?


 questa "schifosissima" ISA.
Dipende sempre da cosa confronti.
Se faccio un confronto a pari investimenti, mi torna
sicuramente un risultato diverso.
Solo due sono state le reali migliorie introdotte
nella classe x86: la FPU del Pentium e l'aumento di
spropositato di clock (senza il quale non si andava
da nessuna parte).
Ma come ho gia` detto, avere un clock a 10GH, con 100
stadi di pipeline, non mi pare un successo tecnico.
bye,
-- 
  Piergiorgio Sartor

Quale di preciso?
Ti ho risposto in mail


 Alberto.
si pero se le auto fiat ad alcool farebbero 100Km con un litro vedresti GM
affrettarsi a costruirle pure lei..............
non sottovaluterei il fatto che microsoft si è decisa a sviluppare s.o. per
questa nuova piattaforma fino ad ora è stato difficile ottenere anche
qualche piccola patch per amd figuriamoci un s.o. intero.........

 mi pare). E ripeto: fonte _CERTA_
Bravo superi i migliori siti di HT.
Ovviamente spero che ti riferisca alla porzione
di produzione UMC legata al K7, vero?
UMC non č proprietą Amd, a quanto ne so.
(comuque sia, non č una situazione comoda).
Solo i veri uomini hanno le fab? (Sanders)
Ciao.
Alberto.

 qualche piccola patch per amd figuriamoci un s.o. intero.........
Questo non e` esatto, almeno non lo e` l'ordine
di grandezza.
Per confronto prendi le modifiche di Linux per x86-64,
e` proprio un patch che va a toccare uno o due file,
quelli che si occupano della paginazione virtuale.
Non e` che Microsoft si sia affannata a fare un OS
64 bit per K8, ha semplicemente patchato uno o due
file per sfruttare (nominalmente) i 64 bit.
bye,
-- 
  Piergiorgio Sartor

 stadi di pipeline, non mi pare un successo tecnico.
Basta che allunghino le pipeline lentamente, in modo da stargli dietro col
resto della tecnologia. L'approccio Pentium 4 in futuro si rivelerà
sbagliato perché le penalità per gli stalli della pipeline diventeranno
troppo pesanti.


 troppo pesanti.
Infatti il P4 dimostra proprio questo, cioe` che
il limite superiore del clock e` ormai arrivato.
I nuovi P4 a 3.5GHz non saranno 1.75 volte piu`
veloci dei P4 a 2GHz.
Bus di sistema piu` veloci, sono necessari, ma
anche molto costosi, molti di piu` di un bus
interno di prestazioni simili.
DRAM piu` veloce as well.
La cache piu` grande puo` sopperire, ma in
minima parte.
Io insisto per il multi processing, in questo
senso K8 mi pare favorito.
bye,
-- 
  Piergiorgio Sartor

 ha scritto nel messaggio news:3CC80BB0...@libero.it...

Speriamo che vada meglio di come tu dici,
sarebbe un peccato, x86 mi ha stufato.
Ciao.
Alberto.

 troppo pesanti.
Dimentichi Smt :-) ovvero il modo di riempire la pipe.
Ciao.
Alberto.

 Dimentichi Smt :-) ovvero il modo di riempire la pipe.
Sembra che l'arte del quoting sia passata di moda...
Sģ certo, SMT aiuta, ma non tanto quanto vorremmo... forse sarebbe il caso
di passare a un SMT a 4 vie? O la situazione non cambierebbe?
Comunque, prima di dare un giudizio definitivo meglio aspettare prescott...


 esporre il microcodice RISC utilizzato in tutte le CPU a partire dal K6...
Ecco bravo, questa cosa non l'ho mai capita! Mi spiego: per quale motivo AMD
ha 'nascosto' oppure 'non esposto' il codice risc dei k6/k7 impedendone
l'utilizzo ?!?
Poteva essere quella la volta buona per un cambio di rotta...almeno pi
poteve 'attivare' tale feature con un flag  ed invece a quanto pare anche
per i prox anni ci toccherà questo maledetto codice x86 incredibile!

 Comunque, prima di dare un giudizio definitivo meglio aspettare prescott...
Già.....sembra che sia un smt migliorato(+50%?), quello di Prescott.
Certo è che con la nuova generazione, il ''problema pipe'' sarà
meno grave(forse).
Ma la novità maggiore sono le Alu a 32bit. Potremmo avere una
cpu che si mangia alla grande tutta la concorrenza, nessuno escluso.
Ma come detto (vale anche per il K8), aspettiamo serenamente.
Ciao.
Alberto.

 Dimentichi Smt :-) ovvero il modo di riempire la pipe.
Non e` una soluzione, e` solo una pezza
per tirar fuori qualche spicciolo in piu`.
L'idea, di per se, non e` male, anzi, solo
che non da risultati troppo visibili ed
e` un po' troppo specifica (MP).
Sarebbe meglio risolvere il problema a
compile-time, come per i VLIW, ma questa
non mi pare una via accettabile da chi
fa SW per x86.
In realta`, sicuramente vi sono tecniche
simili per sfruttare meglio gli stadi del
pipeline della CPU, solo che per poter 
funzionare bene, serve un redesign del
core, in termini di funzionalita` logiche
(piu` FPU, piu` ALU, etc.), cosa che, molto
facilmente, farebbe allontanare troppo da x86.
bye,
-- 
  Piergiorgio Sartor

Solo i veri uomini hanno le fab? (Sanders)
La FAB di UMC/AMD è in pratica in mano ad AMD, e questo non lo sai, però è
cosi'. Perchè non è comoda? Ti ho detto che qualsiasi cosa succede AMD può
tirarsi fuori e avere un rischio quasi pari a 0. 
Il problema qua è che mentre tu credi alle tue illazioni, quando ti si presenta
una notizia certa, e questa lo è caspita, la dai per falsa, nonostante
l'evidenza e la certezza tu la dai per falsa... Non ti capisco quando fai cosi'.


 per i prox anni ci toccherà questo maledetto codice x86 incredibile!
Esattamente lo stesso pensiero, non mi e` affatto
chiaro il motivo.
E non credo vi siano stati dei limiti tecnici,
forse erano piu` limiti di "segretezza".
bye,
-- 
  Piergiorgio Sartor

 senso K8 mi pare favorito.
Un multiprocessore in ogni casa, in ogni stanza, su ogni scrivania :-D.


 fa SW per x86.
Ma qual'è la strada migliore, dunque ?
Solo Dio lo sa..............
Ciao.
Alberto.

 cpu che si mangia alla grande tutta la concorrenza, nessuno escluso.
La potenza pura aumenterebbe sicuramente, ma le prestazioni non vanno di
pari passo.


 Un multiprocessore in ogni casa, in ogni stanza, su ogni scrivania :-D.
Se riesco a mettere insieme il secondo PC,
mi faccio un cluster con Linux!!! :-)
Con connessione in rete via RS-232! :-)
bye,
-- 
  Piergiorgio Sartor

 Ma qual'č la strada migliore, dunque ?
Per la classe x86 e` ovviamente il multiprocessing.
Oppure una nuova CPU, IA-64 avrebbe potuto esserlo,
pero` non sono piu` cosi` confidente adesso...
bye,
-- 
  Piergiorgio Sartor

Ma come detto (vale anche per il K8), aspettiamo serenamente.
Si narra anche che le ALU saranno a 32bit (sempre lo stesso Hans) e sarà anche
probabile ma sta sicuro che non mandano in giro un processore di quel tipo con
Itanium in giro... E non venirmi a dire che non collidono per piacere, Hammer,
Prescott e Itanium finiscono nello stesso mercato, sia che Alberto sia d'accordo
sia che non lo sia.
Staremo a vedere quello che viene fuori.
-- 
e-mail:dialtone#/N0SPAM/#@
aruba.it
|Non vorrei piacere a tutti
togliere #N0SPAM# per inviare     |Avrei meno stima di me stesso
Powered by Debian Woody           |Se piacessi a certa gente
Co-Responsabile Hardware Information & Technology 
http://hit.edengames.net

 pari passo.
Beh questo vale per qualunque miglioria, anche il CMP ha difetti
insormontabili (con l'attuale tecnologia). Penso bisognerà aspettare
i 0.065um................altrimenti fonde tutto, con die piccolo.
Ciao.
Alberto.

direttamente al CMP.
Sempre Hans scrive che probabilmente l'SMT già attivo ha possibilità di eseguire
4 thread... Vedremo vedremo...
-- 
e-mail:dialtone#/N0SPAM/#@
aruba.it
|Non vorrei piacere a tutti
togliere #N0SPAM# per inviare     |Avrei meno stima di me stesso
Powered by Debian Woody           |Se piacessi a certa gente
Co-Responsabile Hardware Information & Technology 
http://hit.edengames.net

 Si narra anche che le ALU saranno a 32bit (sempre lo stesso Hans) e sarà anche
Ma scusa, non caspisco, adesso le ALU sono a 16bit?
bye,
-- 
  Piergiorgio Sartor

i 0.065um................altrimenti fonde tutto, con die piccolo.
E' prevista per gli .09 con die più piccolo di quello del P4 attuale... Cosa
fonde?
-- 
e-mail:dialtone#/N0SPAM/#@
aruba.it
|Non vorrei piacere a tutti
togliere #N0SPAM# per inviare     |Avrei meno stima di me stesso
Powered by Debian Woody           |Se piacessi a certa gente
Co-Responsabile Hardware Information & Technology 
http://hit.edengames.net

 Staremo a vedere quello che viene fuori.
He gia! :-).
Ciao.
Alberto.


Si, attualmente lavorano eseguendo operazioni a 32 bit dividendole in 2 da 16bit
e facendole eseguire un pezzo a ogni unità e la seconda unità parte mezzo ciclo
di clock dopo la prima.


sviluppava prima heheheheheheh.
IBM il suo processore la fatto... E' un signor processore da 20 mila dollari...
Però dentro ce ne sono 4 e va molto meglio di 4 Itanium


 fonde?
E' la solita menata della densità di energia dissipata per mm2 di
silicio........mi rendo conto che è una cosa noiosa, ma questo limita
il clock raggiungibile, almeno con il raffreddamento tradizionale.
Certo con sistemi alternativi, no problem....ma sai...........
L'aspetto termico è importante, a volte lo si dimentica :-).
Io sono un fissato, però sono giustificato, è il mio campo..........
Ciao.
Alberto.

 Però dentro ce ne sono 4 e va molto meglio di 4 Itanium
Si ma, ora, quanto può scalare ? o è già al limite?.....(siamo già a 0.13u+soi)
Ciao.
Alberto.

 silicio........mi rendo conto che è una cosa noiosa, ma questo limita
Ma usualmente, quando si riduce il gate,
non si riduce anche Vcc?
Cioe` a 0.09um, dovrebbero/potrebbero andare a
1.0V o persino 0.9V.
Con relativa riduzione dei Watt.
bye,
-- 
  Piergiorgio Sartor

 di clock dopo la prima.
???
E perche`? Che ragione c'e` per questo
strano procedimento?
bye,
-- 
  Piergiorgio Sartor

di un P4 a GHz, nessun dubbio su questo.
La migliore cpu all'epoca era (imo) lo z8000, ahime' castrato da un 
indirizzamento iniziale a 16 bit con MMU esterna per indirizzamenti 
maggiori che sarebbe dovuta servire per lo z8001.. il famoso 48 piedini...
(IIRC eh.. son passati gli anni..)
Sigh.. aveva una struttura registri simile a quella dei mainframe 
pur essendo un cpu a stack..
ciao r.d.

 l'evidenza e la certezza tu la dai per falsa... Non ti capisco quando fai cosi'.
Ma quale fab è ? nel sito Umc si parla di una Join per una 300mm
a Singapore, quella è certa, ma la fab attuale che sigla ha? dimmelo
così faccio qualche conto........
Di sicuro, comunque, Umc non fa cenno ad altro processo 0.13u se
non il suo L130, che non pare gran craniata. Poi..................
Ciao.
Alberto.

 Con relativa riduzione dei Watt.
Già ma tu immagina due core, vicini vicini, che se la
zompano a pieno regime..............
Bisogna almeno aspettare i 0.065u (ovvero la riduzione
del 60-70% del vcore) per avere soluzioni accettabili
con die cosi piccolini. Anche Intel ha allo studio una
soluzione simile, purtroppo ora il calore sviluppato è
tale che ottenere un 50-60° stabili a pieno regime, è
problematico. Certo tu puoi abbassare il clock, ma
allora dove è il vantaggio rispetto alla soluzione 2 cpu
separate?, forse qualche % di prestazioni in più ma.....
l'affidabilità della cpu ne risente, nel professionale ovvio :-).
Ciao.
Alberto.

 ha scritto nel messaggio news:aablm6$3lp$1...@atlantis.cu.mi.it...

E' vero, all'epoca era soggiunto un signore
che cercava di convincere la direttrice del
centro di calcolo della Univ., a sostituire
un vecchio IBM con una soluzione z8000
dotata di memoria virtuale su disco.
La mia proff. fu ben impressionata, ma
proprio il limitato indirizzamento diretto,
causņ la rinuncia.......:-(.
Ciao.
Alberto.

 - Difficile manutenzione
Che vuol dire? Ti riferisci al SW?
bye,
-- 
  Piergiorgio Sartor

 La migliore cpu all'epoca era (imo) lo z8000, ahime' castrato da un
Mi pare fosse un po' seguente, o sbaglio.
Credo che uno dei motivi per cui IBM
scelse 8086 fu la relativa "giovinezza"
del 68000 ed un altro la non certezza
delle "quantita`" da parte di Motorola
(suona nuova, questa?)
bye,
-- 
  Piergiorgio Sartor

con die cosi piccolini. 
Calma calma... Il die del CMP Hammer è più grande del die del Prescott. Tutte le
modifiche che faranno al Prescott sono MOLTO più esose in termini di energia
richiesta e dissipazione. Oppure ti scordi di questi problemi con Intel?
Guarda che 2 ALU a 32 bit a doppia frequenza con SMT scaldano un fottio... Altro
che 2 core che bene o male dividono su una superficie più ampia il calore da
dissipare... Tu non la conti quasi mai giusta...


non il suo L130, che non pare gran craniata. Poi..................
Ebbravo, L130 è un cesso ma la tecnologia ti ho detto che la porta AMD. In
questo momento a .13 sono in Taiwan ma quel processo è un cesso, viene portato
dentro da AMD. 


 Con connessione in rete via RS-232! :-)
Azz.. chissa' che prestazioni :D
-- 
Qui e' Jack Burton, del Pork-Chop Express,
che parla a chiunque sia in ascolto...
http://digilander.iol.it/burton666/index.html

 dissipare... Tu non la conti quasi mai giusta...
Mah....sai che sei un bel tipo :-).
Tu raddoppia la dissipazione di un core K7 (è una approx.
ovviamente) e vedi a cosa vai incontro, Soi o non Soi.
Certo anche il Prescot sarà calduccio, ma niente rispetto
a due core già roventi per antonomasia (troppe unità allo
scopo di ottenere ottimi IPC).
Abbiamo un bel ''transistorswagon'' ;-). Facciamo il conto dei
transistors on die? 140Mil? con MOLTISSIMA logica.
Inoltre se rimane l'attuale densità di energia, povero dissipatore,
indipendentemente dalla sup. del die.
Ciao.
Alberto.

 dentro da AMD.
Ho detto che non è una craniata, non un cesso........
Penso metteranno a frutto le rispettive esperienze, dato
che ormai Motorola si è defilata (peccato).
Ciao.
Alberto.

(suona nuova, questa?)
no hehehe.... 
ma credo che la scelta fosse dovuta alla intelligente modularita'
di 808x..*** in effetti il primo scelto non fu 8086 ma 8088 che permetteva
bus semplici e poco costosi..  poi vennero 8086 (il primo che vidi era su un 
Olivetti ) e 80286.. il resto e' storia.
**l'indirizzamento a 2MB permesso dalla architettura 8086 sembro' all'epoca
largamente ridondante.. era l'epoca di "nessuno avra' mai bisogno di +
di 640kb..." ed in effetti le MV sotto CP/CMS di IBM raramente avevano
uno spazio di oltre 1MB.. (virtuale ovviamente.. andavamo in piu' di 
cento con 4MB REALI, era un IBM serie 370/168.. )
ciao r.d.

indipendentemente dalla sup. del die.
Ahhhhhh Che stress che sei... Willamette consuma oltre 100W a 2 Ghz... Non
venirmi a dire che Hammer sia a rischio... un bel dissipatore 80x80 a 2 Ghz
consuma 80W, ti sembra una previsione errata? A me no.


che ormai Motorola si è defilata (peccato).
Qua ero d'accordo con te... Non è un processo produttivo da processori oltre il
Ghz e mezzo... Con il processo di UMC difficilmente superi 1.2/1.4Ghz.


 Azz.. chissa' che prestazioni :D
Bisogna fare un fine tuning del
load balancing :-)
bye,
-- 
piergiorgio

 di passare a un SMT a 4 vie? O la situazione non cambierebbe?
Propendo per la seconda ipotesi. Hai visto i test fatti da Anandtech? Un
dual Xeon con  SMT abilitato guadagnava pochissimo  rispetto allo stesso
sistema  senza SMT. Questo  e` segno  (IMHO) che  il bus  di sistema  e`
diventato il collo di bottiglia e limita le prestazioni. Implementare un
SMT a 4 vie andrebbe (sempre  IMHO) a cozzare contro lo stesso problema.
Un P4 con SMT a 4 vie attaccato ad un bus HT sarebbe un'altra cosa...
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
"La mia teoria scientifica preferita e` quella secondo la quale gli 
 anelli di Saturno sarebbero interamente composti dai bagagli andati 
 persi nei viaggi aerei." -- Mark Russel

IA-64 è un bel sogno, che poi sia targato Intel non mi riguarda.......
era un bellissimo sogno in origine, poi lo hanno pasticciato oltre
ogni limite...
non potevano limitarsi ad una soluzione vliw "pulita"? no, dovevano
per forza incollarci tutti quegli orpelli posticci che la complicano
inutilmente...
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

l'utilizzo ?!?
gia', e' una cosa che mi chiedo praticamente dall'annuncio del k6 da
parte di NexGen...
si fosse potuto programmare nativamente in risc86 chissa come
sarebbero cambiate le cose...


scelse 8086 fu la relativa "giovinezza"
no, fu che l'8088 costava molto meno in quantita'.
IBM non credeva nei personal, li realizzo' soltanto per soddisfare le
richieste degli investitori e fece di tutto per ridurre al minimo le
perdite di quello che era convinta si sarebbe risolto in un flop
completo...


non sono mai state realmente un problema.
a parte l'fpu del 040, se non ottimizzavi specificamente ti trovavi
con prestazioni terribili.


i 0.065um................altrimenti fonde tutto, con die piccolo.
quali difetti insormontabili? non mi pare che i power4 abbiano grossi
problemi, o gli ultimi ultrasparc o gli ultimi PA...
ha _costi_ elevati con l'attuale tecnologia, questo e' indubbio, ma
tecnicamente non ha assolutamente problemi fintanto che e' legata ad
un bus sufficientemente ampio da gestirla bene.


Ciao.
il problema resta il bus, anche a 533mhz in single con smt pienamente
funzionante sono dolori - in multicpu e' un disastro.


 inutilmente...
La mia impressione e` che abbiano voluto
fare la CPU *perfetta*.
Il VLIW ovviamente *non* e` la CPU perfetta,
per cui si sono messi a correggere tutti i
"difetti" aggiungendo cose che alla fine fanno
piu` danno che altro.
Se questo e` vero, sembrerebbe trattarsi di
tipico caso di: "non sappiamo cosa farci,
quindi dobbiamo poterci fare tutto".
bye,
-- 
piergiorgio

 con prestazioni terribili.
C'era di peggio, in alcuni casi
si era costretti a riscrivere
(piccole) parti del codice, per
minuscole incompatibilita`.
Questo, pero`, faceva si che
si ottimizzasse continuamente
il software.
In realta` credo sia salutare,
sempre il software, sempre dal
punto di vista tecnico, avere
CPU sempre migliori, ma leggermente
incompatibili, cosi` da spingere
al rinnovo *anche* del parco SW,
non solo di quello HW.
bye,
-- 
piergiorgio

 sarebbe un peccato, x86 mi ha stufato.
Se volevi stufarti di x86, dovevi farlo prima. Ormai ha prestazioni troppo
buone.
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________/

 per i prox anni ci toccherà questo maledetto codice x86 incredibile!
Uccidere x86? E' fuori discussione, visto che ha prestazioni migliori che
mai. Volenti o nolenti, tanto gli unici che hanno a che fare con l'assembler
x86, ormai, sono quelli che scrivono compilatori, e anche per loro
l'architettura è ormai talmente familiare...


 di un P4 a GHz, nessun dubbio su questo.
Difficile non avere dubbi, quando si comincia con un "se". Tutto dipende
dalla competizione, č quella l'unica motivazione per fare progetti sempre
migliori.


 forse erano piu` limiti di "segretezza".
Probabilmente le "istruzioni risc" dei K6/K7 sono troppo
dipendenti dall'hardware (piu che istruzioni vere e proprie credo siano
dei tag con un valore temporaneo ed un "selettore di unita funzionale").
Nelle cpu x86 recenti le istruzioni in formato x86 una volta che
arrivano al decoder "scompaiono" e tutto il resto e' piu o meno
un risc superscalare.
Per "esporre l'anima risc" sarebbe servito un decoder aggiuntivo
(che espone al programmatore un formato "portabile" anche alle cpu
  successive senza aggravi in termini di prestazioni), inoltre
sarebbe servito un compilatore radicalmente diverso.
E' una cosa banale, ma per avere un compilatore x86-64 "che funziona"
(anche se ottimizza poco il codice) basta prendere il GCC ed editare
il backend per x86 cambiando le dimensioni dei registri ed impedendo
la generazione di INC e DEC "corti".
Una volta fatto questo si puo gia iniziare a portare il codice
(con prestazioni a 64bit al massimo con un certo aggravio
  a causa del maggior spazio occupato da dati e codice nelle cache)
e si ha tutto il tempo per migliorare il backend.
I rischi dal lato compilatore sono quindi ridotti al minimo, tutto
l'opposto di quanto e' accaduto con IA64.
AMD evidentemente ha voluto giocare sul sicuro
(ovvero: "male che vada sara' un x86 piu veloce").
L. Micheletto

 Con connessione in rete via RS-232! :-)
Su, su, confessa, sotto, sotto stai gia pensando ad un doppio
link in direct bound. ;-)
L. Micheletto

Alberto wrote:
 > Speriamo che vada meglio di come tu dici,
 > sarebbe un peccato, x86 mi ha stufato.
Il guaio e' che IA64 sembra messo veramente male, anche se
in teoria MS .Net *potrebbe* salvarlo se Intel
non lo affossa prima.
I casi sono due: o Intel ammazza l'IA64 entro un anno
oppure tiene duro per almeno 4 anni sperando che AMD
arrivata al K10 non riesca piu a salire di prestazioni
(con l'IA64 che nel frattempo continua a crescere
  in termini di hardware e compilatore mentre tira
  a campare nella fascia alta sperando che HP/Compaq
  non decida/decidano di cambiare cpu).
Se penso che anni fa Intel ha avuto l'occasione
di "portare a casa" l'Alpha (quando ha acquisito
le fab ex-DEC prima e lo StrongArm poi) che allora
era gia la cpu piu potente e con una base di utenza
consolidata ...
... viene da pensare a cosa potrebbe fare *ora* una
cpu Alpha EV8 "made in Intel" clockata a 2400Mhz
con SMT e memory controller integrato con 8 canali
rambus per cpu (con un rating tipo XP4800+
tanto per rendere l'idea).
L. Micheletto

affrettarsi a costruirle pure lei..............
Ma in tutto questo c'è il fatto che il petrolio non sarà abbandonato
perchè sennò i pesi arabi vanno in c......
Ergo, non sempre la tecnologia migliore domina sul resto ;)
-- 
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)

l'utilizzo ?!?
Quello delle CPU intel è pure nascosto o no?
-- 
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)

cpu che si mangia alla grande tutta la concorrenza, nessuno escluso.
Spero in un'ottima CPU da parte di intel... così AMD sarebbe obbligata
a darsi una mossa, e così via ;)


Ottime prestazioni, ma quanto costa un'Alpha?
Perchè è rimasto un processore di nicchia... *se* si fosse imposto
come standard, i prezzi si sarebbero abbassati, e con 2 o 3 produttori
di CPU basate su architettura Alpha -un po' come Intel e AMD su x86-
penso si sarebbe sviluppato in proporzione come si è sviluppata x86 ->
un mostro...
Idem se IBM 20 anni fa avesse scelto il 68.000... quando ho visto quei
16 registri a 32 bit, mi è venuto da piangere ;_____;


Io sono un fissato, però sono giustificato, è il mio campo..........
Che lavoro fai?


non si riduce anche Vcc?
Si ma aumentano i transistor :-)
Il mio K6/233 coi suoi 33 watt a pieno carico, all'epoca era
classificato tra i forni a legna... ora una cpu di punta che dissipi
33W farebbe gridare al miracolo ^__^


IA-64 č un bel sogno, che poi sia targato Intel non mi riguarda.......
No, ma che sia uscito con anni di ritardo č innegabile... e questo gli
ha tarpato le ali.


 un mostro...
Beh, gli Alpha non sono proprio progettati col desktop in testa, basta
guardare le schede madri...
Mi sa che il confronto RISC/x86 sia fattibile solo con i PowerPC...
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________/

 migliori.
Ma e` il concetto di "migliore" che e`
opinabile.
Un P4 e` migliore di un P1, ma non e`
migliore di un PPC o di un Alpha.
bye,
-- 
piergiorgio

 guardare le schede madri...
In realta` Digital aveva l'idea di
partire dai server e scendere ai
desktop. Questo anche spiega lo
sforzo SW per rendere Alpha compatibile
con il Pentium.
Eppoi Alpha non era cosi` costoso,
perche` era molto scalabile, per
esempio da 0 a 4 unita` FP, con costi
(e prestazioni) ovviamente diversi.
bye,
-- 
piergiorgio

minuscole incompatibilita`.
la fpu del '40 era davvero terribile - per realizzarla on-chip
decisero di eliminare alcune istruzioni complesse (alcune di quelle
standard iee!) ed implementarle via librerie software.
se queste librerie non venivano caricate dal s.o. la fpu era del tutto
incompatibile sia con le iee sia con il codice 68881/2.
se le librerie erano presenti l'emulazione passava comunque via alu,
con prestazioni tremende.
con codice ottimizzato d'altra parte era velocissima (ancora il
pentium era da venire...).
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

Ottime prestazioni, ma quanto costa un'Alpha?
un 21264 se non ricordo male ha 17Mtransistor - un'inezia al giorno
d'oggi, e nonostante cio' ha ancora prestazioni di punta...
se costa e' perche' non viene prodotto in quantita' piu' che per la
tecnologia produttiva necessaria.


 un 21264 se non ricordo male ha 17Mtransistor
Anche di meno... mi pare attorno ai 15 milioni..


 la fpu del '40 era davvero terribile - per realizzarla on-chip
La storia e` alquanto complessa.
Il 68881 e 68882 erano le FPU off-chip
della famiglia 68000.
Processori decenti, ma sempre off-chip.
Nel 040 viene integrato un *subset* del 882
(non ricordo se la storia inizia con il 030),
per fare spazio ad altre cosucce, tipo la
cache piu` ampia ed il supporto MP.
Nel 060 viene integrato un subset della FPU
del 040 (!), cioe` praticamente solo la somma
e moltiplicazione (dico io), sempre per gli
stessi motivi.
Comunque Motorola forniva le librerie di
compatibilita` FP... Agratis! :-)
bye,
-- 
piergiorgio

quindi dobbiamo poterci fare tutto".
beh, questo era scontato: dopotutto sono cpu general purpose...

Ottime prestazioni, ma quanto costa un'Alpha?
piuttosto: quanti se ne vendono ? essendo un settore di nicchia (alte
prestazioni poi) e' logico che i costi siano alti
che poi, se non erro, il processore in se' non e' che costi cifre folli
(soprattutto se guardiamo i listini intel, _quelli_ sono prezzi folli),
sono le mainboard che...

l'architettura è ormai talmente familiare...
no, in realta' il peso di X86 non sta nel costo necessario allo sviluppo 
software o alle prestazioni ottenibili, ma nel costo *hardware*, dovuto 
a strutture usate lo 0.001% del resto del chip ma necessarie per mantenere
la compatibilita' col passato.
e man mano che si smette di programmare in assembler (o con compilatori
per i 16bit) aumentano le parti non utilizzate del chip: i compilatori
usano ben poche istruzioni e quelli moderni sono fatti per usare le
istruzioni piu' frequentemente usate e quindi rese piu' veloci (e' un po'
un cane che si morde la coda...). pero' il microcodice necessario
all'istruzione LAHF rimane li' in attesa...

 un bus sufficientemente ampio da gestirla bene.
Gią, ma noi stiamo parlando di cpu che non dovranno
costare un'arto. Ibm ha fatto il suo esercizio di bravura,
peccato costi decine di milioni (di lire).
Ciao.
Alberto.

 Ahhhhhh Che stress che sei... Willamette consuma oltre 100W a 2 Ghz...
Ooops 75W a 2Ghz, con gli stessi criteri adottati da
Amd nel Palomino (vedi data sheet).
I segreti di Amd.......................;-).
Ciao.
Alberto.

 l'utilizzo ?!?
Utilizzare un livello di astrazione permette di lavorare su due piani
separati senza preoccuparsi di cosa c'è sopra o sotto.
Se imponi un nuovo piano di astrazione, puoi dividere il problema in sotto
problemi più semplici, ma ci si trova a dover rispettare dei nuovi vincoli
che in futuro potrebbe esser comodo cambiare e in generale si perde
efficenza nelle entità che sfruttano il piano di astrazione più elevato.
...questo lo si può applicare a tutti i campi della progettazione...
--
Reply to: brain79(at)
inwind.it
www.brainetwork.net
ICQ# 
4742797710
 - FeSToso n°143

 I segreti di Amd.......................;-).
Non l'hai più letto quel post di Ace's hardware che ti avevo mostrato, eh?
:-)


 concetto _e`_ sbagliato.
Anche quando ogni bit di memoria era più preziosa di una CU un po' più
complessa?


 peccato costi decine di milioni (di lire).
Guarda che a 0.09u è già fattibile con die di dimensioni umane. E per umane
intendo non più della metà di Willamette.


 1.0V o persino 0.9V.
...ma non in maniera proporzionale... non si può restare sotto soglia... e
la soglia non si può spostare più di tanto...


peccato costi decine di milioni (di lire).
costare un arto? 
con gli shrink attuali (90nm) del processo produttivo processori
nell'ordine dei 100milioni di transistor sono al massimo nel range
"alto", non in quello supercomputing.
e una soluzione del genere abbatte i costi delle mb per
multiprocessing massivo drasticamente.
una soluzione 8way ti viene a costare un 70% in meno,
complessivamente, forse anche piu' - con prestazioni enormemente
superiori (il bus locale fra le coppie di processori permette di
condividere la cache locale con bandwidth immense).


sono le mainboard che...
stesso discorso, mb prodotte in quantitativi di nicchia, per mercati
di nicchia.
potresti adattare tranquillamente un die 21264 ad un package SocketA e
montarlo su una k7s5a da 80 euro, basterebbe aggiornare il bios
(ovviamente gli attuali '264 non hanno l2 on-die...)
cio' non toglie che - nonostante tutto questo potenziale - alpha e'
morto, mips e' morto, ppc e' moribondo (*), power tira avanti ma non
si sono viste novita' da due anni, sun sta perdendo pezzi ed hp ha
gettato la spugna.
solo x86 continua a prosperare - in questo mondo sopravvivono i piu'
furbi, non i migliori.
(*) e pure io mi sento poco bene... :-)


complessa?
questo ovviamente e' sempre stato il tallone d'achille dei processori
risc...


compatibilita` FP... Agratis! :-)
appunto, librerie che usavano l'alu per gestire la fpu.
performance-hit del 70% - roba da pazzi (di fatti alcune macchine per
rendering montavano dei 68882 con dei 68040 con fpu disabilitata per
avere prestazioni decenti con soft generico...)


 beh, questo era scontato: dopotutto sono cpu general purpose...
Non proprio, se pensavano realmente ai server
come mercato.
bye,
-- 
piergiorgio

 complessa?
Con un minimo di pensiero al futuro, direi
che si poteva fare meglio.
Eppoi parliamo della classe i386, non piu` 8086,
all'epoca la memoria era gia` abbastanza grande
(ma si distingueva fra i primi 640k ed il resto...)
bye,
-- 
piergiorgio

 (ma si distingueva fra i primi 640k ed il resto...)
Ma appunto Intel prima del 386 aveva provato a immettere sul mercato
l'iAPX432 -- perché non ha avuto successo?
(Comunque di 386 con 1 MB di RAM ne ho visti piů d'uno, la RAM non č andata
veramente giů fino al '95)


 :-)
Letto letto, peccato che non cambia molto:
entrambe le aziende, quando danno i ''numeri'' della dissipazione,
si riferiscono ai massimi valori in esecuzione di sw commerciali.
Perciò...............prendiamoli per buoni, altrimenti si può dare del
bugiardo sia Amd che a Intel.
Il problema di Amd è che dividendo il valore di dissipazione max
con i sw comm. per il Vcore, si ottengono gli ampere max................
Ma allora non sono i MAX, ovvero quelli dichiarati da Intel in
condizioni worst case.................capito, o no?
Ergo, non conosciamo gli ampere assorbiti da Amd in worst case,
ma solo quelli in esecuzione di sw commerciali.
Hai hai hai !
Ciao.
Alberto.

 Che lavoro fai?
Mi occupo di termotecnica, per vivere.
Ciao.
Alberto.

 ma solo quelli in esecuzione di sw commerciali.
Non hai capito niente :-).
Il thermal design dei pentium 4 non è la dissipazione massima col software
commerciale, ma una sua frazione. Inoltre è addirittura misurata con il die
raffreddato a temperatura ambiente, che implica resistenza minore, e quindi
dissipazione più bassa di quella che avresti alla temperatura massima del
die.
La dissipazione massima degli AMD è misurata col die a 90/95 °C, e quindi si
può ben considerare "worst case", nel senso che si spera che tutti
raffreddino il die a circa 50/55 °C almeno, ottenendo dissipazioni minori.


 raffreddino il die a circa 50/55 °C almeno, ottenendo dissipazioni minori.
La temp del die non influenza i W dissipati.
Ovvero puoi dissipare 50W a 50° come
a 90°................strano vero? :-)
Ciao.
Alberto.

 a 90°................strano vero? :-)
Temperatura maggiore => Resistenza maggiore => maggiore dissipazione
P=r*i^2... mi sembra banale, vale per tutti i circuiti elettrici.
Mi piacerebbe spostare la discussione sul forum di Ace's hardware...


 veramente giů fino al '95)
Miii, hai detto niente, 1MB.
Ci gira ampiamente codice 68000, che non
e` proprio ottimizzato per l'uso della memoria.
bye,
-- 
piergiorgio

 Mi piacerebbe spostare la discussione sul forum di Ace's hardware...
Supponendo che funzioni come dici tu, ma non è visto
che una cosa è la temperatura superficiale del rivestimento
del die, altro è la temperatura effettiva delle giunzioni e il calcolo
è effettuato con il sistema die-pasta-dissy, senza mettere in
conto quello che avviene nei conduttori interni:
la temperatura ambiente è considerata intorno ai 70°
(temp max del case) assumendo un coeff. di temperatura
per il rame pari a 0.0039 per grado:
R1=R0*(1+(90-70)*0.0039)= 1.078*R0
quindi anche facendo questo abominio di calcolo che nulla
ha a che vedere con la realtà, abbiamo una differenza dello
8% fra i due sistemi di misurazione.
Dato che ci riferiamo ai conduttori interni, il divario è
ancora minore, pochi %............non fa testo.
Ciao al prossimo tentativo :-).
Alberto.

 e` proprio ottimizzato per l'uso della memoria.
Anche i 68000 sono soggetti all'elefantiasi del codice? :-)
A proposito, mi piacerebbe dare un'occhiata all'assembler 68000, puoi
consigliarmi qualche manuale scaricabile?


 Ciao al prossimo tentativo :-).
Mi presenti dati che non posso né confermare né confutare, che ne dici di
fare una chiacchierata in un ambiente un po' piů ampio?


 la temperatura ambiente è considerata intorno ai 70°
Comunque le mie fonti negavano questo.


 fare una chiacchierata in un ambiente un po' piů ampio?
Ma figurati, ovvio, ci mancherebbe...............
discutere č sempre stimolante e TUTTI possono
sbagliare.
Ciao.
Alberto.

 Comunque le mie fonti negavano questo.
Beh, l'ambiente è il case no?
In effetti il conto non è giusto, visto che Intel
considera anche la diluizione in temperatura
dovuta all'afflusso di aria dall'esterno( 45°).
Ma lo stesso conto la fa anche (necessariamente)
Amd, apparentemente con un Ta=90° e Te=45°.
(45° è un classico visto che i PC devono funzionare
anche in climi tropicali).
Mi sorge un dubbio sul Ta=90°, sarebbe un forno,
comunque mi informo meglio dalle documentazioni.
Lavori in corso :-).
Ciao.
Alberto.

 P=r*i^2... mi sembra banale, vale per tutti i circuiti elettrici.
Ma e` anche P=(v^2)/r, cioe` la potenza aumenta
al diminuire di "r". Come la mettiamo?
bye,
-- 
piergiorgio

 consigliarmi qualche manuale scaricabile?
Uh? Tempo fa, sul sito della Motorola, sotto
semiconduttori, c'erano tutti i manuali
completi, potresti partire da loro.
bye,
-- 
piergiorgio

 al diminuire di "r". Come la mettiamo?
Interessante, hai anche la soluzione? :-)


 ha scritto
 > nel messaggio news:3CCBB0DA...@nexgo.REMOVE.THIS.de...
 >
 >>Eppoi parliamo della classe i386, non piu` 8086,
 >>all'epoca la memoria era gia` abbastanza grande
 >>(ma si distingueva fra i primi 640k ed il resto...)
 >
 >
 > Ma appunto Intel prima del 386 aveva provato a immettere sul mercato
 > l'iAPX432 -- perché non ha avuto successo?
Perche e' stato probabilmente l'ultima architettura CISC prodotta
con un fottio di feature che a confronto l'Itanium sembra un PIC a 12bit.
Era stato progettato per avere tutte le ultime cose trendy nel settore
dei processori, persino il supporto in hardware delle capability
e che io sappia l'unica "cpu" (si fa per dire) uscita sul mercato
con supporto hardware delle capability e' stata quella degli AS/400 IBM
"originali" (non quelli attuali che fanno girare il vecchio codice in
emulazione).
Giusto per dare un idea: a sentire uno su comp.arch che aveva avuto modo
di aver accesso ad un prototipo di pre-produzione, gli iAPX432 avevano
rom esterne per il microcodice (roba piu da cpu per minicomputer
di una volta che da "nuove" cpu degli anni '80).
L. Micheletto

 Interessante, hai anche la soluzione? :-)
Uhm, si, ma non so se dartela :-P
Dunque, dipende dal modello che usi,
cioe` se usi generatori di corrente
o di tensione.
Se attacchi un generatore di V ad una R,
la formula e` P=(V^2)/R, se ci attacchi
un generatore di I, allora P=(I^2)*R.
La confusione puo` nascere dai teoremi
di equivalenza dei generatori, che pero`
garantiscono l'equivalenza di V ed I
(ed R), ma non di P...
bye,
-- 
piergiorgio

 con un fottio di feature che a confronto l'Itanium sembra un PIC a 12bit.
Coooosa???
Ero convinto che fosse un RISC o un similRISC...
Ma d'altra parte è impossibile farsene un'idea visto che, a guardare il sito
intel, sembra che l'abbiano abiurato assieme all'i860...
Documentazione tecnica? è possibile trovarne?


guardare le schede madri...
Beh nemmeno gli x86 sono progettati con l'high end in testa, eppure...
;)
-- 
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)

un generatore di I, allora P=(I^2)*R.
Alla fine, è un problema di bilanciamento del carico... ^_^


 molto simile. Cioe` hanno la stessa efficienza.
Mah! Non ne sarei cosi sicuro, nonostante gli MC68000
avessero le ALU a 16bit e le AGU a 32bit
(poi portate tutte a 32bit dallo 68010/20 in su)
quei bei 16 registri a 32bit e le varie modalita
di indirizzamento lineare a 32bit logici facevano
un bella differenza a saperli usare (solo con
i 386 si e' avuto qualcosa di simile per gli x86
nonostante gli 8 GPR in meno).
Sfortunatamente in quel periodo i compilatori
non erano al livello di quelli attuali quindi certe
cose si potevano sfruttare solo programmando in assembly.
L. Micheletto

 wrote:

Uhm... voi vi buttate sull'elettrotecnica... io torno alla vecchia
fisica fatta al liceo ;-)
Il mio prof di fisica ha sempre detto che P=(V^2)/R e P=R*I^2 valgono
solo nel caso i conduttori siano Ohmici. Ora, non credo che la
resistenza si una CPU salga linearmente con la tensione e la
corrente... tutti quei transistor e quei semiconduttori di lineare
hanno pochetto. Non č che la soluzione cercata č semplicemente la
formula generale: P=V*I :-D
Ok... ho sparato la mia stronzata quotidiana.
Saluti,
Mav
-- 
<==--------------=[::. Mav .::]=---------------==>
 
www9.brinkster.com/mav3rik
 | 
mav...@yahoo.com
  m[a]v @ 
irc.azzurra.org
    |     ICQ# 22579106
<==--------------------------------------------==>

 formula generale: P=V*I :-D
La soluzione e` *sempre* e *solo* P(t)=V(t)*I(t),
ma si puo` approssimare, soprattutto se
si considerano i valori medi di V o I, anche
per i conduttori non ohmici.
Cioe` posso considerare la corrente media
e quindi considerare  I=V/R.
Dove V e` costante, poiche` il regolatore
di tensione la mantiene tale.
La potenza sara` data da P=V*I=(V^2)/R,
cioe` un potenza media.
Attenzione pero`, Pmedia in generale non e`
data da Vmedia * Imedia!
bye,
-- 
piergiorgio

guardare le schede madri...
Beh nemmeno gli x86 sono progettati con l'high end in testa, eppure...
;)


 ha scritto nel messaggio
 > news:3CCC465B...@libero.it...
 >
 >>Perche e' stato probabilmente l'ultima architettura CISC prodotta
 >>con un fottio di feature che a confronto l'Itanium sembra un PIC a 12bit.
 >
 >
 > Coooosa???
 > Ero convinto che fosse un RISC o un similRISC...
 > Ma d'altra parte è impossibile farsene un'idea visto che, a guardare il sito
 > intel, sembra che l'abbiano abiurato assieme all'i860...
 > Documentazione tecnica? è possibile trovarne?
Difficile, non e' neppure uscito sul mercato che io sappia.
Forse, se chiedi su comp.arch qualcuno puo dirti qualcosa di
piu preciso, ma a quei tempi non c'erano i pdf ed in certi casi
la documentazione tecnica "riservata" era stampata in modo da
rendere impossibili le fotocopie ... e la lettura ai daltonici.
Quelle che ho scritto nel post precedente sono ricordi di
cose che ho letto l'anno scorso in un post in quel ng.
Forse cercando su google riesci a recuperare i link giusti.
L. Micheletto

 ...questo lo si può applicare a tutti i campi della progettazione...
Giustissimo, ottima considerazione.
A questo punto penso che neanche AMD abbia mai creduto nelle sue capacità e
per questo motivo ha perso il treno, poteva essere un successone o magari
nulla di che ma il rischio peggiore era quello che nessuno se la filasse.
Visto che poi il K7 ha una struttura completamente diversa si poteva tentare
e non restare vincolati allo sviluppo del K6.
Che so'.. si potevano introdurre delle semplici e utilissime
add d1,d2,d3
madd d1,d2,d3,d4
...
..
magari eseguibili in 1 ciclo di clock ampliando il set dei registri base.
e cosi' via. In pratica istruzioni alla stregua dei RISC che coinvolgono 3 o
4 registri che svolgevano semplici istruzioni facili da implementare in
qualsisasi futuro sviluppo, tanto per tentare di introdurre una
innovazione.., del resto lo hanno fatto con le SIMD!

 ...questo lo si può applicare a tutti i campi della progettazione...
Non e` proprio cosi`, dato che si perde
in prestazioni.
Quindi si deve fare, come sempre, una scelta.
bye,
-- 
  Piergiorgio Sartor

 4 registri che svolgevano semplici istruzioni facili da implementare in
Non capisco, vuoi inventare il VCISC (Very Complex Instruction Set
Computing)? ;-)
x86 è nato come architettura a registri Special Purpose, è stato trasformato
in registro-memoria, ma non potrà mai diventare una registro-registro.
Introdurre istruzioni come quelle potrebbe portare ad assurde codifiche di
anche 25 byte :-D.
Un'architettura registro-memoria a 2 operandi sarà più ostica per i
compilatori di una a tre operandi, ma con 16 registri diventa totalmente
gestibile.
(e comunque, a che servirebbe madd?)
Saluti.
--
//   Xelloss da Bologna  || in real life: Wilmer Ricciotti   \\


> efficenza nelle entità che sfruttano il piano di astrazione più elevato.
--
Reply to: brain79(at)
inwind.it
www.brainetwork.net
ICQ# 
4742797710
 - FeSToso n°143

**l'indirizzamento a 2MB permesso dalla architettura 8086 sembro' all'epoca
ricordi male oppure all'epoca qualcuno si prese la briga di decodificare
gli stati del bus, in modo da ottenere 1MB per CS ed 1MB per DS/ES/SS ?

Ma in tutto questo c'č il fatto che il petrolio non sarą abbandonato
beh, prima o poi finisce, mica e' eterno...

strano procedimento?
uhm ... detta cosi' mi ricorda due sommatori non ripple-carry a 16 bit
collegati _col_ ripple-carry ... in pratica un sommatore a 32bit non
ripple-carry sarebbe troppo costoso/lento e cosi' si "pipelinizzano" le
due somme.
pero' c'e' anche da dire che non sono informatissimo sullo stato dell'arte
delle alu, quindi ...

beh, prima o poi finisce, mica e' eterno...
Vabbeh questo è un altro discorso, ovviamente gli arabi non se lo
possono inventare se non c'è ;)
Resta il fatto che le tecnologie ci sono già adesso, ma non vengono
sfruttate...


 (e comunque, a che servirebbe madd?)
madd in asm ppc sta per moltiplica e poi addiziona esempio:
a = b*c+d   --->   madd a,b,c,d
oppure
fmadd a,b,c,d se volessimo utilizzare la FPU, potente no ? (5 cilci di clock
su un PPC 604e)
Servono sopratuto per i calcoli matriciali e quindi per tutto quello che
concerne il 3d e la codifica/decodifica video&audio, PPC rulez! (e non solo
PPC..)

 PPC..)
Non è un tipo di istruzione che mi soddisfa, sulla stessa base potrei dire
che nell'elaborazione di stringhe x86 rulez...


 E perche`? Che ragione c'e` per questo strano procedimento?
Potrebbero c'entrare  la ALU  dual pumped? Forse a  pieno regime  le due
unita` lavorano in contemporanea e non interleaved.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Runtime error 6D at f000:a12f : user incompetente

 che nell'elaborazione di stringhe x86 rulez...
Si non c'è dubbio nella gestione delle stringhe gli x86 sono i migliori :-D

 Si non c'è dubbio nella gestione delle stringhe gli x86 sono i migliori
:-D
Quella volta si era convinti che un calcolatore general purpose dovesse
processare una grossa quantità di stringhe di dati...


 processare una grossa quantità di stringhe di dati...
E' comprensibile.. quando furono progettati gli 8080/86 esistevano solo
terminali con stampante e schede perforate.. se ci penso bene credo sia un
miracolo che lo 'sviluppo' di queste cpu sia arrivato fino al 2002 e abbia
sviluppato tutta questa potenza.

 mi sente per caso? Help me!.
Sia SSE che SSE2 *non* operano su vettori, operano su registri a 128bit
( XMM0 .. XMM7 da non confondere con i registri MMX0 .. MMX7).
Le istruzioni SSE prevedono sia formati "packed" in cui si opera
sugli XMM considerandoli come 4 valori floating point a 32bit "inpaccati"
nel registro, sia operazioni che operano sulla sola parte bassa
(senza alterare i restanti valori).
Le istruzioni MOV che operano sugli XMM permettono poi
di copiare la parte bassa di un XMM sulla parte alta di un altro
(anche lo setto, ovviamente).
Con SSE2 non si e' fatto altro che aggiungere un ulteriore
formato "packed" (in cui un registro XMM contiene due valori
floating point a 64bit "impaccati").
L. Micheletto

(e comunque, a che servirebbe madd?)
multiply-add ?

magari eseguibili in 1 ciclo di clock ampliando il set dei registri base.
volendo usare istruzioni a tre operandi e' piu' che obbligatorio avere un
discreto numero di registri. e sul k6-2 c'e' un buon numero di istruzioni
eseguibile in un solo ciclo (previa decodifica anch'essa molto breve).
in altre parole: volendo e' possibile usare il k6 come un risc con
istruzioni a due operandi: basta ignorare le altre...

di nicchia.
non e' proprio lo stesso: mentre una cpu alpha potrebbe costare meno di un
duron, le MB per alpha sono costruite in un modo  (e montano tutta
una serie di "accessori") che difficilmente porterebbe a costi umani,
anche nel mercato x86.

 multiply-add ?
Sě ma non mi era chiaro in che modo moltiplicava e aggiungeva.
In ogni caso non mi sembra un'istruzione geniale, ma se ce l'hanno messa
dev'esserci un motivo.


anche nel mercato x86.
tralasciando le soluzioni custom per macchine massivamente parallele,
le schede 2way sono al livello di un 760mp - hanno alcune soluzioni
interessanti (tipo i960 a bordo come controller) ma iniziano ad essere
datate... certo, cinque anni fa costavano dai dieci milioni in su,
oggi un mpx le batte per 400 euro...
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

 dev'esserci un motivo.
la multiply-add è una operazione geniale che è utilizzata moltissimo in
molti tipi si software, in pratica in TUTTI gli algoritmi di grafica 3d,
compressori audio/video, decodificatori di immagini (tipo JPEG/MPEG),
algoritmi di compressione tipo Zip, etc..
Più in generale è utilizzata tutte le volte in cui ad una moltiplicazione si
sussegue una somma e credimi i casi sono innumerevoli e le occorrenze pure.
Ovviamente il tutto su PowerPC, su x86 (ed altre cpu pure) saranno
necessarie almeno 2 istruzioni per avere lo stesso risultato.
Ci sarebbero altre istruzioni da menzionare ovviamente, ma quanto esposto
voleva solo essere di esempio di come sia limitato ed arcaico l'assembly
x86, fermo restando che comunque tutto cio' che si puo' fare con una CPU è
fattibile anche da un'altra, presupposte alcune basi, l'unico neo è la
velocità di esecuzione (macchina di Turing se non ricordo male).

 molti tipi si software, in pratica in TUTTI gli algoritmi di grafica 3d,
Non c'entra, tutti questi software rappresentano una minima parte delle
istruzioni che verranno processate, e la progettazione di una CPU in
generale, e di una RISC in particolare non dovrebbe tenerne conto. In FPU
un'istruzione del genere già è comprensibile, in ALU *NO*... Però ripeto,
chi l'ha progettata non è un cretino, quindi dietro c'è sicuramente un'altro


necessarie almeno 2 istruzioni per avere lo stesso risultato.
sarebbe interessante vedere come i due si organizzano a livello
superscalare in un caso del genere...
dubito che la madd sia un'istruzione singola sul ppc alla fin fine...


 ha scritto nel messaggio
 > news:yNaA8.45529$W9.10...@twister2.libero.it...
 > > la multiply-add è una operazione geniale che è utilizzata moltissimo in
 > > molti tipi si software, in pratica in TUTTI gli algoritmi di grafica 3d,
 >
 >
 > Non c'entra, tutti questi software rappresentano una minima parte delle
 > istruzioni che verranno processate, e la progettazione di una CPU in
 > generale, e di una RISC in particolare non dovrebbe tenerne conto. In FPU
 > un'istruzione del genere già è comprensibile, in ALU *NO*... Però ripeto,
 > chi l'ha progettata non è un cretino, quindi dietro c'è sicuramente un'altro
 > motivo.
Hai presente la storia del tizio che affogo' in uno stagno
la cui profondita' media era 10 cm ? :-)
La Sun fece una cosa simile quando realizzo' i primi Sparc senza istruzioni
di moltiplicazione (c'era solo una istruzione che eseguiva un singolo
passo di moltiplicazione) ... poi si affrettarono ad aggiungere un
moltiplicatore completo prima che fosse troppo tardi.
La multiply-add per interi serve anche quando si usano valori fixed point
(usando le ALU degli interi, non la FPU).
Ovviamente nelle cpu "generiche" la madd (sia per interi che per float)
non e' che sia cosi "necessaria" (ma se c'e', parecchio software ne puo
trarre vantaggio) ma ad esempio per i DSP le prestazioni della madd sono
uno dei parametri di riferimento per valutarne le prestazioni.
L. Micheletto

 dubito che la madd sia un'istruzione singola sul ppc alla fin fine...
In realta la MADD, o MAC, nasce nei DSP quando
il moltiplicatore HW non esisteva od era cosi`
lento da non consentire operazioni di trattamento
dei segnali, che, giusto per onor di cronaca, si
possono sintetizzare come integrali di qualcosa,
quindi somme di prodotti.
Un DSP (magari VLIW) moderno non ha piu` la MAC,
usa semplicemente due istruzioni in pipeline,
come fanno tutte le altre CPU.
Uno dei motivi e` che la MAC richiede un
registro particolare (accumulatore) oppure
un accesso multiplo ad un registro in lettura
e scrittura.
Nel primo caso si rompe l'ortogonalita`, nel
secondo si complica enormemente il registry
file della CPU (e la CPU stessa), per cui
(a volte) si preferisce soprassedere ed
usare il pipeline.
Infine, nei SW di processamento dei segnbali,
e` raro trovare una MAC da sola (che nei
DSP classici, come singola, e` pure lenta), ma
si trovano dentro loop, quindi si puo` sfruttare
a dovere la struttura superscalare.
Discorso completamente diverso per le SIMD,
dove la MAC ha senso, dato che puo` trattare
un vettore di dati, che altrimenti andrebbe
spezzato, processato e ricomposto, cosa non
auspicabile certamente.
bye,
-- 
  Piergiorgio Sartor

 uno dei parametri di riferimento per valutarne le prestazioni.
Ma certo, i DSP sono processori con istruzioni specializzate eseguite
direttamente in hardware, si capisce, ma ho problemi a capire perché sia
cosě indispensabile nelle cpu generiche ;) (il fatto che diverso software ne
possa fare uso non č una scusa, potenzialmente puň rallentare tutto il
resto).
Comunque č chiaro che se i progettisti hanno messo questa istruzione, se lo
potevano permettere...


Non è che ho capito prorio tutto del tuo doscorso ma minch.. dove le hai
prese tutte queste notizie?!? Complimenti!

 prese tutte queste notizie?!? Complimenti!
Beh, grazie.
E` un po' di tempo che gioco e lavoro
(nell'ordine) con i DSP...
bye,
-- 
  Piergiorgio Sartor

datate... certo, cinque anni fa costavano dai dieci milioni in su,
aggiornale: continuano a non avere prezzi "umani".  del resto non
hanno prezzi umani nemmeno alcune MB per server x86 ...

dev'esserci un motivo.
utilizzo a parte: spero che non si scandalizzi nessuno, ma le MMX (e/o
3DNow! /SSE etc etc) comprendono delle multiply-add ...

 genere appesantisce molto l'ALU e relativamente meno la FPU.
Non l'appesantisce troppo se la si implementa valutando costo e benefici.
Piuttosto che non avere una madd conviene persino averne una "non ottimale"
che appesantisca poco l'ALU (se proprio non si ha modo di implementare
il "sottosistema madd" come unita funzionale a parte) ma che permetta
di evitare tutta la trafila di add, mul, test e branch che si hanno
in sua mancanza.
Es: Sulle cpu H8S/2600 ("roba da embedded") l'istruzione MAC
     (multiply-accumulate) ha due operandi a 16bit ed il risultato
     della moltiplicazione viene sommato su un accumulatore a 42bit.
     In altre parole partendo con l'accumulatore azzerato, si possono
     eseguire almeno 1024 MAC *consecutive* senza controlli di overflow
     ed il check di eventuali overflow e' necessario solo dopo
     la 1024-esima.
     Implementando invece la cosa con istruzioni add e mul si perde un sacco
     di tempo a testare i bit di carry , a fare jump condizionali e ....
     ... a decodificare istruzioni.
L. Micheletto

 3DNow! /SSE etc etc) comprendono delle multiply-add ...
Lo supponevo, e le trovo perfettamente giustificate.
Saluti.
--
//  Xelloss dal portatile || in real life: Wilmer Ricciotti  \\


Estendere x86 a RISC? E' un'impresa completamente disperata...
a parte che piu' che estendere sarebbe "ridurre", su quali considerazioni
la ritieni un'impresa disperata ?

 la ritieni un'impresa disperata ?
Non si tratta solo di eliminare, si tratta di ridefinire completamente il
formato delle istruzioni, e questo non lo puoi fare senza perdere la
compatibilità.
Saluti
--
//   Xelloss da Bologna  || in real life: Wilmer Ricciotti   \\


compatibilità.
in realta' ci sono almeno due modi:
a) inserire un modo "esteso", in cui le istruzioni sono decodificate
(e magari anche prelevate) con un altro decoder. e' una soluzione usata ad
esempio dai nec v20, 25 ... che avevano un modo 8080 in cui eseguivano il
codice binario 8080. c'erano anche processori e/o controllori risc che
avevano due formati diversi di istruzione, di cui uno piu' lento da
interpretare ma piu' compatto, e cosi' via...
b) utilizzare (se c'e' ovviamente) un byte non ancora utilizzato come
"prefisso" per decodificare in modo diverso le operazioni. come lo z80 (i
prefissi per indicare l'uso di IX e IY al posto di HL ...) o i 386.
col passaggio al 386 fu fatta una cosa del genere ma con un "limite": i
prefissi indicavano si' 32 bit di dato/indirizzo ma la decodifica delle
istruzioni era coerente con le istruzioni a 16 bit (es: mov ax, [bx]
diventava mov eax,[bx]. 
e' facile capire il perche': riutilizzando parti della vecchia unita' di
controllo non si devono inserire parti nuove, che costano...
non so che hanno fatto esattamente con hammer, ma _spero_ che abbiano
fatto qualcosa di meglio

interpretare ma piu' compatto, e cosi' via...
arm (dalla versione 3 se non ricordo male) ha due modalita' di
funzionamento - modalita' arm e modalita' thumb - quest'ultima per
l'appunto con un certo hit sulle prestazioni riesce a ridurre
notevolmente le dimensioni del codice...
Strong non integra la modalita' Thumb, che e' stata reintrodotta in
Xscale.
