Apple, ritornano le voci sul passaggio ad ARM per desktop e portatili

[LMCH]

Originariamente inviato da jappilas

per sviluppare implementazioni non ARM della isa ARM mi risulta occorra una licenza architetturale
licenza che intel possedeva (ereditò da Digital e usò per sviluppare le cpu XScale - e poi vendette a Marvell se non erro - e probabilmente si sarà mangiata le mani...) ma che AMD non mi risulta possieda...

Se non sbaglio AMD negli ultimi mesi ha acquisito la licenza per gli ARM.

Originariamente inviato da jappilas

le istruzioni simd della isa ARMv8 prevedono calcoli su registri a 128 bit (peraltro condivisi con le istruzioni FP scalari), ma un Core che un' ipotetica cpu di classe ARM a 64 bit dovrebbe eguagliare (anzi superare, altrimenti non ci sarebbe alcun incentivo alla migrazione) possiede unità capaci di calcoli su 256 bit per volta (doppio di GFlOPS)
inoltre, trattandosi di una ISA RISC con istruzioni a lunghezza fissa di 32 bit, da una parte questo può implicare un decoder più semplice (se non altro perchè non è necessario fare un matching parallelo su tutti i 16 byte provenienti da una cache line - che potrebbero ognuno essere il primo di una differente istruzione a lunghezza variabile - nè decodificare tutti i prefissi prima dell' opcode vero e proprio)
ma comunque non è detto, dovendo il decoder fare comunque i conti con una varietà di modalità operative, come thumb/thumb2/thumbeee con i suoi opcode a 16 bit, e di indirizzamento - a meno che queste non vengano escluse...

Quello di ARM Ltd mica sono nati ieri ed hanno considerato bene le alternative quando hanno fatto certe scelte.

Se si implementa l'esecuzione out-of-order si possono aggiungere più unita SIMD 128 ed avere le stesse prestazioni di una cpu con la metà delle unita SIMD 256, mentre dall'altro lato con 128bit per registro invece che 256bit diventa più semplice realizzare una versione "risparmiosa" con buone prestazioni.

Poi un decoder capace di interpretare sia istruzioni "ARM 32bit" che thumb è estremamente semplice rispetto ad uno solamente "ARM 32bit", perchè le istruzioni thumb si mappano "a schema fisso" in modo estremamente semplice sulle istruzioni ARM equivalenti quindi in una cpu che supporta entrambi, il "decoder thumb" è solo uno stadio aggiuntivo al decoder "ARM 32bit" e tale stadio aggiuntivo non è a rischio di stalli ed automagicamente circa raddoppia le istruzioni inviabili in esecuzione senza praticamente andare a toccare tutto quello che c'è a valle.

[birmarco]

Originariamente inviato da LMCH

Se non sbaglio AMD negli ultimi mesi ha acquisito la licenza per gli ARM.



Quello di ARM Ltd mica sono nati ieri ed hanno considerato bene le alternative quando hanno fatto certe scelte.

Se si implementa l'esecuzione out-of-order si possono aggiungere più unita SIMD 128 ed avere le stesse prestazioni di una cpu con la metà delle unita SIMD 256, mentre dall'altro lato con 128bit per registro invece che 256bit diventa più semplice realizzare una versione "risparmiosa" con buone prestazioni.

Poi un decoder capace di interpretare sia istruzioni "ARM 32bit" che thumb è estremamente semplice rispetto ad uno solamente "ARM 32bit", perchè le istruzioni thumb si mappano "a schema fisso" in modo estremamente semplice sulle istruzioni ARM equivalenti quindi in una cpu che supporta entrambi, il "decoder thumb" è solo uno stadio aggiuntivo al decoder "ARM 32bit" e tale stadio aggiuntivo non è a rischio di stalli ed automagicamente circa raddoppia le istruzioni inviabili in esecuzione senza praticamente andare a toccare tutto quello che c'è a valle.

Eh fino a questo punto direi che è difficile fare previsioni Vedremo nei prossimi mesi

[birmarco]

Sembra uscito apposta http://www.tomshw.it/cont/news/il-bo...l/40902/1.html

[jappilas]

Originariamente inviato da LMCH

Se non sbaglio AMD negli ultimi mesi ha acquisito la licenza per gli ARM.

spulciando in giro non trovo nulla che parli esplicitamente dell' acquisto di una licenza architetturale
solo che AMD introdurrà opteron basati su ARM (ma probabilmente basati sui core sintetizzabili di quest' ultima, non su design propri)

Quello di ARM Ltd mica sono nati ieri ed hanno considerato bene le alternative quando hanno fatto certe scelte.

ma nemmeno quelli di intel sono nati ieri - e lo dico storcendo il naso di fronte ad una ISA tutto fuorchè elegante (anche di CISC ci sono esempi di gran lunga migliori, a partire da z8k e 68k) ma (purtroppo) oggi disponibile in forma molto potente

il fatto è che che gli uni e gli altri si sono dati differenti priorità - in un caso retrocompatibilità ad ogni costo (compresa a livello di assembly simbolico tra l' 8080/z80 e l' 8086 - quest' ultimo progettato così come fu anche perchè fosse possibile tradurre 1 a 1 il sw usato sui micro con cp/m, con un tool automatico) inizialmente e prestazioni (anche a discapito dei consumi) più di recente, nell' altro caso semplicità architetturale a discapito delle prestazioni pure
non che quest' ultimo implichi alcunchè rispetto al livello di capacità - anche se è innegabile che le risorse di intel e quelle di arm siano su due livelli diversi, a quel punto un design semplice è favorevole in ottica di manutenibilità (infatti da parte di ARM si sente parlare di errata molto meno che da altri produttori...) - è semplicemente un approccio diverso al compromesso tecnico

Se si implementa l'esecuzione out-of-order si possono aggiungere più unita SIMD 128 ed avere le stesse prestazioni di una cpu con la metà delle unita SIMD 256, mentre dall'altro lato con 128bit per registro invece che 256bit diventa più semplice realizzare una versione "risparmiosa" con buone prestazioni.

un sommatore da 256 bit e due sommatori da 128, richiedono grossomodo lo stesso numero di transistor - però limitatamente alla/e ALU, il problema è che oltre alla doppia ALU nel secondo caso si ha anche il doppio delle porte in uscita dallo scheduler (code), il doppio delle strutture dati per il register renaming, la complessità delle rete di bypass cresce se non ricordo male esponenzialmente
e ho in ogni caso bisogno, a monte, di due istruzioni decodificate da inviare alle ALU, quindi due decoder distinti e il doppio della banda...

Poi un decoder capace di interpretare sia istruzioni "ARM 32bit" che thumb è estremamente semplice rispetto ad uno solamente "ARM 32bit", perchè le istruzioni thumb si mappano "a schema fisso" in modo estremamente semplice sulle istruzioni ARM equivalenti quindi in una cpu che supporta entrambi, il "decoder thumb" è solo uno stadio aggiuntivo al decoder "ARM 32bit" e tale stadio aggiuntivo non è a rischio di stalli

che sia semplice non lo metto in dubbio,
quello di cui sopra però era un discorso di decoder- e pipeline - "lanes" (quindi di decoder paralleli presenti e impegnati da una parte, e di istruzioni dall' altra) necessarie per svolgere lo stesso lavoro

automagicamente circa raddoppia le istruzioni inviabili in esecuzione senza praticamente andare a toccare tutto quello che c'è a valle.

come?
tipicamente un decoder è UN decoder - se è fatto in un certo modo per decodificare e passare allo stadio successivo una istruzione alla volta perchè una istruzione alla volta è quanto lo stadio successivo è in grado di accettare (che è la situazione tipica per una pipeline improntata alla semplicità e regolarità strutturale, come appunto un risc inorder) ne decodificherà sempre al più una per ciclo, che sia a 16 o 32 bit - a meno che non hai informazioni specifiche su ARM/thumb che mostrino che a 16 bit le istruzioni decodificate raddoppiano...

[LMCH]

Originariamente inviato da jappilas

tipicamente un decoder è UN decoder - se è fatto in un certo modo per decodificare e passare allo stadio successivo una istruzione alla volta perchè una istruzione alla volta è quanto lo stadio successivo è in grado di accettare (che è la situazione tipica per una pipeline improntata alla semplicità e regolarità strutturale, come appunto un risc inorder) ne decodificherà sempre al più una per ciclo, che sia a 16 o 32 bit - a meno che non hai informazioni specifiche su ARM/thumb che mostrino che a 16 bit le istruzioni decodificate raddoppiano...

Ho parlato di raddoppio delle istruzioni inviabili in esecuzione, non in raddoppio tout court delle istruzioni eseguite (dipende se basta la compressione del codice o se si hanno gate da spendere in ulteriori migliorie).

Ma anche senza modifiche a valle, si ottengono comunque parecchi benefici.
In modalità thumb la cache istruzioni L1 contiene fino ad un massimo del doppio delle istruzioni e si riducono gli stalli dovuti all'accesso ai livelli successivi di cache (meno accessi da parte della cache istruzioni L1 che vanno ad interferire con quelli della cache dati L1).