Was heißt __IO beim GCC

[Philipp (Gast)]

Im Manual finde ich nichts darüber und Google läßt mich auch dumm 
sterben :-(

Philipp

[Naja (Gast)]

Für sowas gibt es Suchmaschinen.
Du schreibst was von "Google". Das ist auch eine Suchmaschine.
Klick einfach auf den ersten Link.

[Philipp (Gast)]

Danke für die Antwort. Wenn ich was brauchbares im Google gefunden 
hätte, dann würde ich hier nichts posten ;-)

Philipp

[yalu (Gast)]

__IO ist ein Identifier und kann bspw. als Variablen-oder Funktionsname
verwendet werden.

Oder hast du den Eindruck, __IO wäre irgendetwas Besonderes, vielleicht
Compilerspezifisches? Wenn ja, wie entstand dieser Eindruck?

[Jörg W. (dl8dtl) (Moderator)]

__IO ist erst einmal ein reservierter Bezeichner.  Reserviert ist
er "for the implementation", d. h. die Gesamtheit aus Compiler und
Systembibliothek(en).

Der GCC selbst benutzt __IO nicht (zumindest nicht Version 4.3.1),
insofern dürfte es eher was aus der Systembibliothek sein.  Dafür
wiederum müsstest du uns verraten, auf welchem System / in welcher
Umgebung dein GCC so läuft.

[Hc Z. (mizch)]

> Oder hast du den Eindruck, __IO wäre irgendetwas Besonderes, vielleicht
> Compilerspezifisches? Wenn ja, wie entstand dieser Eindruck?

Möglicherweise entstand er dadurch, dass Variablen, die mit __ beginnen, 
beim Winzigweich-Compiler für deren private Verwendung reserviert sind.

In den AVR-Header-Files findet sich nirgends ein __IO.

[Philipp (Gast)]

Also ich verwende einen Cortex-Me von ST mit GCC als Compiler. Mit IO 
verbinde ich eigentlich aus der 8-Bit Zeit, daß es um den IO Bereich 
geht, aber das kann hier nicht stimmen.

So sieht der Codeteil aus :

__IO uint32_t NbrOfPage = 0x00;

Wobei es für mich insofern keinen Sinn ergibt, weil die Variable nur als 
Schleifenvariable genützt wird. Ich habe nur einen Verdacht im Internet 
gefunden, daß es dabei um eine Registervariable geht.

Philipp

[Jörg W. (dl8dtl) (Moderator)]

Das müsste sich in der Spezifikation deines konkreten Compilers
finden.  Kann schon sein, dass damit ein IO register space gemeint
ist, und dass man die Schleifenvariable halt in einen solchen legen
lässt, weil der Zugriff auf den IO space besonders schnell ist.

Das ist aber nur eine Vermutung meinerseits, ich habe keinen blassen
Schimmer, wie so ein Cortex arbeitet.

[Martin T. (mthomas) (Moderator)]

>Im Manual finde ich nichts darüber und Google läßt mich auch dumm
>sterben :-(
Welches Manual?

Wie auch immer: __IO ist in core_cm3.h (Teil von CMSIS) so definiert:

#define     __IO    volatile

steckt also kein Geheimnis dahinter.

>Also ich verwende einen Cortex-Me von ST mit GCC als Compiler.
In der StdPerLib für STM32 von ST ab V3.0.0 sind die CMSIS Dateien 
enthalten. Suche nach Zeichenkette __IO in den Dateien von STM hätte 
näher gelegen als Google oder Forum.

Die Verwendung der doppelten Unterstriche ist m.M. nicht erforderlich 
aber wurde halt so von ARM festgelegt. Die Hersteller übernehmen es, um 
ihre Treibersammlungen mit "CMSIS compatible" zu schmücken. Warum man 
überhaupt ein alias für volatile eingeführt hat, wissen wohl nur die 
CMSIS-Schöpfer.

zu CMSIS siehe z.B.: http://www.arm.com/products/CPUs/CMSIS.html
zu volatile siehe z.B.: http://en.wikipedia.org/wiki/Volatile_variable

[Marcus H. (mharnisch)]

Martin Thomas schrieb:
> Warum man überhaupt ein alias für volatile eingeführt hat, wissen wohl
> nur die CMSIS-Schöpfer.

Ich zitiere mal aus der CMSIS Dokumentation:

"IO Type Qualifiers are indented to be used for automatic generation of 
debug information of peripheral registers."

Mit anderen Worten: Entwicklungswerkzeuge sollen damit in die Lage 
versetzt werden, normale volatile Variablen von "echten" Registern zu 
unterscheiden.

Gruß
Marcus
http://www.doulos.com/arm

[Jörg W. (dl8dtl) (Moderator)]

Marcus Harnisch schrieb:

> Mit anderen Worten: Entwicklungswerkzeuge sollen damit in die Lage
> versetzt werden, normale volatile Variablen von "echten" Registern zu
> unterscheiden.

Dafür wiederum ist aber die hier gezeigte Verwendung kompletter Unfug.

Wahrscheinlich hätte es auch nichtmal eines volatile überhaupt
bedurft, wenn das Ganze nur ein Schleifenzähler ist, oder aber
es ist eine vorsätzliche Pessimierung, um damit eine Delay-Schleife
zu bauen.

[Martin T. (mthomas) (Moderator)]

Marcus Harnisch schrieb:
> Martin Thomas schrieb:
>> Warum man überhaupt ein alias für volatile eingeführt hat, wissen wohl
>> nur die CMSIS-Schöpfer.
>
> Ich zitiere mal aus der CMSIS Dokumentation:
>
> "IO Type Qualifiers are indented to be used for automatic generation of
> debug information of peripheral registers."
>
> Mit anderen Worten: Entwicklungswerkzeuge sollen damit in die Lage
> versetzt werden, normale volatile Variablen von "echten" Registern zu
> unterscheiden.

Danke für den Hinweis.

Muss zugeben, die CMSIS Dokumentation bis dato nur überflogen zu haben. 
Bin im Quellcode der STM32 StdPerLib an einigen wenigen Stellen (z.B. in 
system_stm32f10x.c, stm32f10x_flash.c V3.1.0) über die Verwendung von 
__IO gestolpert, wo keine Register der Hardware angesprochen werden aber 
der __IO Alias anstatt volatile gemeint ist. Daher - irrtümlich - 
vermutet, dass der Alias ein overengineering Resultat ist.

Jörg Wunsch schrieb:
> Marcus Harnisch schrieb:
>
>> Mit anderen Worten: Entwicklungswerkzeuge sollen damit in die Lage
>> versetzt werden, normale volatile Variablen von "echten" Registern zu
>> unterscheiden.
>
> Dafür wiederum ist aber die hier gezeigte Verwendung kompletter Unfug.
Hmm, das "hier" kann ich grade nicht interpretieren. Übliche Verwendung 
ist bei der STM32/CMSIS-library z.B. sowas:

typedef struct
{
  __IO uint32_t DR;
  __IO uint8_t  IDR;
  uint8_t   RESERVED0;
  uint16_t  RESERVED1;
  __IO uint32_t CR;
} CRC_TypeDef;
#define PERIPH_BASE           ((uint32_t)0x40000000)
#define AHBPERIPH_BASE        (PERIPH_BASE + 0x20000)
#define CRC                   ((CRC_TypeDef *) CRC_BASE)
#define CRC_BASE              (AHBPERIPH_BASE + 0x3000)

Sehe darin grade keinen "Unfug" für volatile und die Verwendung des __IO 
Alias passt zumindest zur zitierten Erklärung.

> Wahrscheinlich hätte es auch nichtmal eines volatile überhaupt
> bedurft, wenn das Ganze nur ein Schleifenzähler ist, oder aber
> es ist eine vorsätzliche Pessimierung, um damit eine Delay-Schleife
> zu bauen.

"Pessimierung" trifft wahrscheinlich auf sowas zu (auch STM32F 
StdPerLib):

__IO uint32_t StartUpCounter = 0, HSEStatus = 0;
...
do
{
  HSEStatus = RCC->CR & RCC_CR_HSERDY;
  StartUpCounter++;  
} while((HSEStatus == 0) && (StartUpCounter != HSEStartUp_TimeOut));

Ohne volatile ist das mglw. zu schnell, wenn der Compiler den Counter in 
einem Core-Register zugewiesen hat und man erhält nicht die gewünschte 
Verzögerung. Für den Zähler ist hier __IO statt volatile m.M. aber eher 
irritierend (wohl auch für den mir unbekannten "debug 
information"-Generator). Ähnlich hier:

...
*(__IO uint16_t*)Address = Data;
...

Ist eine Zeile aus einer Flash-Routine. Address ist eine Adresse im 
Speicher, kein HW-Register.

[Stefan E. (sternst)]

Martin Thomas schrieb:

>> Dafür wiederum ist aber die hier gezeigte Verwendung kompletter Unfug.
> Hmm, das "hier" kann ich grade nicht interpretieren.

Das "hier" bezieht sich sicherlich hierauf:

> So sieht der Codeteil aus :
>
> __IO uint32_t NbrOfPage = 0x00;
>
> Wobei es für mich insofern keinen Sinn ergibt, weil die Variable nur als
> Schleifenvariable genützt wird.

[Philipp (Gast)]

Vielen Dank, komplett auf CMSIS umsteigen war als nächstes dran bei mir. 
Eigentlich halte ich nicht viel davon, etwas zu verkomplizieren, aber 
wenn es dann einheitlicher ist ...

Rückwirkend betrachtet, habe ich volatile immer für Ports verwendet ... 
IO  :-)

ciao,
Philipp

[Marcus H. (mharnisch)]

Martin Thomas schrieb:
> Muss zugeben, die CMSIS Dokumentation bis dato nur überflogen zu haben.

Wahrscheinlich hast Du bereits die ganze Doku gelesen. Die ist nur eben 
sehr dünn geraten :-)

Gruß
Marcus

[Jörg W. (dl8dtl) (Moderator)]

Martin Thomas schrieb:

> "Pessimierung" trifft wahrscheinlich auf sowas zu (auch STM32F
> StdPerLib):

> Ohne volatile ist das mglw. zu schnell, wenn der Compiler den Counter in
> einem Core-Register zugewiesen hat und man erhält nicht die gewünschte
> Verzögerung.

Schlimmer noch: der Compiler erkennt, dass die Variable nichts tut,
und eliminiert sie komplett.

Verzögerungsschleifen baut man am besten als inline asm (siehe
<util/delay.h> in der avr-libc), sofern man nicht den Compiler
davon überzeugen kann, irgendwas wie _delay_cycles() bereit zu
stellen.

Beim Hochzählen einer Variablen (auch bei volatile) kann man immer
nur raten, wie lange das wirklich dauern wird, die Zeit ist dann
mit und ohne Optimierung unterschiedlich usw. usf.

> Für den Zähler ist hier __IO statt volatile m.M. aber eher
> irritierend

Genau das meinte ich mit "hier".  Wenn schon, sollte man an dieser
Stelle wirklich volatile schreiben, damit wenigstens jeder gleich
den Hack erkennen kann.