Link alla notizia: http://news.hwupgrade.it/11678.html

IBM ha effettuato il tape out di alcuni sample di processori a 65 nanometri, destinati all'impiego con le console di gioco di prossima generazione

Click sul link per visualizzare la notizia.

Per lavorare a East Fishkill venderei la mamma del mio migliore amico (e il padre a contratto stipulato)

CPU per console a 64 bit?
Ma la ps2 non è 128?

infatti.
C'è un errore?

umh ma a questo punto i giochi xbox non saranno compatibili xbox2...

potrà superare la soglia dei 3ghz e avvicinarsi a quella dei 5ghz...sembra un poco esagerato, o sbaglio? è vero che si parla di 0.65 nanometri ma...

Io penso che il bello delle consol era che puoi giocare con un gioco per un sacco di tempo(vedi playstation1)...ma adesso le si stanno aggiornando piu velocemente di un pc... a questo punto continuo a giocare con un pc almeno ho la retro compatibilità!!!

Originariamente inviato da ErminioF
CPU per console a 64 bit?
Ma la ps2 non è 128?

Originariamente inviato da Prova
infatti.
C'è un errore?

Per quel che ne so il chip grafico è a 128 bit non la CPU che comunque è ancorata a 32 bit.Conferme? ;)

Si ma si parla di 2005-2006 per la loro uscita...non domani :)
Ancora un paio d'anni di vita ce li hanno.
Cmq strano, prima ogni console era un mondo a parte, ora ps3 e xbox2 avranno la cpu prodotta da ibm...e nintendo?

nintendo non farà più console

Cpu a 128bit sulle console? Ma per piacere :D

cpu a 128 bit?
anche per quanto ne so io i 128 bit sono sono per l'emotion engine della ps2, ma la cpu dovrebbe essere ancora una 32bit...

Originariamente inviato da nonikname
Per lavorare a East Fishkill venderei la mamma del mio migliore amico (e il padre a contratto stipulato)


:rotfl: :eheh:


Cmq 0.065 micron....impressionante! :eek:

Originariamente inviato da ErminioF
Si ma si parla di 2005-2006 per la loro uscita...non domani :)
Ancora un paio d'anni di vita ce li hanno.
Cmq strano, prima ogni console era un mondo a parte, ora ps3 e xbox2 avranno la cpu prodotta da ibm...e nintendo?

Non è esatto: la notizia dice che "utilizzeranno per i microprocessori tecnologie sviluppate da IBM". E comunque, anche se fosse, se Sony progetta da sé la propria CPU e poi la fa costruire a IBM, non ci soo problemi di sorta (non ce ne sono comunque).

Originariamente inviato da nonikname
Per lavorare a East Fishkill venderei la mamma del mio migliore amico (e il padre a contratto stipulato)

:D :D :D
io mi accontenterei di lavorare alla stm...;)

il "vetusto" Sega Dreamcast monta Cpu Hitachi SH4 128bit Risc, mi sbaglio ??!

Mi sembra di ricordare che cpu del Dreamcast sia un Mips R4x00, decisamente a 32bit. Cpu a 128 bit nel senso che intendiamo noi non se ne vedono ancora!

Il software è a 32Bit ma qualsiasi CPU dal Pentium in su presenta registri più grossi, 64Bit come minimo x la virgola mobile a singola precisione, ottenuti al max con l'unione di 2 registri x gli interi x risparmiare sul silicio. Estesa è a 80 bit e doppia 128, e ormai questo tipo di calcoli lo fanno tutti...
X le GPU siamo ancora più avanti ma alla fine l'indice mogliore credo sia dato dai Bit del SW che viene fatto girare...

La CPU della playstation2 (nell'Emotion Engine) è un core MIPSIII a 64bit con un set di istruzioni esteso per gestire i suoi coprocessori (unità vettoriali a 128bit).

I registri x86 per gli interi sono registri a 32bit, il subset di istruzioni x87 (FP) prevede l'utilizzo di registri a 80bit

A questi registri sono affiancati (in realtà non so se sono gli stessi estesi o ci sono operazioni di register renaming interni, le mie conoscenze non arrivano a questi livelli) i registri MMX e 3Dnow/SSE/SSE2 a 128bit.

Aggiungo che l'obiettivo di Intel (e AMD) è di far abbandonare progressivamente l'uso dell'x87 in favore delle SSE/SSE2 per le operazioni floating point. Infatti l'estensione dei registri da 8 a 16 nella modalità x86-64 è prevista per le operazioni intere, MMX, 3DNow/3DNowEX/SSE/SSE2 e NON per il set di istruzioni x87.

Aggiungo una domanda, ma oltere gcc esistono compilatori x86-64 prodotti da AMD o dorme come al solito?

I processori mips serie r4x00 sono a 64bit dall'r4400.

Le cpu per console derivate da cpu per computer sono quasi sempre castrate per ridurre i costi, soprattutto della componentistica accessoria.

Toppa.....l'R4200, o meglio una versione custom e' contenuto nel N64 ed e' un full 64 bit!!
La dreamcast contiene un Hitachi Sh4 a 128 bit!!!
In piu' L'Emotion Engine funziona anche da unita' centrale oltre che da Processore grafico!!! Percio' se andiamo a tirare le sommme le vere Console a 128 bit sono la Ps2 e la DC....Il Cubo ha un 64bit risc e l'Xbox un p3 castrato (o celeron vitaminizzato fate voi) a 32 bit!!! Insomma i "bit" dell'unita' centrale non dimostrano la potenza della console...e' il comparto grafico a determinare la piu' potente!!!

volevo precisare che EE della ps2 e' quello che un tempo poteva definirsi un VeryLargeSystemIntegrate tra le cui parte c'e' anche un core Mips4400 con registri a 64bit

volevo fare un appunto su chi ha scritto che i registry FP sono a 80 bit e 128bit e' assolutamente falso! andatevi a laggere i documenti IEEE che trovate all'universita' in qualunque corso di microelettronica e architettura digitale!!!

i registry FP sono tutti a 80bit! di questi 80bit
vengono sfruttati 32bit per i calcoli in singola precisione + 8 bit per l'arrotondamento

64bit per i calcoli in doppia precisione + 16 bit per l'arrotondamento

preciso che questo e' standardizzato fin dalla fine degli anni '80 e quindi tutte le unita' FP seguono tassativamente questo standard.

le istruzioni SSE/MMX sono instruzioni che vengono mappate sugli stessi registri FP a volte strutturati a coppie per i calcoli a 128bit
e non possono svolgere gli stessi compiti delle unita' FP semplicemente perche' hanno metodi di approssimazioni differenti e non standardizzati quindi sono certamente piu' performanti ma altrettanto meno precisi nei conti....

per quanto riguarda l'IBM i suoi centri di ricerca sono ai massimi livelli tecnologici e le architetture VLSI permetterano di infilare cpu e memory management cache e geometry engine in un unico package come avviene per la EE della PS2 e chissa' cos'altro quei maghi degli ingegneri IBM riusciranno a infilarci....

a tal proposito voglio ricordare che ho giusto montato una scheda grafica con chip IBM GT10000 full OpenGL compliant e devo dire che nonostante i 120mhz di clock rulla alla grande non oso immaginare la stessa architettura clockata a 3ghz con una connessione diretta alla cpu' senza passare per il bus pci.....

brrrr.....a volte mi chiedo se l'architettura dei nostri pc non vada rottamata immediatamente....

Calma, hai in parte ragione.

Prima di tutto non ho MAI detto che i numeri floating point siano in un formato diverso dai 32 bit.
Secondo che i registri FP siano tutti a 80 bit è una cosa che dici tu. Lo saranno quelli x87.

Chiariamo alcune cose.
Una cosa è il data type per i dati floating point a singola precisione definito dallo standard IEEE 754, ALTRA cosa sono i registri che vengono implementati.
Lo standard dovrebbe essere (se non ero) non 32+8 bit, ma 24 di cifre significative + 8 di mantissa.

Le SSE sono istruzioni SIMD che manipolano vettori a 128 bit quindi a singola precisione 4 dati da 32, e utilizzano 8 registri a 128 bit (nn ho mai capito perchè intel si è intestardita su 8 registri) SEPARATI da quelli MMX/x87.

Quanto alla progressiva sostituzione dell'x87 devo aver letto un articolo sull'argomento ma adesso nn mi sovviene nulla, proverò a fare qualche ricerca. Certo è che se AMD nn estende i registri x87 e Intel insiste ad aggiungere nuove istruzioni qualche motivo c'è, nn credi? :)

Aggiungo che sulle 3dNow MMX hai perfettamente ragione, quelle condividono i registri x87

Il nes64 ha un r4300, ma tutta l'architettura e' castratissima. Oltretutto i veri mips 64bit sono gli r10k.
L'hitachi di cui parli ha tutt'altro che registri a 128bit, ma a 32bit.
Se la ps2 integra un core mips, come puo' avere i registri a 128bit?
Penso si tratti anche in questo caso di un core a 32bit.
Che senso avrebbe usare registri a 64bit in una console?

infatti i 1 bit per il segno 23bit per le cifre + 8 bit di mantissa
in piu' c'e' il passaggio ai numeri denormali...
gli altri 8 bit sono necessari quando il computer deve decidere come approssimare l'ultima cifra utile, in questo caso entrano in gioco gli altri 8bit che non fanno parte dello standard IEEE754 dei numeri, ma che garantiscono una forma di approssimazione che lo standard richiede. questi 8 bit non sono in alcun modo usabili o manipolabili dall'utente.
esistono diversi algoritmi in matlab che permettono di provare e sperimentare quello che dico basta fare una ricerca in google
in generale si vede che 2 numeri aventi medesime cifre FP vengono considerati diversi proprio perche' calcolati dal processore con metodi di arrotondamento diversi.
aggiungo che la maggior parte dei produttori utilizzano lo standard in modo che software come matlab possa funzionare in modo coerente su architetture diverse...
questa ovviamente puo' essere un procedura violata in processori per video game dove sono richiesti altri standard di calcolo

Processori a 128 o più bit NON ESISTONO. Non nell'accezione classica del termine, ossia dotati di ALU e registri general purpose di questa dimensione.
I 128 bit vengono tirati fuori per le unità SIMD, che sono in grado di manipolare queste quantità di dati, ma che eseguono dei compiti ben precisi. Sono un'AGGIUNTA all'architettura della cpu, che è sempre a 32 o 64 bit.
Fine discussione.

Ragazzi, allora forse non mi sono spiegato bene io.

Non ho MAI detto che l'EE abbia una architettura a 128 bit. Ho detto (RIPETO) che al core MIPS si affiancano UNITà VETTORIALI a 128 bit.

Se proprio volete saperla tutta allora:

L'emotion engine ha una CPU basata su architettura MIPS III con 2 ALU per gli interi a 64 bit, 32 registri generale purpose a 128 bit e un coprocessore FPU. A questo si aggiungono 2 unità vettoriali, di cui una può lavorare parallelamente alla CPU (VU0)
Perchè usare registri a 128bit? Semplice, le due ALU (a 64bit) possono lavorare PARALLELAMENTE oppure COME UNITA' SIMD (+o- come le istruzioni MMX) che operano su vettori a 128bit (quindi 16 a 8bit ops/ciclo fino a 4 a 32bit ops/ciclo).
Per implementare queste funzioni (anche le operazioni SIMD delle unità vettoriali) Toshiba ha ovviamente implementato delle estensioni all'architettura MIPS del processore (le estensioni di cui parlavo nel mio primo post).
Il coprocessire FPU è una unità classica dell'architettura MIPS (32bit, una FMAC e una FDIV).
Le due unità vettoriali, diciamo in maniera generale che sono unità SIMD/VLIW, agiscono su pacchetti di dati a 128bit (famo 4x32bit o sennò ci si confonde) e hanno 4FMAC, 1FDIV e altre cosette. Le differenze sono che la VU0 può essere vista dal programmatore come parte integrante della CPU (come fosse un coprocessore) mentre la VU1 ha alcune cose aggiuntive (come 1FMAC e 1FDIV in più per alcune operazioni geometriche).

Per quanto riguarda le SSE stessa storia, unità vettoriali 4x32bit.

Originariamente inviato da falcon.eddie
Per quel che ne so il chip grafico è a 128 bit non la CPU che comunque è ancorata a 32 bit.Conferme? ;)

Sono definiti erroneamente a 128 bit, ma tutte le CPU delle console attuali sono a 32 bit (si calcola sulla dimensione del bus indirizzi e non dei registri interni).

La PS2 è l'unica console che si potrebbe considerare almeno parzialmente a 128bit, anche se HIMO il concetto di console "a bit" ormai non vale più come una volta quando c'era solo un procio a fare praticamente tutto.

Il core dell'EE contiene si' la tecnologia dei MIPS ma customizzata da sony ed in numero di due unità correlate strettamente fra di loro.
In parole povere ha due alu a 64bit, che possono lavorare realmente in parallelo per alcuni tipi di istruzioni,
come quelle di load/store.

Fonte:

Link (http://www.arstechnica.com/reviews/1q00/playstation2/ee-4.html)

@fek
Un cpu a TOT bit è una cpu che può eseguire instruzioni a TOT bit, gli 8086 ad esempio sono cpu a 16 bit e non a 20bit (larghezza bus indirizzi) ;)

Alla fine poi che se ne fà una console di un bus indirizzi da 128bit??? già i 4GigaByte indirizzabili con 32 bit sono un'enormità!

Non mi trovi d'accordo: in base a cosa puoi dire che la PS2 è "parzialmente" a 128 bit?
Ripeto, io considero una cpu a "n" bit quando presenta registri general purpose a "n", e la ALU è in grado di eseguire operazioni a "n" bit. Con registri gpr mi riferisco sia ai registri dati che a quelli indirizzi, ove presenti. Ove non presenti, mi riferisco alla CAPACITA', per un registro, di generare indirizzi a "n" bit per l'accesso alla memoria.
Con ciò mi va stretta anche la definizione di fek :). Il 68000 era un processore con registri dati e indirizzi a 32 bit, ed era in grado di eseguire spostamenti, operazioni aritmetiche e logiche, ecc. a 32 bit. Purtroppo, per il solo fatto di presentare un bus dati esterno a 16 bit è sempre stato considerato a 16 bit. :rolleyes:
Un appunto: le console non sono tutte a 32 bit. Il Nintendo64, con la sua cpu MIPS R4400, è a 64 bit per i motivi di cui sopra (che poi l'implementazione interna dei 64 bit sia un po' "penosa", è un altro discorso. ;))

Io più di così nn riesco a spiegarmi :D
Penso di aver detto cose giuste
Se nn mi avete capito, pazienza :D

Originariamente inviato da cdimauro
Non mi trovi d'accordo: in base a cosa puoi dire che la PS2 è "parzialmente" a 128 bit?
Ripeto, io considero una cpu a "n" bit quando presenta registri general purpose a "n", e la ALU è in grado di eseguire operazioni a "n" bit. Con registri gpr mi riferisco sia ai registri dati che a quelli indirizzi, ove presenti. Ove non presenti, mi riferisco alla CAPACITA', per un registro, di generare indirizzi a "n" bit per l'accesso alla memoria.
Con ciò mi va stretta anche la definizione di fek :). Il 68000 era un processore con registri dati e indirizzi a 32 bit, ed era in grado di eseguire spostamenti, operazioni aritmetiche e logiche, ecc. a 32 bit. Purtroppo, per il solo fatto di presentare un bus dati esterno a 16 bit è sempre stato considerato a 16 bit. :rolleyes:
Un appunto: le console non sono tutte a 32 bit. Il Nintendo64, con la sua cpu MIPS R4400, è a 64 bit per i motivi di cui sopra (che poi l'implementazione interna dei 64 bit sia un po' "penosa", è un altro discorso. ;))

Bè, parzialmente perchè esegue delle istruzioni a 128bit, possiede registri general purpose a 128bit, tutti i bus dati sono a 128bit (unica eccezione quello delle alu che è suddiviso in due da 64).
Avrei detto che era completamente a 128 bit se avesse avuto un'alu a 128 bit :)
Nel caso della play le due alu possono eseguire solo certe operazioni a 128bit.

Quello degli indirizzi a dire il vero non so' di quanto sia (presumo a 64 ma anche 32 sarebbe indifferente), ma anche se fosse a 128 bit a cosa servirebbe? nemmeno se mettessimo in parallelo tutte le ram esistenti al mondo riusciremmo anche solo ad avvicinarci ad utilizzarlo completamente:
2^128 = 340 miliardi di miliardi di milardi di Gigabyte :eek:

@ B|4KWH|T3 secondo mè sei stato chiarissimo e mi trovo daccordo con te!

l'architettura PowerPC!wowwissimo

Attenzione, ripeto: le ALU del core MIPS sono 2 a 64bit e possono fungere come unità a 128 bit MA SEMPRE SIMD. Cioè il vettore è a 128bit e ciò significa che può essere fatto da 16dati a 8bit, 8 a 16bit, 4 a 32bit. Stesso discorso per unità vettoriali quali VU0/VU1/SSE/3dnow/SSE2/AltiVec

NON VUOL DIRE CHE HA UNA ARCHITETTURA A 128bit, almeno non nel senso in cui intendiamo che MIPS/Athlon64 sono a 64bit o che AthlonXP/P4 sono a 32bit!

Dipende da cosa si intende per "processore a tot bit"

Perfettamente d'accordo e sei stato chiarissimo (anche prima, ma siccome si continuava sullo stesso punto, ho preferito ribadire la mia). ;)

x ripsk: vedi messaggio di B|4KWH|T3. Anche con le SSE è possibile fare qualche calcolo a 128 bit, ma non per questo possiamo definire i P4 dei processori a 128 bit (anche solo parzialmente).

E' vero che non esiste nessuna definizione formale di architettura a "n" bit, e che bisognerebbe mettersi d'accordo, ma continuo a sostenere la mia tesi: da più di vent'anni programmo in assembly, e l'esperienza mi porta a sostenere a spada tratta quanto scritto sopra.

x Dragunov: non perdi occassione per continuare a spammare. :rolleyes: