ARM e la strada che porta ai 64-bit

ARM e la strada che porta ai 64-bit

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

di pubblicata il , alle 14:37 nel canale Private Cloud
ARM
 
22 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
shodan11 Febbraio 2011, 11:29 #11
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

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.
LMCH12 Febbraio 2011, 00:19 #12
Originariamente inviato da: Pleg
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).
shodan12 Febbraio 2011, 10:57 #13
Originariamente inviato da: LMCH
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.
LMCH13 Febbraio 2011, 00:43 #14
Originariamente inviato da: shodan
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.

Originariamente inviato da: shodan
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.
Pier220413 Febbraio 2011, 01:02 #15
Originariamente inviato da: focuswrc
chi si aspetta di vedere win8 su arm, penso che possa mettersi comodo dato che potrebbe non succedere mai


Fonte?

Tutta la dimostrazione che hanno fatto al CES con una macchina su architettura ARM funzionante cos'era?
focuswrc13 Febbraio 2011, 12:16 #16
ho detto potrebbe...comunque bisogna vedere le prestazioni finali
bongo7413 Febbraio 2011, 12:20 #17
Originariamente inviato da: Pier2204
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
Pier220413 Febbraio 2011, 12:41 #18
Originariamente inviato da: bongo74
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...
shodan14 Febbraio 2011, 13:28 #19
Originariamente inviato da: LMCH
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.
Pleg15 Febbraio 2011, 04:40 #20
Originariamente inviato da: shodan
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

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^