Samsung e ARM: tapeout di Cortex-A7 con processo FinFET a 14nm

Le due aziende annunciano di avere completato con successo l'ultima fase di sviluppo precedente alla produzione in volumi con il processo produttivo a 14 nanometri per la realizzazione di transistor tridimensionali FinFET
di Andrea Bai pubblicata il 22 Dicembre 2012, alle 09:31 nel canale ProcessoriSamsungARM
34 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infotant' è vero che anche un qualunque processore X86 attuale, all' accensione o al reset si avvia in modalità reale con segmentazione - e occorre codice per portarlo in modalità protetta prima o long mode poi
su un processore X86-64 con OS a 64 bit il sw a 32 gira "tranquillamente" anche in sandbox (quella dell' ambiente WoW64 o quella della VM hosted) perchè è il processore stesso a supportarne l' esecuzione, ma laddove si ricorra all' emulazione di un set di istruzioni non più supportato, dovendo sostituire il processo di decodifica hardware (prima svolto da una macchina a stati -avendo a che fare con istruzioni di lughezza variabile la decodifica è stateful- in logica cablata) con del codice (che sarà complesso, ricco di branch, quindi molto oneroso sull' unità di prediction e sulle cache) a sua volta fetchato e decodificato dall' hw, vi sarà inevitabilmente un overhead sostanziale
in termini di tempo (occupazione della cpu) o di spazio (occupazione di memoria)
inoltre, anche supponendo di poter impiegare tecniche tipo JIT, il runtime costituirebbe comunque un layer aggiuntivo che renderebbe l' esecuzione del codice emulato, meno deterministica - quindi in certi ambiti applicativi non sarebbe una soluzione praticabile
Un paio forse (e sopratutto perchè hanno usato codice gia pronto per alcune funzioni ordinarie).
uno dei motivi per cui il mercato ha decretato il succeso dell' architettura X86 facendola sopravvivere abbastanza da farla diventare standard industriale a dispetto della sua ineleganza - è proprio la sua caratteristica di autocompatibilità all' indietro (lato hw) e in avanti (lato sw)
la certezza di acquistare un processore forse meno potente (maanche meno costoso) di quello di una workstation o server basata su architettura proprietaria, ma capace di eseguire non solo l' ultima release dell' applicazione di alto profilo a 32 ( o adesso 64) bit, ma anche qualunque programma prodotto negli anni per la stessa pittaforma (di entrare quindi in uno sconfinato ambiente aperto)
in quest' ottica un processore "X86" 64 bit-only capace di far girare solo codice nuovo, a parte forse le prestazioni pure non avrebbe nulla di più di una CPU AArch64 (arm a 64 bit) - che peraltro resta compatibile con le modalità legacy ARM
per quanto strano possa sembrare, sarebbe proprio l' "evoluzione" che auspichi a spingere l' architettura intel in una nicchia...
tant' è vero che anche un qualunque processore X86 attuale, all' accensione o al reset si avvia in modalità reale con segmentazione - e occorre codice per portarlo in modalità protetta prima o long mode poi
il discorso non è così semplice...
su un processore X86-64 con OS a 64 bit il sw a 32 gira "tranquillamente" anche in sandbox (quella dell' ambiente WoW64 o quella della VM hosted) perchè è il processore stesso a supportarne l' esecuzione, ma laddove si ricorra all' emulazione di un set di istruzioni non più supportato, dovendo sostituire il processo di decodifica hardware (prima svolto da una macchina a stati -avendo a che fare con istruzioni di lughezza variabile la decodifica è stateful- in logica cablata) con del codice (che sarà complesso, ricco di branch, quindi molto oneroso sull' unità di prediction e sulle cache) a sua volta fetchato e decodificato dall' hw, vi sarà inevitabilmente un overhead sostanziale
in termini di tempo (occupazione della cpu) o di spazio (occupazione di memoria)
inoltre, anche supponendo di poter impiegare tecniche tipo JIT, il runtime costituirebbe comunque un layer aggiuntivo che renderebbe l' esecuzione del codice emulato, meno deterministica - quindi in certi ambiti applicativi non sarebbe una soluzione praticabile
semplicemente in fase di decodifica si traduce l' istruzione X87 (con il suo modello di indirizzamento dei registri "a stack"
non è una questione temporale - a quanto ne so, anche le esistensioni simd recenti che pur permettono calcoli massivi su numeri in virgola mobile (a 64 bit), non supportano la precisione estesa a 80 - che però in certi casi è necessaria...
credo si debbano guardare le cose in una prospettiva più ampia...
uno dei motivi per cui il mercato ha decretato il succeso dell' architettura X86 facendola sopravvivere abbastanza da farla diventare standard industriale a dispetto della sua ineleganza - è proprio la sua caratteristica di autocompatibilità all' indietro (lato hw) e in avanti (lato sw)
la certezza di acquistare un processore forse meno potente (maanche meno costoso) di quello di una workstation o server basata su architettura proprietaria, ma capace di eseguire non solo l' ultima release dell' applicazione di alto profilo a 32 ( o adesso 64) bit, ma anche qualunque programma prodotto negli anni per la stessa pittaforma (di entrare quindi in uno sconfinato ambiente aperto)
in quest' ottica un processore "X86" 64 bit-only capace di far girare solo codice nuovo, a parte forse le prestazioni pure non avrebbe nulla di più di una CPU AArch64 (arm a 64 bit) - che peraltro resta compatibile con le modalità legacy ARM
per quanto strano possa sembrare, sarebbe proprio l' "evoluzione" che auspichi a spingere l' architettura intel in una nicchia...
Concordo in tutto tranne che nella conclusione:
In passato abbiamo visto cambi di architettura molto radicali essere eseguiti discretamente, motorola 6800-ppc-i368 in casa apple per fare un esempio.
Ad ora abbiamo due produttori di cpu che spingono entrambi su architettura ibrida cpu-gpu, un produttore software che deve tutto il suo fatturato al mondo x86, e praticamente inesistente su architetture arm.
Queste condizioni possono far decollare una isa x64 in brevissimo tempo.
Portare tutti gli utenti "domestici" ad adottare la nuova architettura, per loro computer significa windows.
Il 99% delle software house sarebbero costrette ad abbracciare tale architettura (impensabile chiedere bottega per non migrare).
non esiste un prodotto di nicchia come da te definito, ad oggi (ma anche tra due-tre anni) significa lasciare il vuoto del 94% del mercato pc.
Arm non è ancora pronta per scalzare wintel da quel mercato, e wintel non ha la capacità di accedere a quote sostanziali di mercato tra i dispositi mobili.
Se oggi i computer (pc+portatili) hanno il 50% dei dispositivi connessi alla rete tra 4 anni saranno relegati al 30% e tra 8 anni saranno del tutto fuori mercato e relegati davvero ad un prodotto di nicchia, mentre arm continua ad erodere mercato anche tra i microserver per arrivare a costituire un ecosistema android-ios come terminali ed unità di elaborazione in remoto (cloud) per i calcoli massivi (praticamente torneremo all'epoca dei terminali stupidi che pilotavano software su mainframe).
Dico questo perchè vedo un continuo proliferare di dispositivi mobili che fanno girare software su server esterni senza che l'utente ne abbia la reale percezione.
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".