di  -  mercoledì 25 novembre 2009

Nei precedenti articoli abbiamo avuto modo di apprezzare l’architettura ARM, analizzandone caratteristiche peculiari e funzionalità, focalizzando l’attenzione sugli elementi che l’hanno contraddistinta e sulle modifiche apportate dalla casa madre nel corso degli anni.

Il 2005 segna l’introduzione di una nuova famiglia di microprocessori, con la quale ARM introduce novità, ma anche un po’ d’ordine fra le varie sigle, famiglie, architetture, estensioni, riduzioni e quant’altro abbia contribuito a generare confusione fra una moltitudine di prodotti e relative etichette.

Cortex, questo il suo nome, è presente in tre gruppi, ognuno contraddistinto da una lettera che ne richiama l’appartenenza: Application (A), Realtime (R) e Microcontroller (M).

L’idea è quella di avere un core comune da specializzare specificamente in base al target d’utilizzo. Il più ricco è il gruppo A, che include tutta una serie di caratteristiche ed estensioni necessarie per l’utilizzo in ambito “tradizionale” (desktop, server, smartphone): Thumb-2, Thumb-EE (Jazelle RCT; per Java e altri linguaggi dotati di Virtual Machine), Vector Floating Point (VFP, per calcoli in virgola mobile), Advanced SIMD (NEON), cache L1 ed L2, PMMU e TrustZone (per la sicurezza e i DRM).

Il gruppo R è pensato per le applicazioni realtime, per le quali la maggior parte di queste funzionalità non è necessaria. Thumb-2 viene implementato ed eventualmente l’unità VFP, per le cache c’è spazio per selezionarne la configurazione, e infine per la protezione della memoria è opzionalmente disponibile un’unità estremamente ridotta (l’MPU, che integra soltanto alcune caratteristiche della ben più complessa PMMU).

Infine il gruppo M, essendo dedicato ai microcontrollori, implementa soltanto il Thumb-2, non è prevista nessuna cache, e l’unità MPU è opzionale. E’ interessante notare che implementando esclusivamente l’ISA Thumb-2, si elimina la classica e tradizionale ARM. La CPU diventa, quindi, a tutti gli effetti un CISC, come abbiamo avuto modo di appurare nel precedente articolo parlando di questa nuova ISA.

Rispetto alla versione 6 dell’architettura le novità di rilievo sono le seguenti:

  • NEON, un’unità SIMD dedicata al calcolo di operazioni su vettori di 64 o 128 bit (su registri dedicati) contenenti valori interi (16 o 32 bit) o in virgola mobile (a precisione singola, 32 bit), che opera in maniera indipendente dalla pipeline principale (dalla quale comunque attinge le istruzioni da eseguire)
  • VFPv3, che raddoppia il numero di registri (portandoli a 32) dell’unità di esecuzione in virgola mobile e aggiunge qualche nuova istruzione
  • Thumb-EE, una versione derivata da Thumb-2 nata per soppiantare Jazelle (la precedente tecnologia per accelerare l’esecuzione di codice Java) e utilizzata per implementare il nuovo modello di esecuzione per macchine virtuali chiamato Jazelle RCT
  • TrustZone, che introduce una nuova modalità di esecuzione definita secure per implementare l’esecuzione di codice “fidato” (trusted, che in genere fa ricorso a certificati) e meccanismi di Digital Rights Management (DRM)
  • pipeline superscalare costituita da 13 stadi e in grado di eseguire due istruzioni in-order

Notiamo subito un punto di rottura col passato rappresentato dal fatto che l’approccio usato in precedenza per implementare funzionalità di tipo SIMD è stato molto più “morbido”, modificando il core aggiungendo nuovi flag e istruzioni per accomodare l’applicazione di operazioni (in genere dello stesso tipo) su più dati al medesimo tempo, ma continuando a sfruttare i registri del processore.

Altro cambiamento sensibile è dovuto alla sostanziale rimozione della vecchia modalità Jazelle. In realtà viene mantenuta per retrocompatibilità, ma nessun bytecode viene accelerato in hardware: ognuno di essi comporta l’invocazione dell’handler che si dovrà occupare della sua interpretazione e relativa esecuzione. Al posto di Jazelle si sfrutta una modifica a Thumb-2, che offre un ambiente più flessibile e generale (non legato esclusivamente a Java).

Non sarà gradita a molti, invece, la soluzione rappresentata da TrustZone. Quanti avevano pensato di abbandonare x86 & affini a causa della famigerata tecnologia Trusted Computing o Palladium, confidando quindi nella “liberazione” grazie ad ARM, si ritroveranno già ad ardere nella brace del software “trusted, magari senza neppure saperlo e addirittura vantandosi dell’acquisto.

Ma il futuro, checché se ne dica e ci si stracci le vesti, è rappresentato da questi meccanismi che non sono e non vanno visti esclusivamente in ottica “liberticida”. Per cui il mio personale consiglio ai “fanatici integralisti” è quello di farsene una ragione fin d’ora e accettare quella che sarà, alla fine dei conti, la realtà (che non è buia e triste come credono) con cui avremo tutti a che fare…

Piacevolissimo e sicuramente apprezzato da tutti è stato, invece, l’arrivo della superpipeline. A vent’anni dall’introduzione del primo esemplare della famiglia, e dopo che tante altre case sono saltate sul carro dell’esecuzione di più istruzioni per ciclo di clock, ARM compie un passo storico e sceglie la soluzione che, 12 anni prima, ha reso famoso il Pentium di Intel: eseguirne due in ordine.

Non che fosse impossibile farlo prima, sia chiaro, ma considerato il mercato di riferimento di Acorn prima e di ARM Ltd poi, la ricerca delle prestazioni elevate a tutti i costi non era certo uno dei suoi obiettivi, per cui ha preferito conservare le peculiarità della sua architettura (in primis un core ridotto all’osso: sui 35mila transistor circa), aggiornandola, estendendola, passando a processi produttivi migliori e innalzando il clock.

Certamente negli ultimi anni e con la sempre più larga e variegata adozione dei suoi microprocessori, è diventato sempre più pressante per lei aumentarne la velocità di esecuzione. Infatti uno dei suoi cavalli di battaglia, la pipeline corta (appena 3 stadi), era stato sacrificato già da qualche tempo sull’altare della frequenza del clock.

Si sono già viste, infatti, CPU con pipeline lunghe da 5 fino a 9 stadi, e sappiamo bene i problemi che ciò comporta: il rischio di uno svuotamento della pipeline con relativo nuovo caricamento delle istruzioni è sempre dietro l’angolo, e il decadimento prestazionale assicurato.

I Cortex segnano il record assoluto per questa famiglia, arrivando a ben 13 stadi. Tanti (troppi, direi io, considerata la sua storia), se pensiamo che un vecchio Athlon ne aveva 10, e 12 i più recenti Athlon64. Ciò ha richiesto l’introduzione di meccanismi di branch prediction efficaci (una global history di 512 entry, un branch target di 4096 a 2 bit, e un return stack di 8).

ARM dichiara il 95% di predizioni corrette: un risultato di tutto rispetto, che garantisce un ottimo livello di prestazioni raggiunte. A titolo di confronto, un Athlon raggiunge gli stessi risultati, ma con una branch history di 2048 entry, un branch target di altrettanti elementi, e un return stack di 12.

C’è però da dire che gli Athlon hanno raggiunto frequenze elevatissime (2,3Ghz con un modello della serie Barton) considerati gli appena 10 stadi e il fatto che si siano fermati a un processo produttivo “da preistoria” (130nm), mentre i Cortex-A8 (primi rappresentanti di questa famiglia) finora hanno toccato il Ghz, ma credo ci sarà ancora molto spazio per scalare in frequenza.

Tornando alla pipeline superscalare, l’implementazione in-order è molto semplice: la prima istruzione viene smistata alla prima ALU (la 0) e quella seguente alla seconda (ALU 1). Può sembrare una forte limitazione, ma entrambe le ALU possono eseguire qualunque operazione (a parte la moltiplicazione, affidata soltanto alla prima, ma si tratti di un’operazione rara) e possono accedere all’unità di Load/Store.

Si tratta di un design conservativo, ma anche molto semplice e poco costoso da implementare, che può garantire un buon miglioramento prestazionale specialmente se i compilatori faranno il loro dovere cercando di ridurre le dipendenze dei risultati e smistando le istruzioni alle due ALU in maniera ottimale.

Concludendo possiamo dire che con la famiglia Cortex-A8 ARM si rende sicuramente più aggressiva nei confronti di realtà più blasonate, che se prima dominavano incontrastate e indisturbate nei segmenti desktop e server, adesso devono fare i conti con una soluzione che presenta un eccellente rapporto fra prestazioni e costumi, e che in futuro, specialmente con le versioni multicore, è destinata a ritagliarsi sempre più spazio

11 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    jpx
     scrive: 

    Articolo interessante, grazie!

    ARM mi sta convincendo sempre di più, non solo a livello di processori, ma anche di GPU e acceleratori video in genere (so che internamente stanno testando un “mostro” composto da 4 core Cortex A9 e 4 core GPU Mali400MP!!!)

  • # 2
    Daniele
     scrive: 

    ARM sembra spettacolare e la stiamo aspettando in molti tuttavia sembra che le soluzioni basate su questa piattaforma tardino ad arrivare. Pur essendoci una vasta scelta di prodotti che sulla carta promettono molto bene (Tegra e Zii in testa ma anche i processori di TI, Freascale e Qualcomm) i produttori sembrano in attesa, personalmente non capisco se queste reticenze siano causate dalla paura di esporsi in tempo di crisi, dalla mancanza di un OS maturo, da un mercato ancora non sufficientemente informato su cosa cambi tra un netbook (o un pc) x86 o ARM o da altri fattori.
    I Sony della serie Vaio P sono uno spettacolo, facessero qualcosa del genere con ARM lo comparerei al volo.

  • # 3
    Giacomo
     scrive: 

    Sull’avanzata ineluttabile dei processori TC non ci farei una scommessa.. tra qualche anno usciranno i processori dei cinesi e degli indiani, che non hanno le paranoie americane su TC, copyright e compagnia bella, e le ditte americane non potranno più spadroneggiare come fanno ora, per cui secondo me la partita è tutta da giocare.

  • # 4
    Cesare Di Mauro (Autore del post)
     scrive: 

    Intanto ancora non ci sono o comunque sono insignificanti per il mercato.

    Per il resto penso che si allineeranno anche loro, perché la tecnologia TC offre indiscutibili benefici per chi vuol realizzare un ambiente più sicuro e non gli basta affidarsi a soluzioni esclusivamente software perché alla fine si riescono a crackare.

  • # 5
    RSV4
     scrive: 

    Inoltre quando i sistemi TC saranno abbastanza diffusi e i servizi online piu importanti tra cui banche e istituzioni inizieranno ad usarlo i sistemi non TC saranno tagliati fuori.

    Immagina al mediaworld:

    Cliente: Perche questo PC cinese costa meno?
    Commesso: Perche non ha il TC, questo significa che non potrà collegarsi alla banca, usufruire dei servizi online delle PA, scaricare i suoi referti dall’ospedale, fare pagamenti e transazioni sicure e molto altro.
    Cliente: Ma col TC posso scaricare lo stesso MP3 dal mulo?
    Commesso: Si.

    A quel punto è evidente che anche a fronte di un prezzo superiore la maggior parte dei clienti prenderà il sistema TC mentre le aziende che fanno sistemi non TC resteranno tagliate fuori e chiuderannno.

  • # 6
    Giacomo
     scrive: 

    “Cliente: Ma col TC posso scaricare lo stesso MP3 dal mulo?
    Commesso: Si.”

    Stai scherzando, vero?
    La ragione inconfessata dell’ambaradan TC è proprio quello di segare la circolazione illegale di materiale protetto, altro che referti dall’ospedale e pagobancomat..
    e poi pensare che un’unica infrastruttura mondiale decida quale software possa girare e quale no è assolutamente utopistico, gli USA tanto per cambiare vorrebbero andarlo a dirigere e gli altri paesi non lo permetterebbero mai..

  • # 7
    RSV4
     scrive: 

    Un sistema TC puo far funzionare sia software Trusted che Untrusted e il software Untrused non puo interagire con i componenti Trusted.

    Questo significa che sul tuo sistema TC potrai comunque installare Emule e scaricare quello che ti pare.

    Pero non potrai con un browser Untrusted accedere a un servizio online Trusted, ne potrai con un editor Untrusetd modificare dei file Trusted e via dicendo.

    Non ci sara nessuna infrastruttura mondiale che decida quale software possa girare e quale no, sul tuo PC installerai comunque quello che ti pare.
    Lo scopo è quello di creare delle aree Trusetd in cui scambiare dati in modo sicuro e ci sara un’infrastruttura che decidera quali software potranno entrare in queste aree e quali no, com’è giusto che sia.

  • # 8
    Giacomo
     scrive: 

    un domani che riuscissero a far passare quel sistema misto direbbero: già che ci siamo facciamo girare solo SO trusted, così automaticamente dentro ci gira solo software trusted.. la tentazione sarebbe troppo forte, e spero che non si arrivi mai a quel giorno.

  • # 9
    Cesare Di Mauro (Autore del post)
     scrive: 

    Questo è lo spauracchio che viene tirato in ballo quando si parla di TC, ma è assolutamente utopistico, e per tre motivi.

    Primo perché il TC, come da specifiche, si può disabilitare, e quindi potrà far girare qualunque software si voglia.

    Secondo, come ha ricordato RSV4, in un ambiente trusted possono girare applicazioni trust e non trusted. Quindi ci sono soltanto vantaggi.

    Terzo perché il TC non può violare le leggi degli stati sovrani.

    Comunque su TC & co. preferisco parlarne in un futuro articolo. Qui ne ho accennato soltanto perché fa parte della nuova CPU di ARM, ma l’argomento rimane il Cortex-A8. ;)

  • # 10
    pleg
     scrive: 

    @ Cesare

    Troppi 13 stadi?
    E cosa dirai, quando raggiungeranno i 2 GHz e andranno in Out-Of-Order?
    :)

    Purtroppo per aumentare le prestazioni c’e’ poco da fare, quella e’ la strada, e’ da vedere se fara’ prima ARM ad aumentare le performance o Intel ad abbassare i consumi. I prossimi anni saranno interessanti :)

  • # 11
    Cesare Di Mauro (Autore del post)
     scrive: 

    I prossimi anni ARM non avrà tutto quel vantaggio che ha adesso in termini di dimensione del core e consumi, grazie, oltre alle cose che hai citato, all’adozione di processi produttivi sempre più piccoli, all’integrazione di notevoli quantità di cache e di unità SIMD che faranno lievitare notevolmente il numero di transistor per qualunque CPU “desktop” & co.

    A questi livelli avrà poco senso parlare di vantaggio di un core piccolo che occupa 50-60mila transistor. :D

    Comunque che la strada sia quella per aumentare le prestazioni non lo metto in dubbio e ne sono perfettamente cosciente. E’ che mi fa un po’ senso vedere come si è arrivati da un’architettura semplice che ne usava 3, a ben 13 stadi di pipeline. :|

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.