![Show Menu](styles/mobile-menu.png)
![Page Background](./../common/page-substrates/page0068.png)
EMBEDDED
56 • maggio • 2015
software
|
CODING GUIDELINE
68
hanno avviato la procedura di impostazione del-
le condizioni sotto le quali permettere specifiche
deroghe dalla piena conformità a MISRA.
La spinta a questo lavoro è quella di definire un
set di deroghe dalle regole che siano strettamen-
te vincolate allo scopo. Un importante primo
stadio è quello di categorizzare le motivazioni di
massima per una deviazione dalla regola di non
conformità.
Ca
tegorizzazione del
le ragioni di deroga
Suddividendo le deviazioni nelle seguenti cate-
gorie, le difficoltà pratiche relative alla confor-
mità appaiono più evidenti. Inoltre, questa ca-
tegorizzazione vigila sulle deroghe inadeguate
e sull’indebolimento degli intenti della codifica
standard.
Performance:
potrebbe sembrare strano e non
intuitivo suggerire le prestazioni come motivo
per non seguire delle buone pratiche di codifica,
ma la seguente situazione presa dalla realtà è la
dimostrazione dell’esigenza:
Quale parte del sistema di controllo del
motore del veicolo, una variabile di tem-
porizzazione necessita di essere accu-
mulata a intervalli regolari. Il codice,
correttamente formulato per soddisfare
MISRA-C:2012 Rule 10.6 (value not to be
assigned to a wider type, legge:
extern uint16_t qty, time_step;
uint32_t prod = ( uint32_t ) qty * ( uint32_t
) time_step;
I cast assicurano che gli operandi 16-bit
non andranno in overflow nella moltipli-
cazione 32-bit per questo compiler. Tut-
tavia, il compiler esegue questa opera-
zione utilizzando la modalità “shift and
add” di long multiplication piuttosto che
la modalità IMUL (signed multiplica-
tion) con cui è equipaggiata. I fornitori
di compiler anno chiarito che la modali-
tà IMUL si verifica soltanto in conversio-
ni implicite, richiedendo all’espressione
di leggere:
uint32_t prod = qty * time_step; // deviate
from Rule 10.6
Permettendo una implicita conversione
in questo caso, il funzionamento del ci-
clo IMUL singolo clock è garantito, in-
vece che l’esecuzione dei ~100 peggiori
casi di clock cycle del precedente, quindi
giustificando una deviazione controllata
sulla base delle performance.
Codice esterno (terze parti):
questa catego-
ria include librerie comuni, codice autogenerato,
e moduli di codice interno ereditato o anche solo
una funzione complessa che comprenda un al-
goritmo di applicazione chiave. I maintainer di
librerie di dominio pubblico, dato il loro ampio
ambito di applicazione, raramente hanno moti-
vazione ad adeguarsi a MISRA o ad altri stan-
dard di codifica. Il Codice autogenerato, a meno
che non soddisfi uno standard di sicurezza fun-
zionale come ISO 26262, intrinsecamente con-
terrà probabilmente delle violazioni a MISRA.
Il codice ereditato potrebbe predatare l’adozio-
ne di MISRA nel progetto. L’analisi di impatto
di possibili rifacimenti per adeguarsi alle re-
gole MISRA potrebbe essa stessa essere causa
di preoccupazioni. Il safety case in tutte queste
situazioni si basa sulla dipendenza “qualificato
attraverso l’uso” in combinazione con altre spe-
cifiche misure di qualità.
Build Configuration:
una caratteristica pe-
culiare delle applicazioni dei fornitori automo-
bilistici è quella di rendere disponibile molte
varianti di una singola base di codice in funzio-
ne delle necessità del cliente. Piuttosto che un
controllo a livello di generazione di queste con-
segne, meccanismi di configurazione vengono
distribuiti per controllare l’esecuzione delle spe-
cifiche funzionalità per ogni variante. Di conse-
guenza, l’adeguamento a MISRA può risentirne
in termini di ridondanza del codice, invarianza
delle espressioni, e questioni complessivamente
collegate.
Accesso all’hardware:
al fine di accedere ai
registri, risolvere interrupt di controllo e memo-
ria assoluta, gli sviluppatori embedded devono