ARM e la strada che porta ai 64-bit

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.

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.

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.



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.

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

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...

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.



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.

Senza dubbio.
E comunque, ARM significa Advanced RISC Machines