Quote:
Originariamente inviato da LMCH
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.
|
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.
Quote:
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.
|
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.
