Newsgroup: it.comp.hardware.cpu
Titolo: cpu console a 128 bit

mi sapreste funzionare perche' le cpu delle console funzionano a 128 bit,
mentre le cpu dei computer da casa funzionano a 32 bit? quel 128 si
riferisce a qualche altra cosa?
--
Ciao
Marchese Gianfranco
e-mail dgruma@NOPUBBLICITA'
tin.it
 (Da togliere NOPUBBLICITA' se vuoi
rispondermi in privato)
sito internet personale: 
www.turbo-pascal.cjb.net
  Tutto sul Turbo Pascal
1.5

 riferisce a qualche altra cosa?
xchè sono CPU dedicate, e quindi si possono permettere anche un parallelismo
elevato.

 --
  C'è anche da dire che nelle cpu x86 per Pc esistono registri
creati per incrementare l'efficienza di esecuzione ad esempio delle
istruzioni 3D come le istruzioni SSE, i quali adottano dopotutto registri
anche a 128bit per effettuare tutto ciò.
Comunque nel campo delle consolle l'importanza della cpu è relativa,
inquanto in questi sistemi esistono più chip dedicati specializzati ognuno
ad esempio per l'audio, per la grafica 3D o altro (cosa che nel campo pc si
sta verificando solo da poco tempo grazie alle nuove gpu o a schede audio
dotate di DSP avanzati) e raramente nel descrivere le caratteristiche
tecniche di una consolle l'unità di calcolo
viene citata come elemento principale del sistema (frequenza compresa).
Ciao.

Marchese Gianfranco wrote:
 > mi sapreste funzionare perche' le cpu delle console funzionano a 128 bit,
 > mentre le cpu dei computer da casa funzionano a 32 bit? quel 128 si
 > riferisce a qualche altra cosa?
Se ti riferisci alla Playstation2 significa solo che ha dei registri
interni ed alcuni bus interni a 128bit, ma non e' niente di
particolarmente spettacolare.
Anche le cpu x86 che implementano le estensioni SSE ed SSE2
hanno registri a 128bit, senza contare le varie schede video
che all'interno della GPU (Graphic Processing Unit) hanno bus
ampi 256bit e relative ALU.
Per avere una "vera" cpu a 128bit bisogna avere come minimo
anche l'indirizzamento a 128bit.
L. Micheletto

Si certo perche sono ottimazzatissime  e non devono aspettare che Microsoft
faccia uscire la sua versione a 128 bit.
per la verità è appena uscito win XP a 64 bit
"Marchese Gianfranco" <d.g.r.u.m.a.@VediInFirma.it> ha scritto nel messaggio
news:eMeu8.14719$b62.4...@news1.tin.it...


riferisce a qualche altra cosa?
come se le consolle avessero bisogno di 128 bit di indirizzamento...
:-)
no, non esistono processori a 128bit nelle consolle, e' soltanto una
invenzione pubblicitaria - esistono delle versioni sottopotenziate a
32bit di processori originariamente a 64 (i Mips) e dei processori a
32bit con alcuni registri speciali a 128 (come e3dNow!, sse e sse2
negli x86) ed alcuni bus interni a 128.
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

 ha scritto nel messaggio
news:3ltlbuo3heccnug4p...@4ax.com...


(ps2, ecc), sono solo balle o almeno, sono state pubblicizzate troppo?
entrambe :-)
oddio, fino ai 16bit sono "veri", da li in poi bisogna un po' vedere.
come ho gia' detto molti (nintendo, ps1) montano delle versioni
ridotte dei processori Mips a 64bit in versione 32bit - e' un ottimo
processore ma ne esce decisamente castrato dalla riduzione (un po'
come un 386sx...).
se te la cavi con l'inglese fatti un giro su arstechnica, c'e'
un'analisi dettagliata della ps2 decisamente interessante.


 anche l'indirizzamento a 128bit.
E chi l'ha detto ?
Saluti, Zanza_ra

64bit in versione 32bit
Forse è vero il contrario, i Mips nascono a 32 bit e poi sono uscite
evoluzioni a 64 bit.
Saluti, Zanza_ra

 anche l'indirizzamento a 128bit.
Credo che il numero di bit si possa, in
generale, riferire alla massima lunghezza
di word processata dalla ALU e/o la
massima lunghezza di word che si puo`
trasferire con una move.
L'indirizzamento e` un'altra storia.
Per es. il 68000 che CPU era?
16/24/32 bit?
bye,
-- 
  Piergiorgio Sartor

"Piergiorgio Sartor" <sar...@sony.de.REMOVE.THIS> ha scritto nel messaggio
news:3CD150D8...@sony.de.REMOVE.THIS...

praticamente un 32 bit ma con indirizzamento max di 24 bit il 68000 del
1979..
il 68020 è un full 32 bit con un paio di istruzioni (mul e div) capaci di
gestire i 64 bit unendo 2 registri dati.
il 68060 ultimo della serie 68xxx è anch'esso un 32 bit.

 E chi l'ha detto ?
Esempio 1: Intel PIII (x86 a 32bit ma con registri XMM a 128 bit)
nessuno si sogna di chiamarlo una cpu a 128bit.
Esempio 2: AMD Opteron (indirizzamento logico a 64bit, ha pure esso
gli XMM a 128bit) ma resta una cpu a 64bit.
Di solito un cpu ad n bit ha registri GPR ad n bit
ed indirizzi "logici" almeno ad n bit.
Non c'e' una regola scritta, ma di solito per senso comune
la definizione e' questa.
L. Micheletto

Piergiorgio Sartor wrote:
 >
 > Lorenzo Micheletto wrote:
 >
 >
 >>Per avere una "vera" cpu a 128bit bisogna avere come minimo
 >>anche l'indirizzamento a 128bit.
 >
 >
 > Credo che il numero di bit si possa, in
 > generale, riferire alla massima lunghezza
 > di word processata dalla ALU e/o la
 > massima lunghezza di word che si puo`
 > trasferire con una move.
Gia con gli 8086 potevi muovere con una sola
FMOV dati a 64bit (usando la FPU) ma questo non
lo rendeva un cpu a 64bit.
Di solito il parametro migliore e' il numero di bit
dei registri GPR usati (anche) per l'indirizzamento.
Es: Con lo Z80 potevi usare indirizzi a 16 bit ma
     il singolo registro (che piu si avvicinava ad un) GPR
     era ad 8 bit.
 > L'indirizzamento e` un'altra storia.
 >
 > Per es. il 68000 che CPU era?
 > 16/24/32 bit?
Bella domanda! :-)
L' MC68000 aveva ALU a 16 bit (le istruzioni su dati a 32bit
richiedevano il doppio), AGU a 32bit (per questo in certi casi
conveniva fare le somme con le istruzioni LEA), bus dati
a 16bit e bus indirizzi a 24bit.
Comunque il modello logico era full 32bit ed a confronto
con gli 8086 ed 80286 a programmarlo in assembly era come
stare in paradiso (niente fottuti segmeti rachitici, 16
bei registri a 32bit, ecc. ecc.).
L. Micheletto

16/24/32 bit?
Direi un 32 bit con bus a 16...
Altrimenti dovremmo dire che l'8088 era una CPU a 8 bit ;)
-- 
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)

Esempio 4:
Z80:
bus dati a 8 bit, bus indirizzi (e spazio di indirizzamento) a 16
bit,registri a 8 e 16 bit, nessuno si sogna di chiamarlo un 16 bit.
Esempio 5:
motorola 68000
bus dati a 16 bit, bus indirizzi a  (e spazio di indirizzamento) 24 bit,
registri a 32 bit ed è un 32 bit
sempio 6:
Intel 386
bus dati a 32 bit, bus indirizzi a 24 bit, registri a 8, 16 e 32 bit ed è un
32 bit..
E mi fermo qui, prechè più penso ad altre cpu, più trovo eccezioni alla tua
regola (che non è ne necessaria, nè sufficiente).
Inoltre quando parli di 'registri GPR ' mi spieghi quali sarebbero in uno
Z80 (HL è GPR ? e DE ?)  e in un  (D0 è GPR ? A0 lo è ?)
Saluti, Zicus

>(le istruzioni su dati a 32bit richiedevano il doppio),
Affermazione generica e gratuita.
E poi allora il 68020 ?
Bus dati 32 bit, bus indirizzi 24 bit (incluso lo spazio di indirizzamento),
ALU a 32 bit.
Saluti, ZiCus

 lo rendeva un cpu a 64bit.
Naaa, la FPU non vale, per il semplice fatto
che *non* garantisce un trasferimento corretto.
In particolare se trova un NaN puo` trasformarlo
in un altro NaN (di default)...
Con MMX si introduce la MMOV (mi pare sia...)
a 64 bit.
Il problema di certe architetture e` l'eccessivo
uso di registri specifici, nel caso 68000 la
situazione e` molto piu` semplice, dato che tutti
i registri sono a 32 bit (compresi quelli di
indirizzamento, anche se il bus e` a 24).
Certo, il moltiplicatore e` 16x16, ma ha come
risultato 32 bit, non 16 troncati, per cui
vale ancora come 32 bit... :-)
bye,
-- 
  Piergiorgio Sartor

 ALU a 32 bit.
Il 020 non indirizzava a 32 bit?
bye,
-- 
  Piergiorgio Sartor

 Altrimenti dovremmo dire che l'8088 era una CPU a 8 bit ;)
Non lo era? :-)
bye,
-- 
  Piergiorgio Sartor

 Il 020 non indirizzava a 32 bit?
Vado a rivedere il datasheet con la piedinatura, potrei ricordare male :-(
Ciao, ZiCus

 indirizzamento, anche se il bus e` a 24).
Se non ricordo male (ne sono passati di anni dall'Atari ST :-) ), i bit
oltre il 24 nei registri Axx erano ignorati, cioč l'indirizzo 0x00FFFFFF era
perfettamente uguale a 0x08FFFFFF,
mentre per il PC non ricordo, se trovo velocemente un datasheet in rete vado
a controllare.
Ciao, ZiCus

 a controllare.
La storia e` che il *bus* ignora gli 8 bit alti,
ma ci si puo` memorizzare della roba, anche se
Motorola raccomandava di *non* farlo, per non
compromettere futura compatibilita`.
(Cosa che invece Apple ha fatto e poi si e`
trovata nelle rogne passando al 020~030).
I registri indirizzi sono full 32 bit.
bye,
-- 
  Piergiorgio Sartor

 Anche lo SP e il PC ?
Lo SP sicuramente, dato che faceva parte
degli 8 registri indirizzi.
Il PC penso anche, per motivi di compatibilita`.
bye,
-- 
  Piergiorgio Sartor

> I registri indirizzi sono full 32 bit.
Anche lo SP e il PC ?
ZiCus

Bus dati 32 bit, bus indirizzi 24 bit (incluso lo spazio di indirizzamento),
nope, dal 68020 in su compreso il bus indirizzi e' passato a 32bit -
mi pare di ricordare che ne usci' una versione economica -68ec020- con
bus indirizzi a 24bit.


perfettamente uguale a 0x08FFFFFF,
non venivano usati per l'indirizzamento ma potevano comunque contenere
dati - sull'amiga parecchi bastardi programmavano con i piedi e li
usavano "illegalmente" per risparmiare un paio di cicli, cosa che ha
creato incompatibilita' assurde con le macchine successive (ed
paradossalmente e' stato uno dei fattori che hanno portato alla rovina
di commodore... nessuno voleva comprare i computer nuovi perche' i
giochi vecchi non ci giravano.)


 tempo che una a 16bit...
Difatti, č ovvio che ci mettano di piů, perň il doppio proprio no, e poi un
minimo di giustificazione alle affermazioni.
E' come dire che un'auto da 100 Cv va veloce il doppio di una con 50 Cv ...
E poi a pensarci bene cosě ovvio non direi, qualcuno č piů ferrato di me sui
cicli di clock necessari su un 8088 per fare somme a 8 e 16 bit e mi puň
rinfrescare la memoria ?
Saluti, ZiCus

 Bus dati 32 bit, bus indirizzi 24 bit (incluso lo spazio di indirizzamento),
                                 ^^^^^^
Non e' esatto, il 68EC020 aveva bus indirizzi a 24 bit, mentre il 68020
aveva bus indirizzi a 32 bit.
-- 
Saluti
Cristian
Togliete NONTANTO per le risposte via email

 giochi vecchi non ci giravano.)
Ecco questo è il rovescio della medaglia.. in pratica hai ragione, questo ha
segnato la fine di Amiga in un certo senso ma non disprezziamo però quei
'geni' che da un povero 68000 programmando a mano (assembler) linea x linea
tutto il  codice del programma riuscivano a tenere testa ai 386/486
potenzialmente molto + performanti.

 Z80 (HL è GPR ? e DE ?)  e in un  (D0 è GPR ? A0 lo è ?)
Mii! Ma secondo te cosa significa "non c'e' una regola scritta"
e "senso comune" ? :-)
Nelle cpu tipo lo Z80 ed il 6502 non ci sono veri e propri GPR, quindi
si usa come riferimento quel che gli si avvicina di piu.
L. Micheletto


--


 altri tempi...
E allora hai vinto! :-)
Comunque anche io in passato mi sono battuto per la stessa causa e sono anni
ormai che non si utlizzano + delle simili tecniche di programmazione; la
lezione è servita credimi, ma vedere certi demo pieni di grafica in
movimento girare su 'misero' un 68000 mi fa ancora venire i brividi ed in
qualche modo apprezzo comunque lo sforzo fatto dal coder e tutto il resto
del gruppo.
In pratica è una sfida tra te e la 'cpu', e tanto questa è + lenta tanto
maggiore è la soddisfazione di aver vinto la sfida.

potenzialmente molto + performanti.
mah, un 386 (magari sx) a pari clock le prende da un "povero" 68k, se poi
tieni conto dei coprocessori audio/video ...

cicli di clock necessari su un 8088 per fare somme a 8 e 16 bit e mi può
ho sottomano i datasheet del 186/188 e non mi sembra siano dichiarate
differenze nei cicli richiesti per le varie operazioni.
di sicuro la versione ad 8 bit e' piu' lenta perche' la coda di prefetch
e' piu' breve (questo e' riportato) ed accede solo ad 8 bit alla volta.
la fregatura sta nel fatto che probabilmente i datasheet in realta' _non_
considerano l'attivita' sul bus:
* The op code, along with any data or displacement required for execution
of a particular instruction, has been orefetched and resides in the queue
at the time it is needed.
* No wait states or bus HOLD occur
* All word data is located on even*address boundaries.
[...]
All instructions wich involve memory reference can require one(and in some
cases, two) additional clocks above the minimum timings shown. This is due
to the asynchronous nature of the handshake between the BIU and the
execution unit.

Z80 (HL è GPR ? e DE ?)  e in un  (D0 è GPR ? A0 lo è ?)
i registri di uso generale, come dice il nome, sono quelli utilizzabili
dal(le) ALU, quelli che contribuiscono direttamente all'elaborazione dei
dati.
i registri per l'accesso alla memoria non contribuiscono _direttamente_
all'elaborazione, ma servono per il trasferimento dei dati da e verso la
memoria
cmq, a parte lo z80, tutti gli esempi che hai portato confermano la sua 
regola...

del gruppo.
misero 68000 un accidente, il 68000 schiaccia senza problemi i 286
(soprattutto considerando tutte le limitazioni delle implementazioni
microsoft) e pareggia con i 386 (se non ti serve la memoria
virtuale/protetta, l'assenza di mmu e' l'unico serio limite del 68000
in campo professionale - per le demo serve a poco)...


 Vado a rivedere il datasheet con la piedinatura, potrei ricordare male :-(
Sì, bus indirizzi esterno a 32 bit, corro a comprare una scatola di Acutil
:-)
ZiCus

 sviluppato per il futuro.
E poi si ostinavano a chiamare i vari Amiga, Atari ST o Megadrive come
computer/console a 16 bit ... mah ... misteri del marketing !
ZiCus

 si usa come riferimento quel che gli si avvicina di piu.
Pensavo di aver intuito cosa intendevi per registri GPR, purtroppo mi pareva
di averli identificati nello Z80 come i registri B,C e company (per il 6502
non so, non conosco a l'architettura), invece scopro che mi sbaglio.
Per favore spiegami con tue parole allora cosa intendi per "registro GPR",
non ci sarà una regola scritta, ma almeno un'idea l'avrai !
Vorrei esporti come la vedo io:  quando si parla di bus dati e indirizzi
(interni o esterni che siano), registri o accumulatori il concetto di
parallelismo è ben definito, molto più fumoso diventa quando viene portato a
livello di cpu, spesso l'attribuzione di una determinata cpu a una classe
(8, 16 o 32 ...) nasce per fini puramente commerciali, per differenziare
linee di prodotto di uno stesso produttore (o viceversa per confrontarsi con
linee di altri produttori), per permetere al tecnico di orientarsi più
rapidamente su una famiglia di cpu in base al'applicazione che deve
realizzare o più semplicemente per crearsi una immagine utile per fare
pubblicità al prodotto, come nel caso delle console da videogiochi; (in
quest'ultimo caso il concetto da comunicare è quello di un incremento di
prestazioni, non riesco a capire cosa centri quindi avere uno spazio di
indirizzamento a 32 bit piuttosto che a 128 relativamente al concetto di
aumento di prestazioni ...).
Inoltre in questo thread si nasconde un terribile qui-pro-quo, si confonde
il parallelismo del set di istruzioni con il parallelismo dell'architettura
della cpu: potrei avere una cpu con un accumulatore a 1 bit e un set di
istruzioni in grado di gestire operazioni a 8 bit (potenza del microcodice),
in questo caso non me la sentirei di parlare di cpu a 8 bit.
Saluti, ZiCus

 regola...
E dici poco ? Una tale eccezione per una regola 'non scritta'  e 'basata sul
senso comune' mi sembra più che sufficiente,
Per avere la smentita definitiva dovrei avere una cpu con:
a 8 bit e bus indirizzi a meno di 8 bit (i progettisti non sono mica dei
folli :-))) )
a 16 bit e bus indirizzi a meno di 16 bit (però ci sono alcuni dsp e i
microcontrollori)
a 32 bit e bus indirizzi a meno di 32 bit (e qui si potrebbe discutere un
po' anche se sono il primo a riconscere che pur essendo il 68000 una cpu a
32 bit con bus a 24 bit, in realtà non è possibile prenderla in
considerazione, ma questo non vuole dire che dimostri il contrario ...)
a 64 bit e bus indirizzi a meno di 64 bit (qui non so come sta messo l'Alpha
... e non saprei come considerare il Pentium che ha registri sostanzialmente
a 32 bit, eccetto registri particolari, ma ha un bus dati esterno ma 64 bit
e bus indirizzi esterno a 32 bit !)
a 128 bit e bus indirizzi a meno di 128 bit (e qui è proprio la tesi che si
vuole confutare, anche se - lo ripeto  - prima che ci sia l'esigenza di
avere uno spazio di indirizzamento fisico a 128 bit ne passeranno di lustri
...)
Questo per dire che una sola eccezione invalida la tesi, ma mille esempi a
favore non la dimostrano :-)
Saluti, ZiCus
P.S se poi passo a considerare anche cpu con architetture Harvard la
casistica aumenta ...

 computer/console a 16 bit ... mah ... misteri del marketing !
Nel caso dell'Amiga una possibile giustificazione
potrebbe risiedere nel fatto che *tutto* l'HW
custom, cioe` i vari chip per la grafica, audio,
I/O, erano a 16 bit, nessun pensiero ai 32.
Cosa che ha avuto il suo impatto, sia come
prestazioni che come costo (nel senso che era
costoso interfacciare il bus del 030 con quello
del chipset), con i vari A3000/A4000.
bye,
-- 
  Piergiorgio Sartor

ZiCus wrote:
  > > .. Z80 ...
  > > I "registri a 16bit" erano due (quasi) GPR ad 8bit appaiati utilizzabili
  > > solo con alcune istruzioni.
  >
  >
  > Erano molti di più:
  > B e C (registro BC), D e E (registro DE), H e L (registro HL) e poi XI e YI
  > e se vogliamo esagerare anche AF e tutto il set di registri alternativi. Non
  > mi sembrano solo due. Poi il fatto che permettessero solo poche istruzioni è
  > vero, c'erano comunque la somma e la sottrazione con riporto e non è che
  > l'accumulatore ne avesse molte di più ...
Io ci ho programmato in assembly sugli Z80, se permetti. :-)
A parte i due registri indice tutti gli altri erano coppie di registri
ad 8 bit, ed e' quel che ho scritto, mi sembra.
Non ho scritto "il registro", ho scritto "i registri".
Inoltre a parte che per load/store e add/sub, tutte le altre operazioni
su dati a 16bit andavano fatte passando esplicitamente per l'accumulatore
ad 8 bit (and, or, xor ecc.).
  > > > motorola 68000
  > > > ...
  > > > bus dati a 16 bit, bus indirizzi a  (e spazio di indirizzamento) 24 bit,
  > >
  >
  > > Il bus indirizzi *esterno* era a 16bit,
  >
  >
  > 24 bit
Vero, errore di trascrizione.
  > > > Intel 386
  > > > ...
  > > > registri a 8, 16 e 32 bit
  > >
  >
  > > I registri ad 8 e 16 bit sugli x86 a 32bit sono mappati *dentro*
  > > i GPR a 32bit.
  >
  >
  > Sono comunque registri ad 8/16 bit e nascono per compatibilità da
  > architetture nelle quali erano ad 8/16 bit
Quindi gli x86 dal 386 in su sono a 32bit, no ?
  > > > E mi fermo qui, prechè più penso ad altre cpu, più trovo eccezioni
  > > > alla tua regola (che non è ne necessaria, nè sufficiente).
  > >
  >
  > > Mii! Ma secondo te cosa significa "non c'e' una regola scritta"
  > > e "senso comune" ? :-)
  >
  >
  > "non c'e' una regola scritta" e "senso comune" nel tuo post erano riferiti
  > al concetto numero di bit di una cpu, non al concetto di registro GPR.
  > Se ti va le applichiamo anche al concetto di GPR, nessun problema, allora a
  > questo punto non so cosa dirti, continua a sostenere pure che "per avere una
  > 'vera' cpu a 128bit bisogna avere come minimo anche l'indirizzamento a
  > 128bit" ...
  > Secondo me prima che ci sia l'esigenza di avere cpu con spazi di
  > indirizzamento fisico a 128 bit ne devono passare di anni ...
Sul post a cui ti riferisci avevo scritto:
"
   Di solito un cpu ad n bit ha registri GPR ad n bit
   ed indirizzi "logici" almeno ad n bit.
   Non c'e' una regola scritta, ma di solito per senso comune
   la definizione e' questa.
"
  > > Nelle cpu tipo lo Z80 ed il 6502 non ci sono veri e propri GPR, quindi
  > > si usa come riferimento quel che gli si avvicina di piu.
  >
  >
  > Pensavo di aver intuito cosa intendevi per registri GPR, purtroppo mi pareva
  > di averli identificati nello Z80 come i registri B,C e company (per il 6502
  > non so, non conosco a l'architettura), invece scopro che mi sbaglio.
  > Per favore spiegami con tue parole allora cosa intendi per "registro GPR",
  > non ci sarà una regola scritta, ma almeno un'idea l'avrai !
Registri utilizzabili per la maggior parte delle operazioni
(almeno come uno degli operandi).
Per esempio HL, DE, IX, IY non sono assimilabili a dei GPR
perche supportano solo un sottoinsieme delle operazioni
possibili con A,B,C,D,E (quindi sono essi ad avvicinarsi
di piu al concetto di GPR):
Ovviamente si parla dello Z80 (una cpu dove piu che di GPR
si parla di *un* accumulatore e di altri registri di appoggio)
quindi a spaccare il capello possiamo andare avanti
fino a fine 2050. ;-)
  > Vorrei esporti come la vedo io:  quando si parla di bus dati e indirizzi
  > (interni o esterni che siano), registri o accumulatori il concetto di
  > parallelismo è ben definito, molto più fumoso diventa quando viene portato a
  > livello di cpu, spesso l'attribuzione di una determinata cpu a una classe
  > (8, 16 o 32 ...) nasce per fini puramente commerciali, per differenziare
  > linee di prodotto di uno stesso produttore (o viceversa per confrontarsi con
  > linee di altri produttori), per permetere al tecnico di orientarsi più
  > rapidamente su una famiglia di cpu in base al'applicazione che deve
  > realizzare o più semplicemente per crearsi una immagine utile per fare
  > pubblicità al prodotto, come nel caso delle console da videogiochi; (in
  > quest'ultimo caso il concetto da comunicare è quello di un incremento di
  > prestazioni, non riesco a capire cosa centri quindi avere uno spazio di
  > indirizzamento a 32 bit piuttosto che a 128 relativamente al concetto di
  > aumento di prestazioni ...).
Perche lo spazio di indirizzamento (lineare) e' fortemente correlato
al resto delle prestazioni, per questo avevo scritto che una cpu ad N bit
deve *almeno* supportare indirizzi "logici" ad N bit (anche se magari
poi per ragioni di convenienza gli indirizzi fisici vengono troncati).
  > Inoltre in questo thread si nasconde un terribile qui-pro-quo, si confonde
  > il parallelismo del set di istruzioni con il parallelismo dell'architettura
  > della cpu: potrei avere una cpu con un accumulatore a 1 bit e un set di
  > istruzioni in grado di gestire operazioni a 8 bit (potenza del microcodice),
  > in questo caso non me la sentirei di parlare di cpu a 8 bit.
Il parallelismo interno c'entra fino ad un certo punto, basta
che il modello visibile al programmatore sia ad N bit, non importa
come viene implementato, altrimenti come definiresti
il Pentium 4 con le sue ALU a 16bit a double data rate ?
Se il set d'istruzioni ti permette di vederla "logicamente" come
una cpu ad 8bit, la si puo anche definire tale.
Per esempio la Hitachi classifica la famiglia di cpu H8/300H come
cpu a 16bit perche ha le ALU a 16bit ed e' l'evoluzione
delle H8/300 (che sono veramente a 16bit), ma per un programmatore
e' una cpu a 32bit e la si usa come tale e la differenza rispetto
ad una cpu "veramente a 16bit" la si vede eccome (non appena si
superano i 64KB di spazio di memoria o si devono manipolare
molti valori a 32bit).
L. Micheletto

a 32 bit e bus indirizzi a meno di 32 bit (e qui si potrebbe discutere un
i PDP 4/7/15/18 avevano registri di 18 bit e da 13 a 17 linee di
indirizzo, mentre i PDP-10 avevano registri di 36 bit e indirizzi di 18.

Non lo era? :-)
Beh, è questione di punti di vista ;)
-- 
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)