Link alla notizia: http://www.businessmagazine.it/news/arm-e-la-strada-che-porta-ai-64-bit_35467.html

Da una recente conferenza emergono le posizioni di ARM, per voce del CEO Warren East, in merito alle architetture a 64bit

Click sul link per visualizzare la notizia.

ma l'unico vantaggio relativo ai 64bit è quello di poter usare più di 4 giga di ram oppure c'è dell'altro?

ma l'unico vantaggio relativo ai 64bit è quello di poter usare più di 4 giga di ram oppure c'è dell'altro?

guarda che anche con 32bit potevi usare piu di 4 gb di ram è.... era solo un problema di Windows nelle versioni home ad avere questa limitazione;

perchè gia all'epoca di windows 2000 e 2003 per server erano a 32 bit ma supportavano piu di 4 Gb di ram

http://www.microsoft.com/whdc/system/platform/server/pae/paemem.mspx

ma l'unico vantaggio relativo ai 64bit è quello di poter usare più di 4 giga di ram oppure c'è dell'altro?

si, per ogni singolo processo puoi sfruttare più di 2gb di ram..

Ma ai 64 bit ci dovrà arrivare anche perché tra qualche anno dovrà infilarsi nei PC con Win8 che da quel che ho capito è a 64bit.

ma l'unico vantaggio relativo ai 64bit è quello di poter usare più di 4 giga di ram oppure c'è dell'altro?

i vantaggi vanno oltre perche i 64bit sul x86 sono nati con un nuovo set di istruzioni che vanno a sostiruire le precedenti x86 ormai obsolete avente decenni sulle spalle.

Un altro vantaggio dei 64bit è quello di avere questa dimensione non solo nell'indirizzamento verso la memoria ma anche i registri sono di questa grandezza, su un arm questo per ora sarebbe solo uno svantaggio visto gli ambiti di utilizzo e il maggior consumo che darebbe.

guarda che anche con 32bit potevi usare piu di 4 gb di ram è.... era solo un problema di Windows nelle versioni home ad avere questa limitazione;

perchè gia all'epoca di windows 2000 e 2003 per server erano a 32 bit ma supportavano piu di 4 Gb di ram

http://www.microsoft.com/whdc/system/platform/server/pae/paemem.mspx

non è un problema di windows è un limiet tecnico dei 32bit che sono appunto da 0 fino a 4294967295 e non è certo una qeustione di windows o altro ma semplicemente una qeustione matematica. Tutti gli altri sistemi operativi hanno gli stessi limiti.

Superare i 4GB con il pae è una cosa completamente diversa perche anche se puoi farlo di fatto perdi in performance e flessibilità del sistema di indirizzamento. Insomma si usava prima che esistessero i 64bit ma solo perche non esisteva alternativa, usare questo sistema oggi è assurdo.

ma l'unico vantaggio relativo ai 64bit è quello di poter usare più di 4 giga di ram oppure c'è dell'altro?

Un'esempio stupido potrebbe essere quello di pensare ad una ruota di un'auto di 32 cm di diametro a quanto deve girare per fare in fretta un Kilometro, se ne prendi una di diametro 64 cm a parità di giri avrà fatto molta più strada. Fantasiosamente potresti pensare così alla differenza tra 32 e 64 bit

ma l'unico vantaggio relativo ai 64bit è quello di poter usare più di 4 giga di ram oppure c'è dell'altro?

Con il passaggio ai 64bit è possibile anche definire in modo "pulito" un nuovo set di istruzioni standard che aiuta ad avere prestazioni migliori.
Quelli di ARM Ltd. sono riusciti a rinnovare il set d'istruzioni degli ARM a 32bit "sfruttando gli opcode non utilizzati"; ripartendo da zero per la modalita a 64bit potrebbero fare molto di più, senza cadere nell'errore di modifiche troppo radicali potrebbero "ricompattare" il set d'istruzioni ecc. ecc. in modo da sfruttare meglio le cache dati ed istruzioni ed avere una logica di esecuzione più veloce a parità di tecnologia disponibile.

Poi se si parla di sistemi "grossi", poter accedere linearmente a più di 4GB (senza dover far ricorso a funzioni particolari del S.O. ad ogni accesso a dati "grossi") permette di avere prestazioni migliori e di scrivere codice più semplice che gira su qualsiasi altro sistema a 64bit.

Con gli x86 già a 64bit (e con parecchio codice C/C++ già scritto per essi) se ARM cerca di fargli concorrenza con cpu a 32bit al di sopra della fascia bassa del settore dei server, quelli di intel avranno gioco facile a far notare che per varie applicazioni bisognerà mettere mano pesantemente ai sorgenti e non semplicemente ricompilare (con tutti i costi aggiuntivi che comporta la cosa).

Cosa vuol dire "ricompattare il set di istruzioni"?
ARM e' comunque RISC< quindi tutte le istruzioni sarebbero a 64 buit, comprese la NOP :)
x86 da questo punto di vista e' piu' compatto, producendo un codice di dimensione minore (pagando da altre parti, causa vecchiaia dell'ISA).

chi si aspetta di vedere win8 su arm, penso che possa mettersi comodo dato che potrebbe non succedere mai :D

Questo notizia fa perfettamente il paio con quello che mi aspettavo: processori ARM per uso in web server e altri lavori leggeri. :)
Nelle news precedenti (come quella sul Quad Core Armada) c'era chi si ostinava a confrontarli con gli Xeon 55xx :D

Prima o poi però, se ARM vuole davero avere una quota significativa in ambito server, il passaggio a 64 andrà fatto. Tra l'altro, come ha fatto notare Pleg, in questo frangente l'eredità RISC pone lo svantaggio di rendere immediatamente le istruzioni 2 volte più voluminose, mentre con X86-64 l'incremento non è così netto (in teoria basta aggiungere il prefisso REX che mi sembra essere di 1 bit, anche se i puntatori a memoria ovviamente sono due volte più grandi). Tutto questo significa che per competere davvero a livello prestazionale, a 64 bit gli ARM avranno bisogno di cache più grandi rispetto alle controparti X86.

Ciao. :)

Cosa vuol dire "ricompattare il set di istruzioni"?
ARM e' comunque RISC< quindi tutte le istruzioni sarebbero a 64 buit, comprese la NOP :)
x86 da questo punto di vista e' piu' compatto, producendo un codice di dimensione minore (pagando da altre parti, causa vecchiaia dell'ISA).

Allora, in primo luogo gli ARM non sono dei RISC, hanno parecchi punti in comune con la filosofia di progettazione dei RISC ma sono stati pensati puntando alle prestazioni reali e con caratteristiche decisamente NON-RISC tipo avere la maggior parte delle istruzioni ad esecuzione condizionale.
Poi con le estensioni Thumb e Thumb2 è stato introdotto il set d'istruzioni "compatto" (più compatto della maggior parte degli altri concorrenti,incluso l'x86).
Infatti le cpu ARM di fascia più bassa (M3, M0, ecc.) supportano solo il sottoinsieme Thumb/Thumb2 per "compattare pure il core".

Nel caso del passaggio ai 64bit possono fare una cosa analoga, con maggior liberta nel ricodificare in modo ottimale le istruzioni nella modalità a 64bit, in particolare includendo i registri FP e vettoriali e le relative istruzioni nel set d'istruzioni "standard" a 64bit (se ricordo bene attualmente negli ARM a 32bit quelle istruzioni sono mappate sugli opcode per i coprocessori).

Allora, in primo luogo gli ARM non sono dei RISC, hanno parecchi punti in comune con la filosofia di progettazione dei RISC ma sono stati pensati puntando alle prestazioni reali e con caratteristiche decisamente NON-RISC tipo avere la maggior parte delle istruzioni ad esecuzione condizionale.
Poi con le estensioni Thumb e Thumb2 è stato introdotto il set d'istruzioni "compatto" (più compatto della maggior parte degli altri concorrenti,incluso l'x86).
Infatti le cpu ARM di fascia più bassa (M3, M0, ecc.) supportano solo il sottoinsieme Thumb/Thumb2 per "compattare pure il core".

Nel caso del passaggio ai 64bit possono fare una cosa analoga, con maggior liberta nel ricodificare in modo ottimale le istruzioni nella modalità a 64bit, in particolare includendo i registri FP e vettoriali e le relative istruzioni nel set d'istruzioni "standard" a 64bit (se ricordo bene attualmente negli ARM a 32bit quelle istruzioni sono mappate sugli opcode per i coprocessori).

Be ARM è fondamentalmente un processore RISC; che poi implementi anche alcune istruzioni "aggiuntive" è cosa abbastanza comune (sono stati pochissimi i processori davvero RISC "puri").

Il set di istruzioni Thumb è effettivamente qualcosa di molto utile in ambiti specifici ma, essendo a lunghezza variabile, condivide alcuni dei "difetti" delle CPU x86 (in particolare lato decoder) e quindi non mi stupirei se, in tale modalità, il processore consumasse qualcosa di più...

Ciao. :)

Be ARM è fondamentalmente un processore RISC; che poi implementi anche alcune istruzioni "aggiuntive" è cosa abbastanza comune (sono stati pochissimi i processori davvero RISC "puri").


Uno dei primi dogmi dei RISC è: niente istruzioni complesse o sprecare risorse per istruzioni che vengono usate poco frequentemente.
Gli ARM nel set d'istruzioni "base" hanno la maggior parte delle istruzioni AD ESECUZIONE CONDIZIONALE (su 16 diverse condizioni), hai presente che razza di spreco costituiscono a livello di "istruzioni usate poco frequentemente" ?
Poi l'ARM in origine non aveva istruzioni di shift "dedicate", ma è "nato" con un barrel shifter sul datapath del secondo operando e questo si riflette su parecchie istruzioni, anche qui decisamente poco da RISC avere buona parte delle istruzioni "con una modalità con shift" che in molti casi è poco usata.

Il motivo era che l'ARM fu progettato per essere efficiente e comodo da programmare, senza guardare a nessuna filosofia di progettazione particolare, ma fu commercializzato come RISC perchè allora era di moda.

Infatti la parte "più risc" dell'ARM è il set d'istruzioni Thumb/Thumb2 che è stato codificato tenendo conto della frequenza di utilizzo delle varie istruzioni e dei registri. Ma quello è stato aggiunto più di un decennio dopo ed anche li senza pregiudizi architetturali riguardo risc/cisc/ecc.


Il set di istruzioni Thumb è effettivamente qualcosa di molto utile in ambiti specifici ma, essendo a lunghezza variabile, condivide alcuni dei "difetti" delle CPU x86 (in particolare lato decoder) e quindi non mi stupirei se, in tale modalità, il processore consumasse qualcosa di più...

In realtà consuma leggermente di meno, le istruzioni più compatte comportano una riduzione delle letture dalla memoria esterna ed un maggior numero di istruzioni che stanno nella cache istruzioni
(ed il risparmio in termini di corrente per pilotare le linee di I/O "esterne" è notevole).
Se poi dai un occhiata agli opcode ed al formato delle istruzioni, le istruzioni Thumb si possono inviare direttamente al decoder ARM "vecchio" con uno schema di traduzione fisso che costa pochissimo in termini di implementazione.

chi si aspetta di vedere win8 su arm, penso che possa mettersi comodo dato che potrebbe non succedere mai :D

Fonte?

Tutta la dimostrazione che hanno fatto al CES con una macchina su architettura ARM funzionante cos'era?

ho detto potrebbe...comunque bisogna vedere le prestazioni finali

Fonte?

Tutta la dimostrazione che hanno fatto al CES con una macchina su architettura ARM funzionante cos'era?

e tu ci metti la mano sul fuoco?
ne abbiamo viste di presentazioni che alla fine erano tutta scena e non si sono mai avverate

e tu ci metti la mano sul fuoco?
ne abbiamo viste di presentazioni che alla fine erano tutta scena e non si sono mai avverate

Vado a intuito...

I tablet stanno avanzando con quote impressionanti, i netbook sono lontani dal definirsi morti, infine il recente accordo con Nokia, ...ciò mi fa pensare che W8 su arm, sia stato pensato a tutto tranne che essere abbandonato..

Poi non ho certo la sfera di cristallo...

Uno dei primi dogmi dei RISC è: niente istruzioni complesse o sprecare risorse per istruzioni che vengono usate poco frequentemente.
Gli ARM nel set d'istruzioni "base" hanno la maggior parte delle istruzioni AD ESECUZIONE CONDIZIONALE (su 16 diverse condizioni), hai presente che razza di spreco costituiscono a livello di "istruzioni usate poco frequentemente" ?
Poi l'ARM in origine non aveva istruzioni di shift "dedicate", ma è "nato" con un barrel shifter sul datapath del secondo operando e questo si riflette su parecchie istruzioni, anche qui decisamente poco da RISC avere buona parte delle istruzioni "con una modalità con shift" che in molti casi è poco usata.

Il motivo era che l'ARM fu progettato per essere efficiente e comodo da programmare, senza guardare a nessuna filosofia di progettazione particolare, ma fu commercializzato come RISC perchè allora era di moda.

Infatti la parte "più risc" dell'ARM è il set d'istruzioni Thumb/Thumb2 che è stato codificato tenendo conto della frequenza di utilizzo delle varie istruzioni e dei registri. Ma quello è stato aggiunto più di un decennio dopo ed anche li senza pregiudizi architetturali riguardo risc/cisc/ecc.

Questo è vero, il punto è che di processori RISC-puri sono stati davvero pochi: quasi tutti, pur attingendo a quella filosofia, sono in realtà dei post-RISC o comunque ibridi. Tuttavia, data l'ISA principale a dimensione degli opcode fissa, trovo più appropriato associare ARM a RISC piuttosto che ad altre filosofie.


In realtà consuma leggermente di meno, le istruzioni più compatte comportano una riduzione delle letture dalla memoria esterna ed un maggior numero di istruzioni che stanno nella cache istruzioni
(ed il risparmio in termini di corrente per pilotare le linee di I/O "esterne" è notevole).
Se poi dai un occhiata agli opcode ed al formato delle istruzioni, le istruzioni Thumb si possono inviare direttamente al decoder ARM "vecchio" con uno schema di traduzione fisso che costa pochissimo in termini di implementazione.

Si, però mi pare che questo è vero perchè Thumb lavora principalmente con bus a 16 bit, contro i 32 bit delle istruzioni principali. Sarebbe interessante testare la parte a 32 bit di Thumb2 per capire se il consumo aumenta o diminuisce...

Ciao. :)

Tuttavia, data l'ISA principale a dimensione degli opcode fissa, trovo più appropriato associare ARM a RISC piuttosto che ad altre filosofie.

Senza dubbio.
E comunque, ARM significa Advanced RISC Machines :)

Si, però mi pare che questo è vero perchè Thumb lavora principalmente con bus a 16 bit, contro i 32 bit delle istruzioni principali. Sarebbe interessante testare la parte a 32 bit di Thumb2 per capire se il consumo aumenta o diminuisce...


Thumb ha istruzioni "ottimizzate" per una dimensione di 16bit, ma sin dal principio girava su cpu con bus a 32bit.
L'ottimizzazione era pensata in primo luogo per ridurre le dimensioni del codice eseguibile per applicazioni embedded senza complicare troppo il core (infatti il decoder Thumb è quasi banale da implementare in piggyback su un decoder "ARM 32").
Le versioni "più ridotte all'osso" (es: M3) hanno solo le istruzioni Thumb (e relativo core ancora più semplificato), ma le istruzioni Thumb sono presenti anche nei modelli di fascia superiore.

Thumb2 aggiunge solo qualche istruzione che si è visto tornava utile e semplifica il "mixaggio" di codice "ARM a 32bit" e codice "Thumb a 16bit" (sono entrambi set d'istruzioni a 32bit, "a 32bit" e "a 16bit" è riferito solo alla dimensione più frequente delle istruzioni).

Thumb ha istruzioni "ottimizzate" per una dimensione di 16bit, ma sin dal principio girava su cpu con bus a 32bit.
L'ottimizzazione era pensata in primo luogo per ridurre le dimensioni del codice eseguibile per applicazioni embedded senza complicare troppo il core (infatti il decoder Thumb è quasi banale da implementare in piggyback su un decoder "ARM 32").
Le versioni "più ridotte all'osso" (es: M3) hanno solo le istruzioni Thumb (e relativo core ancora più semplificato), ma le istruzioni Thumb sono presenti anche nei modelli di fascia superiore.

Thumb2 aggiunge solo qualche istruzione che si è visto tornava utile e semplifica il "mixaggio" di codice "ARM a 32bit" e codice "Thumb a 16bit" (sono entrambi set d'istruzioni a 32bit, "a 32bit" e "a 16bit" è riferito solo alla dimensione più frequente delle istruzioni).

Ciao,
lavorare con istruzioni "ottimizzate" principalmente a 16 bit significa non solo compattare il codice, ma anche dover "accendere" solo la metà delle linee di comunicazione sul bus esterno (almeno per quanto riguarda il trasferimento delle istruzioni).
E' per questo che dicevo che Thumb2, più orientato verso i 32 bit, potrebbe trovarsi a consumare leggermente di più rispetto a Thumb (che a sua volta comunque deve pagare il costo della "decompressione" degli opcode a 16 bit in istruzioni a 32 bit).

Ovviamente poi andrebbe tutto quantificato... magari parliamo di scostamenti di consumo così bassi da essere insignificanti...

Qualche riferimento:
http://www.arm.com/products/processors/technologies/instruction-set-architectures.php?tab=Thumb+
http://www.arm.com/products/processors/technologies/instruction-set-architectures.php?tab=Thumb-2+

Ciao. :)