warum __inline zwingend erforderlich?

[Peter Z. (Gast)]

Hi,
ich habe mit dem ATmel Studio 6.1 für den ATtiny10 ein kleines Blinkytoy 
für einen WS2812B LED-Streifen programmiert.
Hier ein Teil des Codes:

  while(1)
  {
    Color = 2;
    Lauf_rechts();
    Color = 3;
    Lauf_links();
    Color = 1;
    Lauf_rechts();
    Color = 5;
    Lauf_links();
    Color = 4;
    Lauf_rechts();
    Color = 6;
    Lauf_links();
  }
}
//*********************************************************************
__inline void Lauf_rechts(void)
{
  uint8_t n;
  for(n = 0;n <= 77;n++) Set_pos(n);
}
//*********************************************************************
__inline void Lauf_links(void)
{
  uint8_t n;
  for(n = 76;n;n--)      Set_pos(n);
}
//*********************************************************************

das __inline ist für die Funktionen Lauf_rechts() und Lauf_links 
zwingend erforderlich, sonst leuchtet nix!
Wie kann das sein?

[Pupsomat (Gast)]

Was macht Set_pos? Code?

[Peter Z. (Gast)]

Pupsomat schrieb:
> Was macht Set_pos? Code?

//*********************************************************************
void Set_pos(uint8_t n)
{
  if(n <= 17) light_wave(17 - n);
  else
  {
    for(n -= 17;n;n--)
    {
      Send_Byte(0);
      Send_Byte(0);
      Send_Byte(0);
    }
    light_wave(0);
  }
  _delay_ms(30);
}
//*********************************************************************

[Bernd K. (prof7bit)]

Schieb die mal nach oben oberhalb der main(). Normalerweise sollte das 
gar nicht kompilieren, Du kannst eine Funktion erst aufrufen wenn der 
Compiler die Stelle an der sie deklariert wurde schon gesehen hat. Also 
nach oben damit. (oder hast Du forward-Deklarationen dafür?)

[Peter II (Gast)]

Bernd K. schrieb:
> Normalerweise sollte das
> gar nicht kompilieren

In C ist das zulässig.

[Bernd K. (prof7bit)]

Peter II schrieb:
> Bernd K. schrieb:
>> Normalerweise sollte das
>> gar nicht kompilieren
>
> In C ist das zulässig.

Seit wann? Mein gcc meckert jedenfalls.

[Peter II (Gast)]

Bernd K. schrieb:
> Seit wann? Mein gcc meckert jedenfalls.

schon immer, gcc sollte eine Warnung ausgeben.

Es könnte seit C99 nicht mehr zulässig sein.

[Johann L. (gjlayde)]

Peter II schrieb:
> Bernd K. schrieb:
>> Normalerweise sollte das
>> gar nicht kompilieren
>
> In C ist das zulässig.

Na und?  Kommt trotzdem gerne Müll raus.

Oder hast du ne Kristallkugel, die anhand von
 

int main (void)
{
    foo (1);
    return 0;
}

erkennt, wie z.B. ein anderes Modul foo implementiert und diese Funktion 
die Argumente erwartet? Z.B. als:

void foo (int);
void foo (long);
void foo (float);
void foo (const char*, ...);
void foo (struct xyz);
struct xyz foo (int);

Übrigens erwartet foo im letzten Fall i.d.R. 2 Parameter.

[Peter II (Gast)]

Johann L. schrieb:
> Oder hast du ne Kristallkugel

nein, aber es ist ja zum glück Definiert wie sich er Compiler zu 
verhalten hat. Und die Anzahl der Paramter ist ziemlich egal, sonst 
würde ein Printf mit variablen Anzahl nicht funktionieren.

[Rolf M. (rmagnus)]

Peter Zz schrieb:
> das __inline ist für die Funktionen Lauf_rechts() und Lauf_links
> zwingend erforderlich, sonst leuchtet nix!
> Wie kann das sein?

Stacküberlauf vielleicht? Das Ding hat immerhin nur 32 Bytes RAM.

[Johann L. (gjlayde)]

Peter II schrieb:
> Johann L. schrieb:
>> Oder hast du ne Kristallkugel
>
> nein, aber es ist ja zum glück Definiert wie sich er Compiler zu
> verhalten hat.

Daß der Compiler sich definiert verhält hilft nix wenn er sich in Modul 
A anders definiert verhält als in Modul B.  Siehe Beispiel.

> Und die Anzahl der Paramter ist ziemlich egal, sonst
> würde ein Printf mit variablen Anzahl nicht funktionieren.

Für den Compiler ist ein Funktionsaufruf ohne Prototyp nicht als 
varargs-Funktion erkennbar — wie auch.

Ganz nebenbei werden die Argumente anders übergaben auch wenn es sich 
um die gleichen Typen handelt.  foo (x) mit int x übergibt x in R24/25 
oder auf dem Stack, je nachdem.  Das ist schon ein kleiner Unterschied.

Aber auch ohne varargs werden Argumente anders übergeben: foo(int x) 
erwartet x in R24-25.  foo(long x) erwartet x in R22-25 mit LSB in R24 
bzw. R22. Und foo(float) verwendet zwar die gleichen Register wie 
foo(long), interpretiert dise aber etwas anders.

Ergo: Ob der Compiler sich definiert verhält ist total Banane.  Was 
zählt ist ob er richtigen Code generiert, und das kann er nur mit 
korrekten Prototypen.  Zumindest bei avr-gcc um den es hier ja geht.

[Peter II (Gast)]

Johann L. schrieb:
> Ergo: Ob der Compiler sich definiert verhält ist total Banane.  Was
> zählt ist ob er richtigen Code generiert, und das kann er nur mit
> korrekten Prototypen.  Zumindest bei avr-gcc um den es hier ja geht.

in vielen Fällen stimmt das, aber nicht in allen. In diesem Fall hier 
werde keine Parameter übergeben, damit ist der Aufruf eindeutig.

[Johann L. (gjlayde)]

Peter Zz schrieb:
> ATtiny10
>
> das __inline ist für die Funktionen Lauf_rechts() und Lauf_links
> zwingend erforderlich, sonst leuchtet nix!
> Wie kann das sein?

Schau mal den erzeugten Code an bzw. Mapfile.  Kann sein daß dem 
Hänfling die Resourcen ausgehen, z.B. Stack?

[Peter Z. (Gast)]

Johann L. schrieb:
> Kann sein daß dem
> Hänfling die Resourcen ausgehen, z.B. Stack?

habe ich auch vermutet.
Habe dann meine Tabelle die 18 von den 32Byte RAM frisst ins Flash 
gemapt.

static const __flash uint8_t Wave_Tab[18] = {1,2,4,8,16,32,64,128,255,128,64,32,16,8,4,2,1,0};

Und schon ein neues Problem, ich bekomme beim Compilieren zwei 
Fehlermeldungen:
Register not supported
illegal opcode elpm for mcu attiny10

[Peter Z. (Gast)]

Jetzt funktionierts!   :-)

#include <avr/pgmspace.h>
*
*
*
const uint8_t PROGMEM Wave_Tab[18] = {1,2,4,8,16,32,64,128,255,128,64,32,16,8,4,2,1,0};
*
*
*
  Helligkeit = pgm_read_byte(&Wave_Tab[n]);
*
*
*

__inline ist nicht mehr erforderlich.

[Johann L. (gjlayde)]

Peter Zz schrieb:
> Johann L. schrieb:
>> Kann sein daß dem Hänfling die Resourcen ausgehen,
>> z.B. Stack?
>
> habe ich auch vermutet.
> Habe dann meine Tabelle die 18 von den 32Byte RAM frisst ins Flash
> gemapt.
>

> static const __flash uint8_t Wave_Tab[18] = 
> {1,2,4,8,16,32,64,128,255,128,64,32,16,8,4,2,1,0};
>

> Und schon ein neues Problem, ich bekomme beim Compilieren zwei
> Fehlermeldungen:
> Register not supported
> illegal opcode elpm for mcu attiny10

Ok.  Dann hat die Toolchain keinen Support für ATtiny.  Bestenfalls kann 
man von der Toolchain sagen, daß sie für ATtiny aufgebohrt wurde...

Wenn die Toolchain ATtiny gscheit unterstützt dann sollte ein

static const uint8_t Wave_Tab[18] = { ... };

vollkommen ausreichen:

1) Der Compiler legt diese Daten nach .rodata.

2) WIMRE mappt ATtiny Flash in den Adressbereich von LD/ST, nämlich ab 
0x4000.

3) Das Linkerscript sollte .rodata also ab 0x4000 legen.

Ergo: Wenn die Toolchain ATtiny unterstützt dann brauch't das ganze 
__flash oder progmem Geraffel nicht mehr.

Evtl. kann man mit eigenem Linkerscript nachhelfen das .rodata und 
andere Daten, die nur gelesen werden müssen, ab 0x4000 lokatiert, 
beispielsweise .ctors und .dtors.

[Rolf M. (rmagnus)]

Johann L. schrieb:
> Aber auch ohne varargs werden Argumente anders übergeben: foo(int x)
> erwartet x in R24-25.  foo(long x) erwartet x in R22-25 mit LSB in R24
> bzw. R22. Und foo(float) verwendet zwar die gleichen Register wie
> foo(long), interpretiert dise aber etwas anders.

Natürlich werden unterschiedliche Parametertypen unterschiedlich 
übergeben.

> Ergo: Ob der Compiler sich definiert verhält ist total Banane.  Was
> zählt ist ob er richtigen Code generiert, und das kann er nur mit
> korrekten Prototypen.  Zumindest bei avr-gcc um den es hier ja geht.

In C gab es ursprünglich gar keine Prototypen, und trotzdem konnten 
Compiler korrekten Code erzeugen. Und auch heute geht das noch. Man muß 
dann natürlich selber darauf achten, die Daten mit richtigem Typ zu 
übergeben. Da das sehr mühsam und fehlerträchtig ist, gibt es 
Prototypen, aber zwingend erforderlich sind sie nicht.

[Johann L. (gjlayde)]

Rolf Magnus schrieb:
> Johann L. schrieb:
>> Aber auch ohne varargs werden Argumente anders übergeben: foo(int x)
>> erwartet x in R24-25.  foo(long x) erwartet x in R22-25 mit LSB in R24
>> bzw. R22. Und foo(float) verwendet zwar die gleichen Register wie
>> foo(long), interpretiert dise aber etwas anders.
>
> Natürlich werden unterschiedliche Parametertypen unterschiedlich
> übergeben.
>
>> Ergo: Ob der Compiler sich definiert verhält ist total Banane.  Was
>> zählt ist ob er richtigen Code generiert, und das kann er nur mit
>> korrekten Prototypen.  Zumindest bei avr-gcc um den es hier ja geht.
>
> In C gab es ursprünglich gar keine Prototypen, und trotzdem konnten
> Compiler korrekten Code erzeugen.

Das lag und liegt aber nicht am Compiler sondern am ABI, das für 
Parameterübergabe nicht komplizierter war als "Pack den Krempel 
wortweise auf den Stack und gut is".

Hätte man bei avr-gcc auch machen können, aber zu welcher Codegüte das 
geführt hätte kann sich hier jeder ausmalen.   Der Teil des avr-gcc ABI, 
der festlegt, wo was wann wie übergeben wird, ist 1/2 DIN A4 Seite lang 
oder mehr.

> Und auch heute geht das noch.

Ja, mit entsprechendem ABI.

> Man muß dann natürlich selber darauf achten, die Daten mit
> richtigem Typ zu übergeben. Da das sehr mühsam und
> fehlerträchtig ist, gibt es Prototypen, aber zwingend
> erforderlich sind sie nicht.

Beispiele hab ich oben schon gegeben.  Konkret: Wenn der Funktionsaufruf

 func (0);

ist, dann kannst du nicht ausdrücken, ob 0

1) in R24/25 oder
2) in R22/23 oder
3) auf dem Stack

übergeben wird, bzw. 0 wird immer gemäß 1) übergeben.  Oder wie willst 
du es ohne Prototyp anstellen, dass 0 in R22/23 oder auf dem Stack 
übergeben wird?  Hypnose?

Das sind zumindest laut avr-gcc ABI die 3 Möglichkeiten für func, den 
ersten Parameter zu erhalten wenn dieser vom Typ int ist.

[(prx) A. K. (prx)]

Das avr-gcc ABI wurde eindeutig im Hinblick auf Prototypes definiert. 
Ohne sie hätte es anders ausfallen müssen. Aber auch ohne Prototypes 
wäre ein ABI definierbar, das eine begrenzte Anzahl Parameter in 
Registern übergibt (varargs/stdarg.h wäre dann nur etwas komplizierter).

So gibt es Stellen, an denen das bestehende ABI überhaupt nur mit 
Prototypes implementierbar ist. Beispielsweise setzen so wie im ABI 
definiert Varargs-Funktionen eine Prototyp-Deklaration zwingend voraus, 
weshalb dein Beispiel mit Übergabe auf dem Stack eine direkte Folge der 
Entscheidung bei der ABI-Definition ist. Parameter kleiner als int kann 
es ohne Prototypes auch nicht geben, ebensowenig wie bei den ungenannten 
Varargs-Parametern im aktuellen ABI.

Aber was du mit R22/23 meinst erschliesst sich mir nicht. Ich sehe 
keinen Weg, bei dem ein "int" als erstem Parameter in R22/23 landen 
könnte und von einer solchen Funktion auch dort erwartet würde.

[äöü (Gast)]

Gibt's eigentlich einen Unterschied zwischen

"__inline"

und

"inline"

?

[Johann L. (gjlayde)]

A. K. schrieb:
> Das avr-gcc ABI wurde eindeutig im Hinblick auf Prototypes definiert.
> Ohne sie hätte es anders ausfallen müssen. Aber auch ohne Prototypes
> wäre ein ABI definierbar, das eine begrenzte Anzahl Parameter in
> Registern übergibt (varargs/stdarg.h wäre dann nur etwas komplizierter).

Die Implementierung im GCC wäre marginal aufwändiger, ein paar Zeilen 
mehr und fertig ist der Lack.  Der erzeugte Code wäre kleiner, schneller 
-- sowohl auf Seiten des Callers als auch des Callees -- und verbrauchte 
weniger Stack.

> So gibt es Stellen, an denen das bestehende ABI überhaupt nur mit
> Prototypes implementierbar ist. Beispielsweise setzen so wie im ABI
> definiert Varargs-Funktionen eine Prototyp-Deklaration zwingend voraus,
> weshalb dein Beispiel mit Übergabe auf dem Stack eine direkte Folge der
> Entscheidung bei der ABI-Definition ist.

Bei der Implementierung hat Denis so lange mit der Registerverwendung 
rumgespielt, bis er die beste Codeerzeugung erreicht hatte :-)

Feinheiten wie die Parameterübergabe bei varargs hatte er bestimmt 
weniger auf dem Radar, wohl unter der Annahme, dass diese vor allem von 
den eh teuren printf/scanf Funktionen generiert werden.  Das trifft auch 
heute noch zu; nicht-stdio varargs-Funktionen bleiben Exoten.

> Aber was du mit R22/23 meinst erschliesst sich mir nicht. Ich sehe
> keinen Weg, bei dem ein "int" als erstem Parameter in R22/23 landen
> könnte und von einer solchen Funktion auch dort erwartet würde.

typedef struct { int a[9]; } S;

S fun (int i)
{
    S s;
    s.a[0] = i;
    return s;
}

fun erwartet i in R22/23:

fun:
  movw r30,r24
  std Z+1,r23 ;; da
  st Z,r22  ;; und da
  ret

Der erste Parameter ist implizit und die Adresse, wo der Aufrufer das 
Ergebnis haben möchte.  Und auf Seiten des Callers:

extern S yum (int);

void buh (S *s)
{
    *s = yum (0);
}

buh übergibt i natürlich in R22/23, hier für ATtiny24:

buh:
  push r16
  push r17
  push r28
  push r29
  in r28,__SP_L__
  clr r29
  subi r28,lo8(-(-18))
  out __SP_L__,r28

  movw r16,r24
  ldi r22,0 ;; da
  ldi r23,0 ;; und da
  movw r24,r28
  adiw r24,1
  rcall yum
  ;; blabla mit memcpy und Epilog...

Damit gibt es auch 2 Möglichkeiten, an welcher Stelle im Stack eine 
varargs-Funktion einen ersten int-Parameter erwartet.

Solche Rückgabewerte sind zwar jenseits des Horizonts der meisten 
Anwendungen, werden aber von C und entsprechend auch vom Compiler 
unterstützt.

Sogar wenn immer alle Argumente auf dem Stack übergeben werden, machen 
die Fälle solcher Rückgabewerte, die ein implizites Argument erzeugen, 
ohne Prototypen Probleme.  Selbst wenn das ABI immer ein implizites, 
erstes (Dummy-)Argument verlangte, wüsste man nicht, wieviel Daten die 
aufgerufene Funktion möglicherweise ab der übergebenen Adresse ablädt 
:-)