Newsgroup: it.comp.lang.c++
Titolo: Variabili mappate in memoria

salve,
sto utilizzando IAR WorkBench per la stesura di un programma per 
processore XScale.
Mi sono imbattuto nel seguente codice:
__root __no_init volatile char valore @ 0x4000000;	
credo che sia un modo per indicare al compilatore di allocare la 
variabile valore all'indirizzo 0x4000000. In questo modo, immagino, il 
compilatore non andrà mai ad allocare quell'area di memoria per altri scopi.
vorrei chiedere se questo metodo fa parte dello standard C/C++ oppure se 
fa solo parte di una versione particolare per questi microprocessori.
saluti,


Sono direttive specifiche di IAR, assolutamente non standard.
__root è una keyword per definire una variabile che *deve* sempre essere
inclusa, __no_init significa che la variabile deve essere posta in memoria
non volatile (nei MC quasi sempre e' Flash ROM o spazio periferiche)
Il tutto significa quello che giustamente presumi.
La presenza di volatile potrebbe lasciare presumere che si tratti di un 
registro
di una periferica READ-ONLY.
B.

 > Sono direttive specifiche di IAR, assolutamente non standard.
 > __root è una keyword per definire una variabile che *deve* sempre essere
 > inclusa, __no_init significa che la variabile deve essere posta in 
memoria
 > non volatile (nei MC quasi sempre e' Flash ROM o spazio periferiche)
 > Il tutto significa quello che giustamente presumi.
 > La presenza di volatile potrebbe lasciare presumere che si tratti di un
 > registro
 > di una periferica READ-ONLY.
Grazie Mille! Sei stato molto esaustivo! In realtà quella variabile 
"valore" rappresenta un dato che deve essere comunque aggionato, quindi 
dovrebbe essere errato il "volatile", o no? Infine che significa che 
*deve* essere sempre inclusa? No verrebbe comunque inclusa? :-)
Saluti,

 inclusa? :-)
No, va bene cosi! Il volatile forza il compilatore a non ottimizzare gli 
accessi
alla locazione in questione: se fosse una normale locazione di ram che 
viene
solo letta, ad esempio, il compilatore in qualche punto del codice potrebbe
presumere che basta leggere il valore una volta e tenerselo in un 
registro invece
che accederci fisicamente ogni volta come richiesto: questo sarebbe 
estremamente
dannoso se la locazione fosse in realta' un registro di una periferica o 
una locazione
di una shared o dual port ram che puo' cambiare di volta in volta e 
quindi *deve*
essere acceduta *sempre*...Oppure, in scrittura, se il compilatore si 
accorgesse
che si va a scrivere sempre lo stesso valore, potrebbe decidere di farlo 
una sola
volta ed eliminare, errando ad ottimizzare, tutte le scritture 
successive .....
Il *deve* e' la semantica del token: e' una direttiva imperativa che forza
il compilatore a fare esattamente quanto richiesto *anche* se risultasse
che a quella locazione fosse mappato qualche cosa d'altro.
B.

 che a quella locazione fosse mappato qualche cosa d'altro.
esaustivo come sempre! ;-)
grazie!

> > di una periferica READ-ONLY.
O modificata da un altro processo o interrupt.

HappyCactus ha scritto:

Si, ma il compilatore di per se' non conosce processi ne' interrupt (al
limite, per gli interrupt, ha dei token specifici non standard per
inserire un prologo /epilogo diverso dalle funzioni normali)
Il token "volatile" invece e' assolutamente standard ed indica solo
che l' accesso alla locazione deve essere sempre fatto senza ottimizzare
nulla: questo serve per accessi di locazioni che contengono appunto
valori 'volatili': che siano cambiati per cause hardware, interrupt, 
processi
o altro, poco importa: il compilatore sa' che deve sempre accedere alla
variabile in questione.
B.

 variabile in questione.
Facevo solo riferimento al fatto che affermi che il volatile fa
presumere l'accesso ad una periferica read only (se non ho travisato la
frase di cui sopra.)