Link alla notizia: http://www.hwupgrade.it/news/cpu/arm-non-ha-paura-di-intel_25439.html

Il CEO di ARM Holdings esprime la propria solida fiducia nelle capacità dell'azienda. "Intel non ci fa paura" afferma Warren East

Click sul link per visualizzare la notizia.

Ottimo, un po' di concorrenza è sempre positiva.

Perchè non fanno una docking station dotata di tastiera estesa e schermo da 10'' per i PDA? Così uno si porta dietro il PDA, la docking station e ha già un portatile decente per navigare in internet e un po' di produttività personale. Con i processori Atom poi verrebbe fuori una cosa discreta.

Arm si deve svegliare altrimenti intel se la magna in un sol boccone..
Arm non dormire deve presentare nuovi prodotti o sarà infilata in un mercato di nicchia..
Altro che concorrenza qui c'è la catena alimentare..

"un settore nel quale non operiamo in modo proattivo" ah questo linguaggio di marketing :D

ne ho scritto giusto un'oretta fa sull'articolo relativo alla cpu di nvidia su appunti digitali... al di là delle dichiarazioni di intel, imho rilasciate per secondi fini (tastare il terreno e far salire le proprie azioni sono le prime due che mi vengono in mente, la terza è il solito dirigente che non capisce un cazzo e parla a vanvera), l'atom va a coprire una fetta di mercato precedentemente quasi completamente scoperta, ovvero quella che sta tra i processori per cellulari / pda e i processori per desktop. questo segmento di mercato prima del fenomeno EEE era molto poco interessante (UMPC, elettronica embedded e poco altro), mentre adesso lo è ed eccome... e per intel proporre una cpu piccolissima (47 milioni di transistor) e quindi estremamente economica da produrre, contro il circa 3 volte più grosso celeron m, significa abbattere i costi ad un terzo mantenendo bene o male gli introiti attuali. poi certo, che l'atom possa andare bene anche in umpc, pc embedded o altre applicazioni è fuor di dubbio; va bene per il suo segmento, che non è quello dei cellulari: basta vedere il chipset che accompagna l'atom (oltre al suo tdp) per rendersene conto.

ricordiamoci inoltre che intel produce già gli xscale (che sono arm), la prima azienda a cui farebbe concorrenza è sè stessa.

Spero che quello schifo di X86 non conquisti anche il mercato dei palmari e dei dispositivi embedded.
Sarebbe la feccia che risale dal pozzo....

Spero che quello schifo di X86 non conquisti anche il mercato dei palmari e dei dispositivi embedded.
Sarebbe la feccia che risale dal pozzo....

Perchè !? I Mac sono moooolto migliorati da quando sono X86... soprattutto in stabilità! (ironico... moooolto ironico! ;) ;) )

??
Perchè tanti problemi con x86?
Un palmare x86 è un pc a tutti gli effetti, altro che win mobile!
Puoi metterci l'interfaccia che preferisci senza problemi ma all'occorrenza se vuoi ci installi anche autocad! :D (vabbeh mo' esagero!)

x FX
Se mi ricordo bene quasi due anni fa Intel ha venduto tutta la divisione XScale alla Marvell, quindi con Atom non si fa concorrenza in casa ...

??
Perchè tanti problemi con x86?
Un palmare x86 è un pc a tutti gli effetti, altro che win mobile!
Puoi metterci l'interfaccia che preferisci senza problemi ma all'occorrenza se vuoi ci installi anche autocad! :D (vabbeh mo' esagero!)

E' un discorso di eleganza e semplicità architetturale.
L'X86 è un accrocchio con non so quanti anni sulle spalle e ne dimostra ancora di più... non entro in dettagli specifici.
L'ARM invece è un progetto molto più nuovo e pensato meglio.
Se avessero impiegato gli stessi fondi per ricercare su ARM e su X86, oggi quest'ultiom sarebbe solo un vago ricordo. (IMVHO)

EDIT: se non puoi installare autocad su un ARM è solo perchè la casa madre, comprensibilmente, non è interessata a fare una versione per ARM.

x FX
Se mi ricordo bene quasi due anni fa Intel ha venduto tutta la divisione XScale alla Marvell, quindi con Atom non si fa concorrenza in casa ...

hai perfettamente ragione; rimangono comunque valide le altre argomentazioni per cui l'attuale incarnazione dell'atom non è credibile come cpu per cellulari

A proposito di eleganza architetturale, bisogna dire che anche gli ARM hanno le loro brutture! Certo non tante come l'architettura intel, sia chiaro. Forse i più eleganti sono i MIPS ma ultimamente sembrano relegati ai dispositivi meno "multimediali".

ARM sono essenzialmente dei RISC, qua si risveglia la guerra RISC vs CISC nel settore mobile!
E se c'è la intel di mezzo, meglio che il SW per ARM si smuova, altrimenti senza sw la vedo dura, a sfidare il bacino X86.
Però credo che ARM in questo segmento abbia ancora abbondanti margini di movimento (almeno dal pdv HW), salvo invenzioni dell'ultim'ora da parte della intel.

E' un discorso di eleganza e semplicità architetturale.
L'X86 è un accrocchio con non so quanti anni sulle spalle e ne dimostra ancora di più... non entro in dettagli specifici.
L'ARM invece è un progetto molto più nuovo e pensato meglio.

ma siamo ancora qui con queste storie?

i risc general purpose più avanzati al mondo sono gli... x86, che sono dei cisc. è dal pentium pro, ovvero DA UN MILIONE DI ANNI che gli x86 sono dei risc; l'unica differenza tra un risc puro è che gli x86 hanno qualche centomila transistor che si occupa di tradurre le istruzioni cisc in risc, basta.

il set di istruzioni ha una valenza tutto sommato relativa, e per quella poca importanza che ha è meglio avere un set di istruzioni cisc, perchè alla fin fine risulta più facile l'ottimizzazione del codice (e ovviamente la programmazione in assembler). storicamente le prestazioni sui risc hanno la menata di dipendere strettamente dalla bontà del compilatore, e finchè hai un processore solo puoi anche ottimizzare il compilatore per quello, ma quando hai "n" processori per "x" famiglie c'è poco da fare...

concettualmente si può anche vedere gli x86 come dei risc con un layer di astrazione e un "compilatore on the fly" integrato nell'hardware che ovviamente ottimizza le micro operazioni in modo ottimale (scusate il gioco di parole) per il core risc.

imho l'unica cosa su cui si può discutere è se sono più belle quelle piuttosto che quelle altre istruzioni cisc; discussione molto poco interessante e soprattutto utile o concludente. per il resto muovere agli x86 le critiche che venivano mosse 15 anni fa quando adottavano un'architettura completamente diversa non è molto al passo coi tempi =)

hai perfettamente ragione; rimangono comunque valide le altre argomentazioni per cui l'attuale incarnazione dell'atom non è credibile come cpu per cellulari

Quoto ed aggiungo: un sistema Atom consuma 2 Watt con il solo
processore, al quale vanno aggiunte le periferiche, finendo col raggiungere
4-5 W, prodotto a 45 nm (il processo piu' recente).

Un sistema SoC basata su ARM consuma in genere sugli 0,5 W (la cpu da
sola se non "tirata" consuma 2-300 mW) ed in genere e' prodotto con processi
vecchiotti (spesso 180 nm a volte 90 nm, comunque ha ampi margini di miglioramento).

L'unica mossa che ARM deve fare e' diminuire un poco i prezzi, ed Intel
resta tagliata fuori da tutti i dispositivi piu' piccoli di un UMPC, sempre che non
ci metta batterie sproporzionate.

ma siamo ancora qui con queste storie?

i risc general purpose più avanzati al mondo sono gli... x86, che sono dei cisc. è dal pentium pro, ovvero DA UN MILIONE DI ANNI che gli x86 sono dei risc; l'unica differenza tra un risc puro è che gli x86 hanno qualche centomila transistor che si occupa di tradurre le istruzioni cisc in risc, basta.

Un processore risc con un'istruzione che legge due byte dalla memoria, li confronta e incrementa due puntatori?
Quando anche i processori intel avessero un'architettura interna risc (e non sono per niente sicuro che sia così), è quella visibile al programmatore (o al compilatore) che conta, e nel caso di intel vediamo un'architettura con istruzioni BCD e operazioni a 8 bit...


il set di istruzioni ha una valenza tutto sommato relativa, e per quella poca importanza che ha è meglio avere un set di istruzioni cisc, perchè alla fin fine risulta più facile l'ottimizzazione del codice (e ovviamente la programmazione in assembler).

Il set di istruzioni ha un'importanza radicale quando si tratta di eseguire istruzioni velocemente e consumando poca energia. Più complessità nel set d'istruzioni significa maggiore complessità dell'hardware (maggiore calore, maggiore latenza). Ecco perché da 20 anni a questa parte quasi tutti i nuovi processori sono stati disegnati secondo la filosofia risc (guarda tutte le console di nuova generazione... vedi cisc da qualche parte?).
Per i processori desktop si è data maggiore importanza alla compatibilità con il codice già esistente, ed ecco perché abbiamo processori che richiedono ventole mostruose per funzionare.


storicamente le prestazioni sui risc hanno la menata di dipendere strettamente dalla bontà del compilatore, e finchè hai un processore solo puoi anche ottimizzare il compilatore per quello, ma quando hai "n" processori per "x" famiglie c'è poco da fare...


Come dire che i pneumatici sono meno vantaggiosi delle ruote piene perché i primi hanno la menata di dipendere dall'essere state gonfiati correttamente. Tecnologia nuova richiede strumenti nuovi, non si può vedere come un pretesto per restare indietro.


imho l'unica cosa su cui si può discutere è se sono più belle quelle piuttosto che quelle altre istruzioni cisc; discussione molto poco interessante e soprattutto utile o concludente.

Qua siamo su hw upgrade, di cosa vuoi che si discuta se non della bellezza delle architetture di processori? :D

A proposito di eleganza architetturale, bisogna dire che anche gli ARM hanno le loro brutture! Certo non tante come l'architettura intel, sia chiaro. Forse i più eleganti sono i MIPS ma ultimamente sembrano relegati ai dispositivi meno "multimediali".
Esempio?

ma siamo ancora qui con queste storie?

i risc general purpose più avanzati al mondo sono gli... x86, che sono dei cisc. è dal pentium pro, ovvero DA UN MILIONE DI ANNI che gli x86 sono dei risc; l'unica differenza tra un risc puro è che gli x86 hanno qualche centomila transistor che si occupa di tradurre le istruzioni cisc in risc, basta. Mi pare chd ti stai dando la zappa sui piedi da solo. Due processori, intel e AMD, che condividono l'unico elemento di interpretare una sottospecie di isa vecchia e accrocchiosa, con tanti ripensamenti e stranezze progettuali, quando potevano buttarla alle ortiche e mettersi d'accordo su una cosa più nuova. Una specie di replica del picojava o come si chiama, quel processore che esegue bytecode java. Idiozia allo stato cristallino. Ma il marketing è tutto, e infatti l'X86 oggi è il processore più diffuso.

il set di istruzioni ha una valenza tutto sommato relativa, e per quella poca importanza che ha è meglio avere un set di istruzioni cisc, perchè alla fin fine risulta più facile l'ottimizzazione del codice (e ovviamente la programmazione in assembler). storicamente le prestazioni sui risc hanno la menata di dipendere strettamente dalla bontà del compilatore, e finchè hai un processore solo puoi anche ottimizzare il compilatore per quello, ma quando hai "n" processori per "x" famiglie c'è poco da fare...Storicamente l'hanno menata, ma è ancora così.
Non è vero che ottimizzi meglio su x86, e se lo fai è perchè qualcuno dall'altra parte s'è smazzato con miliardi di transistop per fare in modo che riconosca una certa sequenza di istruzioni e la traduca in uOps ottimizzati. Guardati un po di decompilati generati da un compilatore X86 mediamente serio (esempio cl.exe). Il compilatore è complessissimo, quando essendo il processore un CISC, dovrebbe essere molto semplice. Ha 400 strategie per fare qualsiasi cosa, ad esempio azzerare una struttura (a volte memcpy, a volte loop, a volte delle istruzioni MOV selvagge che l'azzerano 4 byte per volta). L'X86 è talmente complicato che spesso come ti ho appena detto esistono 3 o 4 modi di fare una cosa, e il più veloce dipende dall'implementazione del microcodice del particolare produttore... decine di pagine di bug del microcodice ogni volta che esce una nuova CPU... un buon 70% dell'ISA che è inutilizzato... questo, permettimi di dirlo, fa schifo.

concettualmente si può anche vedere gli x86 come dei risc con un layer di astrazione e un "compilatore on the fly" integrato nell'hardware che ovviamente ottimizza le micro operazioni in modo ottimale (scusate il gioco di parole) per il core risc.Come tu stesso dici una larga parte di un X86 è deputata a fare un compito che un software farebbe 10 volte meglio, una-tantum in fase di compilazione, con 10 volte meno dispendio energetico e finanziario (tempo sprecato incluso). E il processore che lo eseguirebbe è 1000 volte più semplice. Ecco l'ARM.

Esempio?


Esempio che anche gli arm hanno le loro ineleganze: l'architettura Thumb, istruzioni a 16 bit per risparmiare spazio di codice? Utile in un cellulare, ma qua si parlava di architettura ARM sui server...

Esempio che i mips sono eleganti: non hanno un'istruzione "move" perché lo spostamento si può fare sommando un registro con lo zero... sublime ^_^ .

Esempio che i mips non sono più utilizzati in applicazioni multimediali: la playstation, il n64 e la playstation 2 avevano tutte cpu mips, mentre playstation 3, wii, gamecube e xbox 360 hanno tutte processori POWER.

c'è chi spera che x86 non finisca sui palmari, io volevo così sparare qualche dato per farvi rendere conti di quanto siano feccia i palmari di oggi, i palmari di oggi hanno processori 400 mhz come quelli che si usavano 5 anni fa, la maggior parte ha 64 mb di ram... ridicolo il mio nokia E51 che è solo un telefono ha processore 369 mhz e 80 Mb di ram... per telefonare... ha ha ha e i palmari dovrebbero fare molto di più? ma sono lentissimi, sull'htc touch ti spremi i maroni prima che apra qualcosa! Se mettere processori x86 significa alzare le performance.. ben vengano! Ma poi su sti stupidi palmari non c'è mai memoria... ma metteteci 30 gb di memoria solida costa nulla, se 4 gb di chiavetta usb li vendono a meno di 20 € e ci guadagna la casa, i trasportatori, i grossisti e i rivenditori significa che la memoria costa meno di 2 € alla produzione... per dirne una un mio amico ha comprato in cina (ci è andato fisicamente) per 3 € l'una delle chiavette USB da 32 gb... poi non so magari erano rubate, sicuramente di sottomarca... ma 3 € e mettiamo sta memoria sui palmari!

Esempio che anche gli arm hanno le loro ineleganze: l'architettura Thumb, istruzioni a 16 bit per risparmiare spazio di codice? Utile in un cellulare, ma qua si parlava di architettura ARM sui server...Va bè, il thumb nn lo usi e rimane li buono, invece di importi le sue palle di compatbilità (es. istruzioni con operandi risultato e sorgente fissi)

Esempio che i mips sono eleganti: non hanno un'istruzione "move" perché lo spostamento si può fare sommando un registro con lo zero... sublime ^_^ .
E se il registro non ha zero, dentro? Il mips ha le stesse istruzioni con 3 o 4 operandi come l'arm? Tipo "add r0, r1, 0" invece di "mov r0, r1" ? Ha le istruzioni con shift o rotate integrato? Ha tutte le istruzioin per dsp? Questo MIPS mi pare un po troppo risc :D
(Ovviamente le due soluzioni al mov prendono via lo stesso numero di cicli di clock : uno.... )

c'è chi spera che x86 non finisca sui palmari, io volevo così sparare qualche dato per farvi rendere conti di quanto siano feccia i palmari di oggi, i palmari di oggi hanno processori 400 mhz come quelli che si usavano 5 anni fa, la maggior parte ha 64 mb di ram... ridicolo il mio nokia E51 che è solo un telefono ha processore 369 mhz e 80 Mb di ram... per telefonare... ha ha ha e i palmari dovrebbero fare molto di più? ma sono lentissimi, sull'htc touch ti spremi i maroni prima che apra qualcosa! Se mettere processori x86 significa alzare le performance.. ben vengano! Ma poi su sti stupidi palmari non c'è mai memoria... ma metteteci 30 gb di memoria solida costa nulla, se 4 gb di chiavetta usb li vendono a meno di 20 € e ci guadagna la casa, i trasportatori, i grossisti e i rivenditori significa che la memoria costa meno di 2 € alla produzione... per dirne una un mio amico ha comprato in cina (ci è andato fisicamente) per 3 € l'una delle chiavette USB da 32 gb... poi non so magari erano rubate, sicuramente di sottomarca... ma 3 € e mettiamo sta memoria sui palmari!
Cosa c'entra la RAM e la flash?
Mettere l'atom significa dover mettere batterie più grosse = più scomode e anche piu costose, per cosa? Per avere un ennesimo accrocchio che gira su X86? no grazie :asd:

Poi è il SO che conta, se metti un X86 ma ci lasci winmobile, nn risolvi una cippa.

Perchè !? I Mac sono moooolto migliorati da quando sono X86... soprattutto in stabilità! (ironico... moooolto ironico! ;) ;) )

Uh !?

Non credo proprio, la stabilità mi sembra la stessa, del resto la stabilità di un sistema non dipende di certo da un processore.

Chiaro che se poi il processore tende a surriscaldarsi il sistema è instabile, ma lì parliamo di difetti gravi, che non mostravano ne i G4 e i G5, ne mostrano ora gli intel nuovi.
Anzi a esser pignoli il G4 si scaldava decisamente meno degli attuali processori intel.

E se il registro non ha zero, dentro? Il mips ha le stesse istruzioni con 3 o 4 operandi come l'arm? Tipo "add r0, r1, 0" invece di "mov r0, r1" ? Ha le istruzioni con shift o rotate integrato? Ha tutte le istruzioin per dsp? Questo MIPS mi pare un po troppo risc :D
(Ovviamente le due soluzioni al mov prendono via lo stesso numero di cicli di clock : uno.... )

Non ho capito il problema con lo 0, nei mips r0 contiene sempre 0, cmq il set d'istruzioni mips, per quanto semplice, è facilmente estendibile grazie al supporto per i "coprocessori", tant'è vero che in passato gli si è aggiunto di tutto (supporto per la virgola mobile nei processori standard, la GPU della PSX, le due unità vettoriali della PS2...).

c'è chi spera che x86 non finisca sui palmari, io volevo così sparare qualche dato per farvi rendere conti di quanto siano feccia i palmari di oggi, i palmari di oggi hanno processori 400 mhz come quelli che si usavano 5 anni fa, la maggior parte ha 64 mb di ram... ridicolo il mio nokia E51 che è solo un telefono ha processore 369 mhz e 80 Mb di ram... per telefonare... ha ha ha e i palmari dovrebbero fare molto di più? ma sono lentissimi, sull'htc touch ti spremi i maroni prima che apra qualcosa! Se mettere processori x86 significa alzare le performance.. ben vengano! Ma poi su sti stupidi palmari non c'è mai memoria... ma metteteci 30 gb di memoria solida costa nulla, se 4 gb di chiavetta usb li vendono a meno di 20 € e ci guadagna la casa, i trasportatori, i grossisti e i rivenditori significa che la memoria costa meno di 2 € alla produzione... per dirne una un mio amico ha comprato in cina (ci è andato fisicamente) per 3 € l'una delle chiavette USB da 32 gb... poi non so magari erano rubate, sicuramente di sottomarca... ma 3 € e mettiamo sta memoria sui palmari!

E' verissimo, assurdo che nel 2008 si trovi solo 256 MB di memoria fisica dentro un palmare di ultima generazione (e che costa più di 500 euro).
Tuttavia credo ci sia differenza tra quella che i costruttori chiamano ROM (che è di 128 MB o 256) e la memoria flash degli SSD o chiavette: infatti nell'HTC Diamond ci sono 256MB di ROM e poi una memoria statica a parte da qualche giga (integrata). Non ho capito però la ROM con cosa la fanno, sarà mica una vera EEPROM? E perchè ricorrere a questa invece di una normale flash?

E' verissimo, assurdo che nel 2008 si trovi solo 256 MB di memoria fisica dentro un palmare di ultima generazione (e che costa più di 500 euro).
Tuttavia credo ci sia differenza tra quella che i costruttori chiamano ROM (che è di 128 MB o 256) e la memoria flash degli SSD o chiavette: infatti nell'HTC Diamond ci sono 256MB di ROM e poi una memoria statica a parte da qualche giga (integrata). Non ho capito però la ROM con cosa la fanno, sarà mica una vera EEPROM? E perchè ricorrere a questa invece di una normale flash?

In genere quella che i produttori chiamano ROM e' solo un'altra flash
(o addirittura una porzione della flash principale) che pero' richiede una
procedura particolare per venire riscritta (in modo che non ti bruci il
sistema operativo il terzo giorno che usi il palmare...)

Non ho capito il problema con lo 0, nei mips r0 contiene sempre 0, cmq il set d'istruzioni mips, per quanto semplice, è facilmente estendibile grazie al supporto per i "coprocessori", tant'è vero che in passato gli si è aggiunto di tutto (supporto per la virgola mobile nei processori standard, la GPU della PSX, le due unità vettoriali della PS2...).
non ricorfavo il fatto del registro zero... ho usato solo ARM per programmazione assembly ogni tanto!
riesce il mips a codificare nell'opcode un operando, mantenendi ovviamente il requisito della la lunghezza fissa delle istruzioni? (chiaramente con delle limitazioni)
sono queste le cose che mi piacciono dei risc... pieni di funzionalità pensate da programmatori PER prgrammatori... :D

E' verissimo, assurdo che nel 2008 si trovi solo 256 MB di memoria fisica dentro un palmare di ultima generazione (e che costa più di 500 euro).
Tuttavia credo ci sia differenza tra quella che i costruttori chiamano ROM (che è di 128 MB o 256) e la memoria flash degli SSD o chiavette: infatti nell'HTC Diamond ci sono 256MB di ROM e poi una memoria statica a parte da qualche giga (integrata). Non ho capito però la ROM con cosa la fanno, sarà mica una vera EEPROM? E perchè ricorrere a questa invece di una normale flash?
vorrei farti notare che hai preso il P750, uno dei palmari piu sopravvalutati degli ultimi tempi, e che in quanto tale *ancora* solo 64mb di ram :asd:
chi è causa del suo mal...

io le loro robe le ho viste montate solo nelle console Nintendo ...

tempo fa anche MIPS si usava nei palmari, è solo da qualche anno che l'architettura ARM ha assunto una sorta di monopolio...
per quanto riguarda la lentezza dei palmari.... mica dipende dal processore
il sony ericsson p1i che ho preso, ha ARM 200mhz, eppure viaggia molto piu' del mio vecchio htc p3600 con cpu samsung 400mhz, i palmari sono lenti perchè utilizzano microsoft... utilizzare symbian uiq (che ha una migliore interfaccia touchscreen, infatti si usa quasi solo con le dita, è completo quando windows, ma meno complesso...) cmq che la x86 è obsoleta e inutilmente complessa è cosa risaputa, basta chiedere a qualunque docente universitario di architettura dell'elaboratore...
ma come sempre è colpa delle software house...

tempo fa anche MIPS si usava nei palmari, è solo da qualche anno che l'architettura ARM ha assunto una sorta di monopolio...
per quanto riguarda la lentezza dei palmari.... mica dipende dal processore
il sony ericsson p1i che ho preso, ha ARM 200mhz, eppure viaggia molto piu' del mio vecchio htc p3600 con cpu samsung 400mhz, i palmari sono lenti perchè utilizzano microsoft... utilizzare symbian uiq (che ha una migliore interfaccia touchscreen, infatti si usa quasi solo con le dita, è completo quando windows, ma meno complesso...) cmq che la x86 è obsoleta e inutilmente complessa è cosa risaputa, basta chiedere a qualunque docente universitario di architettura dell'elaboratore...
ma come sempre è colpa delle software house...

Dissentirei, tutti i sony ericsson che ho visto basati su UIQ erano schifosamente lenti...
Se un palmare è lento sarà anche colpa del fatto che il produttore non ha montato altre cose di qualità, come ad esempio un chip flash velcoe, un lettore di SD veloce, una RAM veloce, o altri chip integrati che possano assistere in qualche modo il SO in alcune funzioni (acceleratori grafici, etc...)

vorrei farti notare che hai preso il P750, uno dei palmari piu sopravvalutati degli ultimi tempi, e che in quanto tale *ancora* solo 64mb di ram :asd:
chi è causa del suo mal...

E' vero che ha solo 64MB di RAM e sono pochi, ma ti dico due cose:
- Il riferimento alla dimensione della ROM ridotta è valido per tutti i PDA attuali, eccezion fatta per l'iphone.
- Il P750 è sena dubbio il miglior PDA phone con tastiera T9 e GPS integrato, dalle dimensioni accettabili e completezza hardware e di connettività; se trovi un prodotto migliore con queste caratteristiche dimmelo, io non l'ho trovato.

- Il riferimento alla dimensione della ROM ridotta è valido per tutti i PDA attuali, eccezion fatta per l'iphone.
Il diamond avrà 4 gb di ROM.
Per me la ROM non è un requisio importante, basta che non sia poca come nel mio universal che è appena di 128mb. Già 256mb bastano, ne rimangono più della metà disponibili all'utente, per me è un quantitativo più che sufficiente.
Preferisco acquistare una scheda SD/mini/micro da poter togliere e inserire velocemente nel PC se devo scambiare dati.
Questa politica della apple di isolare completamente l'iphone dai suoi simili non mi piace per niente, infatti.

Il diamond avrà 4 gb di ROM.
Per me la ROM non è un requisio importante, basta che non sia poca come nel mio universal che è appena di 128mb. Già 256mb bastano, ne rimangono più della metà disponibili all'utente, per me è un quantitativo più che sufficiente.
Preferisco acquistare una scheda SD/mini/micro da poter togliere e inserire velocemente nel PC se devo scambiare dati.
Questa politica della apple di isolare completamente l'iphone dai suoi simili non mi piace per niente, infatti.

Infatti, "avrà" è futuro. E poi non ha tastiera, quindi già due motivi per non averlo comprato :)
Per la ROM sono d'accordo con te che 256MB sono più che sufficienti per le applicazioni, e che una microSD va benissimo per poterla inserire anche in una chiavetta USB in qualsiasi evenienza (non guasterebbe però una memoria interna più capiente).

Io con un po' di modding (rom) e microSd di qualità ho un signor palmare eten M800 THE BEST (prezzo qualità assistenza cortesia).
Se parliamo di processori ad esempio era meglio 8085 ottimizzato con un ottimo compilatore e codice scritto li-li ovviamente scherzo.
Però era divertente preogrammare i porti ed i led ;).

Io con un po' di modding (rom) e microSd di qualità ho un signor palmare eten M800 THE BEST (prezzo qualità assistenza cortesia).
Se parliamo di processori ad esempio era meglio 8085 ottimizzato con un ottimo compilatore e codice scritto li-li ovviamente scherzo.
Però era divertente preogrammare i porti ed i led ;).

Sicuramente l'8085 aveva più senso con quell'ISA, e un 8085 clockato a 3 ghz nn so mica se sarebbe tanto più lento di un Core2 :D

Esempio che anche gli arm hanno le loro ineleganze: l'architettura Thumb, istruzioni a 16 bit per risparmiare spazio di codice? Utile in un cellulare, ma qua si parlava di architettura ARM sui server...


Le thumb sono estensioni e cosa piu importante sono fatte bene
(la prima implementazione semplicemente "espandeva" secondo uno schema
fisso l'istruzione thumb nel suo equivalente "full 32bit" *dentro* la pipeline)
oltre a produrre codice piu "compatto" ottieni vantaggi
pure in fase si esecuzione (ti sta piu codice nella cache istruzioni
e ti incrementa il numero medio di istruzioni caricate nella pipeline
per accesso alla memoria).
In "codice da server" dove hai parecchia roba sequenziale
che non sfrutta tanti registri ed usa le istruzioni piu comuni
se compili gli spezzoni giusti in formato thumb ottieni un incremento
di prestazioni mica male.

Piuttosto la vera limitazione degli ARM e' che non sono
partiti da subito con un supporto standard per il floating point
e che la maggior parte delle loro implementazioni e' pensata
per applicazioni embedded (dove se la scelta e' tra avere piu cache
ed avere consumi piu ridotti, vince la riduzione dei consumi, lo stesso
vale per la banda di I/O per l'accesso a ram esterna, ecc. ecc.)

Ma se devi sviluppare roba nel settore embedded gli arm sono l'ideale
perche trovi il chip che fa per te con una scelta vastissima
di versioni e fornitori, si va da quelli di "fascia alta" giu fino
ai "simil PIC" della fascia bassa di Luminary Micro, vere cpu a 32bit
con flash e ram interne e con pinout ridottissimo come quello dei PIC
di fascia piu bassa, ma con potenza di elaborazione spropositata
(rispetto ai PIC) e molto piu facili da programmare, non esiste
una vastita di scelta simile con gli x86.


Esempio che i mips sono eleganti: non hanno un'istruzione "move" perché lo spostamento si può fare sommando un registro con lo zero... sublime ^_^ .


E che mi dici del "comodo" slot di 1 istruzione subito dopo i jump ?
O delle move immediate a 32bit che nelle prime versioni
dovevano essere "espanse" in due mov a 16 bit ?

Il fatto e' che quando viene progettata una nuova cpu da zero
c'e' sempre qualcuno che cerca di implementare una feature molto cool
che poi magari finisce con il rivelarsi una palla al piede.
Ma in confronto ai salti mortali degli x86, sia ARM che MIPS sono
pulitissimi.
Comunque quando poi arriva il momento di estendere il set d'istruzion
di solito si finisce sempre con lo sfruttare i "buchi".
Per esempio, se ricordo bene, anche i mitici Alpha
(i RISC piu duri e puri usciti in commercio) quando arrivo' il momento
di implementare le hint di prefetch utilizzarono le istruzioni
"muovi locazione di memoria nel registro costante zero"
che in precedenza era una NOP e veniva sconsigliato di generarla.

Le thumb sono estensioni e cosa piu importante sono fatte bene
(la prima implementazione semplicemente "espandeva" secondo uno schema
fisso l'istruzione thumb nel suo equivalente "full 32bit" *dentro* la pipeline)
oltre a produrre codice piu "compatto" ottieni vantaggi
pure in fase si esecuzione (ti sta piu codice nella cache istruzioni
e ti incrementa il numero medio di istruzioni caricate nella pipeline
per accesso alla memoria).
In "codice da server" dove hai parecchia roba sequenziale
che non sfrutta tanti registri ed usa le istruzioni piu comuni
se compili gli spezzoni giusti in formato thumb ottieni un incremento
di prestazioni mica male.

Piuttosto la vera limitazione degli ARM e' che non sono
partiti da subito con un supporto standard per il floating point
e che la maggior parte delle loro implementazioni e' pensata
per applicazioni embedded (dove se la scelta e' tra avere piu cache
ed avere consumi piu ridotti, vince la riduzione dei consumi, lo stesso
vale per la banda di I/O per l'accesso a ram esterna, ecc. ecc.)

Ma se devi sviluppare roba nel settore embedded gli arm sono l'ideale
perche trovi il chip che fa per te con una scelta vastissima
di versioni e fornitori, si va da quelli di "fascia alta" giu fino
ai "simil PIC" della fascia bassa di Luminary Micro, vere cpu a 32bit
con flash e ram interne e con pinout ridottissimo come quello dei PIC
di fascia piu bassa, ma con potenza di elaborazione spropositata
(rispetto ai PIC) e molto piu facili da programmare, non esiste
una vastita di scelta simile con gli x86.



E che mi dici del "comodo" slot di 1 istruzione subito dopo i jump ?
O delle move immediate a 32bit che nelle prime versioni
dovevano essere "espanse" in due mov a 16 bit ?

Il fatto e' che quando viene progettata una nuova cpu da zero
c'e' sempre qualcuno che cerca di implementare una feature molto cool
che poi magari finisce con il rivelarsi una palla al piede.
Ma in confronto ai salti mortali degli x86, sia ARM che MIPS sono
pulitissimi.
Comunque quando poi arriva il momento di estendere il set d'istruzion
di solito si finisce sempre con lo sfruttare i "buchi".
Per esempio, se ricordo bene, anche i mitici Alpha
(i RISC piu duri e puri usciti in commercio) quando arrivo' il momento
di implementare le hint di prefetch utilizzarono le istruzioni
"muovi locazione di memoria nel registro costante zero"
che in precedenza era una NOP e veniva sconsigliato di generarla.
Hai detto cose molto interessanti ... lavori in campo embedded? Io lavoravo in un azienda dove programmavano i computer di alcune macchine da fitness e medicali con CPU renesas SH3... purtroppo non sono mai arrivato a quella posizione prima che chiudessero (ero sistemista)...
Mi interesserebbe un totale lavorare in questo campo.

Purtroppo la pulizia progettuale non è sufficiente a garantire un progetto.

Per il momento Arm dispone di una larga base installata e di tante soluzioni che si sono evolute nel tempo ma temo che Intel, un po' per volta, schiacci la rivale.

Come è già stato evidenziato gli Apple non sono certo peggiorati passando da processori risc a processori cisc, immagino che la stessa cosa accadrà nei sistemi embedded, sviluppando processori più potenti, mantenendo però sempre bassi i consumi, in modo da compensare (almeno in parte) l'esecuzione delle vecchie istruzioni x86.

Ricordiamoci che Intel ha già subito uno scotto pesante quando ha sviluppato i suoi processori a 64 bit dotati di un set di istruzioni nuovo probabilmente è questo che l'ha fatta optare per il riutilizzo delle x86 anziché sviluppare un set di istruzioni nuovo e specifico.

In ogni modo, anche se immagino che Intel sorpasserà Arm, non si tratta di una cosa che avverrà domani, probabilmente occorreranno diversi anni.

Comunque mi fà piacere esista un po' di concorrenza dato che andrà a beneficio dell'utente.

Sicuramente l'8085 aveva più senso con quell'ISA, e un 8085 clockato a 3 ghz nn so mica se sarebbe tanto più lento di un Core2

Bhe dipende se riesci a qualcuno che ti affitti la stanza e un bruciatore a carbon coke per farlo andare.
Cheers !

Che Intel la spunti con il suo Atom e derivati contro gli ARM non è affatto detto, nonostante la sua indubbia potenza economica e commerciale e l'eccellenza delle sue fabbriche.

Il problema è che gli x86 oltre ad essere CISC (quindi concettualmente antiquati) sono nati male, e solo il monopolio Wintel ha fatto sì che oggi siano competitivi a livello desktop, grazie agli enormi volumi commercializzati e i relativi investimenti possibili.

Ma a livello embedded è un'altra storia.

Per chi non l'ha letto, consiglio questo ottimo articolo di Jon Stokes su Arstechinca: http://arstechnica.com/articles/paedia/risc-vs-cisc-mobile-era.ars

E' un discorso di eleganza e semplicità architetturale.
L'X86 è un accrocchio con non so quanti anni sulle spalle e ne dimostra ancora di più... non entro in dettagli specifici.
L'ARM invece è un progetto molto più nuovo e pensato meglio.
Se avessero impiegato gli stessi fondi per ricercare su ARM e su X86, oggi quest'ultiom sarebbe solo un vago ricordo. (IMVHO)

EDIT: se non puoi installare autocad su un ARM è solo perchè la casa madre, comprensibilmente, non è interessata a fare una versione per ARM.

Non posso non quotarti. Una fredda e inoppugnabile analisi (bello sapere che c'e' ancora chi vede le cose come stanno in realta').
Aggiungerei, per fornire qualche elemento di riflessione ai meno informati che nell'87 il primo ARM e cioe' l'ARM2 con 30000 transistor e 8MHz aveva prestazioni paragonabili a un 386 a 25MHz che di transistor ne contava circa 270000. Inoltre c'e' da dire che server con ARM alla fine degli anni 80 gia' esistevano con l'immancabile Unix (RiscIX nel caso specifico).

ma siamo ancora qui con queste storie?

i risc general purpose più avanzati al mondo sono gli... x86, che sono dei cisc.

Definire gli attuali x86 dei RISC e' assurdo. Sono semplicemente dei CISC. Il fatto che l'hardware sia gestito con un cuore RISC e' irrilevante nella classificazione del tipo di processore poiche' la definizione di RISC o CISC riguarda esclusivamente il set di istruzioni (che tutto e' fuorche' RISC).

...l'unica differenza tra un risc puro è che gli x86 hanno qualche centomila transistor che si occupa di tradurre le istruzioni cisc in risc, basta.
E qualche altra tonnellata di transistor per tutte quelle cose che a un "RISC puro" non e' detto che servano, ad es. branch prediction sofisticata, gestione dello stack, centinaia di istruzioni in piu' da gestire, pesante esecuzione out of order, floating point, cache enormi, etc.

il set di istruzioni ha una valenza tutto sommato relativa, e per quella poca importanza che ha è meglio avere un set di istruzioni cisc,...

Se avessi programmato in assembler un x86 e un qualche altro processore fatto invece come dio comanda sapresti che non e' cosi. Ti posso indicare i 68000 e gli ARM che sono abbissalmente migliori degli x86 (a livello si set di istruzioni naturalmente), ma non dubito che moooooolte altre architetture farebbero impallidire la ia32.
E come opinione mia personale credo che mentre la ia32 potrebbe tranquillamente candidarsi al peggior set di istruzioni di tutti i tempi, quello dell'ARM e' sicuramente fra i migliori mai concepiti (parole grosse ma provare per credere).
Se poi pensiamo che il set di istruzioni condiziona in modo assoluto la rete logica del processore, direi che la tua affermazione e' totalmente errata. Se ci pensi quando costruiamo una rete logica si parte sempre da cio' che i nostri bei transistor sono chiamati a fare e non il contrario. Aggiungiamo anche che cache, latenze,registri e una miriade di altre cose dipendono anche se non sempre in prevalenza dalle istruzioni che si possono eseguire

...storicamente le prestazioni sui risc hanno la menata di dipendere strettamente dalla bontà del compilatore,...

Direi proprio il contrario. Sai la difficolta' di creare un compilatore che tiente conto dei tempi di esecuzione di centinaia di istruzioni create senza coerenza alcuna e che modificano la velocita' di esecuzione del codice in base all'ordine con cui le si posiziona. Nel caso di un RISC il compilatore deve conoscere poche decine di istruzioni spesso con sintassi/significato/comportamento coerenti e una flessibilita' senza pari.

...concettualmente si può anche vedere gli x86 come dei risc con un layer di astrazione e un "compilatore on the fly" integrato nell'hardware che ovviamente ottimizza le micro operazioni in modo ottimale (scusate il gioco di parole) per il core risc.

Avresti anche ragione, ma ti chiedo, che senso ha astrarre in questo modo ?

imho l'unica cosa su cui si può discutere è se sono più belle quelle piuttosto che quelle altre istruzioni cisc; discussione molto poco interessante e soprattutto utile o concludente.

Non solo e' interessante dal punto di vista accademico ma il set di istruzioni di un microprocessore e' la principale interfaccia che ha con l'uomo (scusa se e' poco) ed e' il solo modo di programmarlo per cui va da sè che cattive istruzioni portano a buone imprecazioni (pensa che bello guidare una BMW con gli interni di una 2CV).

per il resto muovere agli x86 le critiche che venivano mosse 15 anni fa quando adottavano un'architettura completamente diversa non è molto al passo coi tempi =)

Architettura diversa ma stesso set di istruzioni pero'. Ed e' proprio di questo che si parla con i termini RISC e CISC, non di puro hardware. Le critiche durano da ben piu' di 15 anni sono 20 anni che vengono criticati aspramente e ci sono tutte le ragioni del mondo per criticarli ancora piu' aspramente visto che dall'8080 del 1974 il set di istruzioni si e' soltanto espanso. In questo campo l'unica vera e grande innovazione e' stata fatta dall'AMD con i 64bit, con un maggior numero di registri, istruzioni piu' coerenti, piu' semplici e piu' flessibili nell'utilizzo che sostanzialmente hanno cercato di raddrizzare un po la rotta.

Hai detto cose molto interessanti ... lavori in campo embedded?

Si, ma attualmente raramente mi occupo della parte embedded
vera e propria.
Principalmente mi occupo della realizzazione dei frontend per la
programmazione e del software di supervisione sul lato pc.

Paradossalmente quella sta diventando la parte piu pesante
perche due macchine industriali "uguali" hanno costi di esercizio
e rese molto diverse in base a come vengono gestite
(es: automatizzando la conversione da disegni .dxf
a part program per lavorazioni specifiche come minimo
si risparmia un operaio e/o un impiegato e si aumenta
il tempo di utilizzo della macchina).

...
In questo campo l'unica vera e grande innovazione e' stata fatta dall'AMD con i 64bit, con un maggior numero di registri, istruzioni piu' coerenti, piu' semplici e piu' flessibili nell'utilizzo che sostanzialmente hanno cercato di raddrizzare un po la rotta.

Non posso condividere.
Amd ha cercato di porre una pezza all'esistente, in modo da garantire la compatibilità con l'enorme parco software esistente, mettendo caratteristiche aggiuntive interessanti.
E' la lentezza della conversione tra sistemi a 32 bit a 64 bit non l'ha certo agevolata.
Da questo punto di vista la situazione è quasi ferma.

L'Intel con l'Itanium ed il nuovo set di istruzioni Epic, che per mantenere il più possibile la compatibilità con il passato effettuava una conversione al "volo" delle istruzioni precedenti x86 - nei casi richiesti, mi pare fosse un progetto più evoluto.

Poi certo non ha avuto successo ed addirittura, cercando su internet, non riesco neanche a trovare certe comparative che venivano effettuate all'epoca con il rivale amd.
Per dire non soltanto è un progetto che non ha avuto successo ma è proprio caduto nell'oblio.
Del resto molti preferiscono mettersi gli Xeon e non avere problemi lato software piuttosto che andare verso gli Itanium.

Non posso condividere....

Mi sono espresso in modo poco chiaro, nel paragrafo stavo parlando di processori x86.

Amd ha cercato di porre una pezza all'esistente, in modo da garantire la compatibilità con l'enorme parco software esistente, mettendo caratteristiche aggiuntive interessanti.

E' vero. Ma poteva farlo nello stesso modo con cui la Intel passò dai 16 ai 32 bit, e cioè senza cambiare niente di niente o peggio avrebbe potuto incasinare ancora di piu le cose con nuove diavolerie, pensa che bello ritrovarsi a gestire di nuovo cose come la segmentazione o altro. :)
Io ho sempre sognato che ci fosse un'apertura dell'I.S. del RISC interno (AMD e Intel ognuno col proprio, ci mancherebbe), e a dire la verità 5-6 anni fa avrei scommesso che sarebbe stata fatta nei processori a venire. Ti immagini usare l'I.S. più opportuno per ogni occasione senza perdite di prestazioni perchè tutto in hardware. Nel giro di pochi anni si sarebbe potuta archiviare la pagina x86 della storia informatica. (stò vaneggiando lo so)

Per dire non soltanto è un progetto che non ha avuto successo ma è proprio caduto nell'oblio.
Del resto molti preferiscono mettersi gli Xeon e non avere problemi lato software piuttosto che andare verso gli Itanium.

Il fatto è che di buoni processori x server ce ne sono molti e l'Itanium non è certo niente di esoterico. La differenza principale fra questi e gli x86 sta nel dio denaro. Costi di R&D e prezzo d'acquisto oltre che time-to-market vengono influenzati dalla richiesta di mercato delle CPU desktop.
Alla Intel hanno incatenato il mercato ad un'architettura ed ora questo gli si è rivolto contro. Se volevano realmente cambiare (vedi Itanium) potevano farlo tranquillamente quando non avevano concorrenza. Adesso è tardi.

Ciao.

A quel che ho sentito in giro ARM la guerra l'ha già persa... contro MIPS.
MIPS è riuscita a guadagnare contratti con partner di maggior prestigio (e maggior volume).
Non che Intel faccia paura, è troppo indietro e troppo inadatta per "addentare" il lucroso mercato in cui MIPS ed ARM sguazzano (e ci sguazzano perché danno licenze e schemi anziché vendere chip); Intel è solo interessata ad entrare nel mercato (anche come underdog) per farsi le ossa.

Poi vabbè, che posso farci... io sono di parte, faccio un uname -a sull'AP e mi dice
Linux DD-WRT 2.4.34-pre2 #170 Fri Sep 15 20:10:21 CEST 2006 mips unknown

Il fatto è che di buoni processori x server ce ne sono molti e l'Itanium non è certo niente di esoterico. La differenza principale fra questi e gli x86 sta nel dio denaro. Costi di R&D e prezzo d'acquisto oltre che time-to-market vengono influenzati dalla richiesta di mercato delle CPU desktop.
Alla Intel hanno incatenato il mercato ad un'architettura ed ora questo gli si è rivolto contro. Se volevano realmente cambiare (vedi Itanium) potevano farlo tranquillamente quando non avevano concorrenza. Adesso è tardi.

Ciao.

Perchè intel ha concorrenza per caso? Umm il 90% dei portatili ha processore intel, compresi i mac (100% loro), bhè forse mi sto sbagliando... più del 90%. I desktop bhè ormai sono tutti intel... il quad che ho io il Q6600 che ho pagato a settembre 240€ ora costa 160€... chiunque può permetterselo... non te lo puoi permettere prendi qualcosa di peggio ma non vai su amd perchè attualmente non è un gran che (e mi dispiace, ce l'aveva quasi fatta qualche anno fa a diventare forte e io infatti prima di questo quad ho comprato 3 amd). Intel subisce la stessa concorrenza che microsoft subisce da linux... ha ha la concorrenza di linux...