Newsgroup: it.comp.hardware.cpu
Titolo: Processori per palmari

Salve,
 mi sto informando sulle CPU per i PDA e purtroppo in rete non ho
trovato molto,
almeno in italiano.
In particolare mi interesserebbero dei benchmark o degli articoli
tecnici tra il Sony iMXL a 200 MHz usato nel Sony Cliè TJ 27 e il
Texas Omap a 126 MHz usato nel Palm Tungsten E.
Sarebbe anche interessante sapere come si comportano le due CPU
summenzionate confrontate con l' Intel Xscale a 400 MHz, che è l'
unico di cui ho trovato un po di roba sul Web.
Sarei tentato di basarmi solo sulla frequenza di clock, ma sono sicuro
di sbagliare, visto che quando era appena uscita la prima versione del
Xscale a 400 MHz seguivo il mondo dei palmari e molti acquirenti
lamentavano che nell' uso con le applicazioni non ottimizzate fosse
simile o addirittura più lento del precednete ARM a circa 200 MHz
usato negli iPaq.
Ringrazio chiunque mi saprà dare quallche indicazione.


appunto.
-- 
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Il segreto per essere considerato un creativo sta nel non fare
    mai riconoscere le proprie fonti [A. Einstein]


E sicuramente non č una cosa da buttare via questa caratteristica...;-)
Se non erro Xcale č in grado di "spegnere" le sezioni che non
vengono sfruttate durante un eventuale elaborazione.
Saluti

vengono sfruttate durante un eventuale elaborazione.
ormai lo fanno tutti :)
soltanto i vecchi strongarm (che e' un progetto digital decisamente
vecchio) non avevano queste funzionalita' di risparmio energetico.
per il momento il processore embedded con la maggiore potenza di
calcolo (almeno in questo campo) e' l'xscale, ma vista la tendenza sul
fronte x86 (efficeon, geode , le versioni piu' estreme dei via) non mi
stupirebbe molto se nel giro di un paio di generazioni le macchine x86
si fagocitassero pure questo segmento.
sarebbe un peccato perche' le ultime evoluzioni dell'ISA inventata da
Acorn per il suo Archimedes sono davvero spettacolari...


 Acorn per il suo Archimedes sono davvero spettacolari...
Interessante, per esempio?
Che tu sappia non esistono incarnazioni PowerPC per il segmento PDA?
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004 


Cos'hanno di particolare?
Saluti

 Acorn per il suo Archimedes sono davvero spettacolari...
???
C'è qualcosa che non mi torna...
Ma l'Acorn Archimedes non era un vecchio computer?
http://www.old-computers.com/museum/computer.asp?st=1&c=75
 


Si, come cpu utilizzava la prima versione della cpu ARM
(ad 8Mhz) e risultava essere piu potente della maggior parte
degli x86 allora in circolazione, se ricordo bene come
potenza di calcolo superava agevolmente i 286 a 12Mhz.
L. Micheletto

 si fagocitassero pure questo segmento.
Fortunatamente gli ARM hanno ancora qualche vantaggio
in termini di potenza_di_calcolo/potenza_dissipata.
Con x86 "risparmiosi" forse si creera' un segmento di
"palmtop x86" ma IMHO ci sara' sempre una fascia piu compatta
(oppure smartphone) basata sugli ARM.
L. Micheletto


wrote:

certo, l'acorn e' stato il primo computer "economico" a montare un
processore risc: l'Acorn Risc Machine (poi rinominato in Advanced Risc
Machine) -  A.R.M.
e gli attuali processori embedded piu' diffusi in assoluto (strongarm,
xscale, samsung, TI/omap ecc...) sono tutti basati su architettura
ARM.
l'architettura arm e' uno dei piu' classici risc che ci siano,
richiede un numero ridottissimo di transistor (arm 6 del '91
richiedeva qualcosa come 35.000 transistor, confrontalo con gli altri
processori dell'epoca... o anche soltanto con un motorola 68000... :),
ha un set di istruzioni ridotto ma estremamente efficiente e
soprattutto -denso- (ovvero pochissimo overhead sul bus) ed e' pure
molto efficiente.
all'epoca dell'archimedes come potenza di calcolo non c'era niente di
paragonabile, si mangiava i 68000 a colazione - peccato che il
marketing acorn fu talmente pessimo da affondare questo piccolo
gioiello.
ai tempi attuali si e' scavato un mercato enorme in campo embedded
grazie alla sua estrema modularita' (prendi un core arm, agganciaci il
modulo che preferisci - ram, dsp, io, quello che vuoi e mettilo in
produzione) ed ad alcune evoluzioni (ad esempio la modalita' thumb,
ovvero un subset del set di istruzioni "compresso" a 16bit per
aumentare ulteriormente la densita' del codice in situazioni di
memoria ultraridotta), in pratica il 99% dei palmari oggi in
circolazione monta derivati arm, quasi tutti i lettori mp3 montano
arm, moltissimi set-top-box, cellulari, schede evolute...


 potenza di calcolo superava agevolmente i 286 a 12Mhz.
Sicuramente era piu` veloce, anzi l'assembler per essere un RISC era anche
abbastanza evoluto, mi piaceva anche se non ho mai fatto una applicazione
"seria" per quella CPU, il problema e che non esisteva software almeno nel
1987, l'architettura x86 era sicuramente la peggiore dell'epoca, il Dragon32
aveva il Motorola 6809 precursone del 68K con un set di istruzioni
"ortogonale" invece che l'orribile asimettrico assembler 8086, poi l'Acorn
e` stata acquistata da Olivetti e l'archimedes e` morto, ma ti assicuro che
all'epoca era la potentissima macchina dei sogni. Comunque oggi i nipotini
dell'ARM sono molto ambiti nell'industria, e quando qualche periferica come
scanner, stampanti laser sono gestiti dall'ARM significa che hanno un
processore molto potente.
Giovanni
www.tiburcc.com

 molto efficiente.
Denso significa quindi che c'è pochissimo overhead sul bus? Bene, mi manca
solo da sapere cos'è l'overhead :-)
Giovanni invece ha parlato di un set di istruzioni "ortogonale"... che
significa?
MaxArt

 significa?
Ti rispondo io, se Maurizio non si offende :-)
Un set di istruzioni per essere defino "ortogonale" deve avere come
caratteristica che le istruzioni che hanno come operatore un registro,
devono poter avere come operatore un qualsiasi registro, ovvero non ci
devono essere registri dedicati a talune funzioni, di solito si distinguono
subito, se i registri vengono chiamati r0,r1....rx allora il set di
istruzioni e` ortogonale, se invece si chiamano a,b,x,y o ax,bx,cx allora il
set di istruzioni non e' ortogonale, ad esempio nel mitico Rockwell 6502 che
equipaggiava apple2 e i c64  il registro a era l'accumulatore ed i registri
x,y erano gli indici esiste adc #5(addiziona #5 all'accumulatare con il
riporto), ma non esiste l'addiziona al registo x o y poiche' non erano degli
accumulatori, invece se torniamo all'assembler dell' ARM l'istruzione era
add r0, r1, r2  che somma il contenuto dei registri r1 e r2 ed il risultato
lo mette nel registro r0 ovviamente esiste anche add r2,r1,r2 e qualsiasi
altra combinazione, non solo in effetti il formato della add e' piu
complesso ovvero add(cond) ovvero la addizione se la condizione e'
soddisfatta, quindi esiste la addcs ovvero addiziona se il riporto e`
settato, il suo opposto addcc addiziona se il riporto non e` settato, per
addizionare incondizionatamente esiste la addal (al = always = sempre), ed
ovviamente esiste la addnv (nv = never = mai) che e` l'equivalente di una
nop (no operation). Nel set x86 originale i registri erano dedicati uno
faceva da contatore, uno da indirizzo di segmento etc, poi nella loro
evoluzione 186, 286, 386, 486 il set di istruzione e` stato
"ortogonalizzato" ed da CISC e` diventato RISC, a proposito tempo fa c'e`
stato un lungo thread "RISC vs CISC" su cui neanche la definizione dei due
acronimi era accettata, io ti ripeto la mia, anche se diciamo di minoranza,
ma cosi` mi ricordo dall'epoca in cui ancora si usavano i CISC :
I processori RISC sono quelli che eseguono qualsiasi istruzione (non
eccezionale come la STOP o la SWI) nello stesso numero di cicli, invece nei
CISC dove le istruzioni sono complesse il tempo di esecuzione varia a
secondo della istruzione.
Giovanni
www.tiburcc.com

Ti rispondo io, se Maurizio non si offende :-)
io mi sono occupato delle altre domande :)


solo da sapere cos'è l'overhead :-)
il problema piu' tipico dei risc e' che richiedono un gran numero di
istruzioni per eseguire un dato compito, hanno il vantaggio di
eseguire queste istruzioni in maniera estremamente veloce pero'
ovviamente questo gran numero di istruzioni lo devi leggere nella
memoria e trovargli posto nella cache, il che vuol dire che per
mantenere le pipeline piene servono delle cache molto grosse e ram
molto veloci (cosa che era, ad esempio, il piu' grosso problema dei G4
nelle implementazioni di Apple, dove venivano accoppiati con un bus
verso la memoria ridicolamente stretto che ne castrava pesantemente e
potenziali prestazioni).
piu' e' denso il set di istruzioni (meno istruzioni sono richieste per
eseguire una routine) minore e' l'impatto di questo problema.
con la modalita' thumb sono arrivati all'estremo, in pratica usano una
specie di vliw inversa, nella quale piu' istruzioni sono accorpate
insieme per ottimizzare al massimo il trasferimento da/a la memoria e
poi "scompattate" nei registri, c'e' una certa perdita di prestazioni
ma le richieste sul fronte bus/memoria sono bassissime (e quindi
eccellenti nelle situazioni dove le risorse disponibili sono
minimali).


e` stata acquistata da Olivetti e l'archimedes e` morto, ma ti assicuro che
credo che acorn fosse gia' di olivetti da prima del lancio di
archimedes, almeno un paio di anni prima.


 archimedes, almeno un paio di anni prima.
No, almeno non pubblicamente, si e' diffusa la notizia che l'Olivetti aveva
comprato la Acorn, operazione puramente finanziaria, quando gia` smanettavo
von l'ARM.
Giovanni
www.tiburcc.com

 clock (hanno gia' passato i 700mhz), e consuma molto poco.
Sě, il mio arriva a 700 in oc .
E regge bene giocandoci ai gioki seri .
A 750 perň si pianta .

 "seria" per quella CPU
Neppure io ci ho potuto mettere le mani sopra, ma conoscendone l'assembly
e memore delle precedenti esperienze con Z80, 8086 e 68000
la prima volta che ho letto un articolo dettagliato sulle cpu ARM
ho avuto l'impressione di trovarmi davanti alla cpu ideale.
Sebbene sia classificata come RISC, IMHO l'ARM originale era
una cpu "progettata per fare bene il suo lavoro" con progettisti
che conoscevano bene come bilanciare teoria e pratica, era RISC
dove aveva senso e senza sacrificare le prestazioni alla teoria.
Per esempio l'esecuzione condizionale di *tutte* le istruzioni
potrebbe sembrare una cosa "poco RISC" ma per il target
iniziale che avevano, costava poco e dava un ritorno in
prestazione decisamente micidiale.
Basta pensare che rendeva conveniente utilizzare l'equivalente
di "jump brevi" implementati come operazioni condizionali, il costo
per "jump breve" (trasformato in una singola istruzione condizionale)
era praticamente uguale sia che avvenisse e sia che non
avvenisse e richiedeva circa 1/4 del numero di cicli richiesti
per codice equivalente eseguito su una cpu tipo x86.
Adesso con tutta l'enfasi sull'esecuzione superscalare
l'esecuzione condizionale non fornisce tanti vantaggi, ma con un
approccio diverso (tante pipeline single-issue che condividono
un pool di ALU e FPU) si potrebbero realizzare dei chip basati
su ARM con prestazioni elevatissime quando operano su piu task/thread
e con codice "semplice" (praticamente niente loop unrolling, quindi
codice molto piu compatto rispetto a quello ottimizzato prodotto
con i compilatori attuali).
L. Micheletto