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

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 pubblicata il , alle 09:31 nel canale Processori
SamsungARM
 
34 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
jappilas26 Dicembre 2012, 15:27 #31
Originariamente inviato da: Ares17
Le istruzioni x86-x87 non sono più fondamentali come 2-3 anni fa.
volenti o nolenti le istruzioni a 16 e 32 bit sono quelle che definiscono l' architettura base - rispetto alla quale i 64 bit non sono altro che un' estensione
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
Un software che gira ancora con istruzioni a 32bit può essere tranquillamente eseguito in virtual machine a 32 bit senza perdita apprezzabile di prestazioni (considerando che erano scritte per processori molto meno performanti degli attuali).
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
Gia le istruzioni x87 sono eseguite sulle cpu AMD in una sorta di emulazione hardware,
semplicemente in fase di decodifica si traduce l' istruzione X87 (con il suo modello di indirizzamento dei registri "a stack", in una equivalente microstruzione "stackless" (col registro target indirizzato direttamente) che gli stadi successivi poi gestiscono consistentemente
ma quanti software recenti (scritti negli ultimi 5 anni) usano set x87 invece che simd?
Un paio forse (e sopratutto perchè hanno usato codice gia pronto per alcune funzioni ordinarie).
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...
Oramai il tempo è maturo per evolvere l'architettura, e se cio non avverrà l'architettura con isa intel sarà respinta in una nicchia di mercato talmente esigua da sparire del tutto nel giro di un decennio
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...
Ares1727 Dicembre 2012, 09:49 #32
Originariamente inviato da: jappilas
volenti o nolenti le istruzioni a 16 e 32 bit sono quelle che definiscono l' architettura base - rispetto alla quale i 64 bit non sono altro che un' estensione
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", in una equivalente microstruzione "stackless" (col registro target indirizzato direttamente) che gli stadi successivi poi gestiscono consistentemente
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.
Dcromato27 Dicembre 2012, 23:31 #33
Se vi può interessare sto usando uno smartphone con soc x86.per quanto mi riguarda l'impressione iniziale che avuto è stata una vera sorpresa.
Silversoulx8608 Gennaio 2013, 12:46 #34
Sta diventando un monopolio samsung in quasi tutti i settori o é solo una mia impressione??

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