Arduino Compiler Speicherverwaltung

Bis zu einer bestimmten Größe werden die Arrays "von Hand", also mit 
einzelnen Instruktionen initialisiert und darüber hinaus mit einer 
Kopierschleife. Das ist Teil des Codegenerators/Optimierers.

Btw, volatile auto vars sind schon ziemlich merkwürdig - da gehört 
zumindest nen Kommentar hinter ;-)

Noch zur Erläuterung: lokale Variablen befinden sich auf dem Stack. Wenn 
sie initialisiert werden sollen, muß das für jeden einzelnen Aufruf vom 
Code händisch gemacht werden.

Bei wenigen Elementen macht der Compiler

1

   // aus

2

   char var[2] = { 1, 2};

3

   // dies

4

   char var[2]; var[0]=1; var[1]=2;

Werden es mehr Elemente (z.B. 5), macht er daraus

1

    static char init937[5] = { 1,2,3,4,5}; // anonymes statisches Array

2

    char var[5]; memcpy(var, init937, sizeof(init937));

Lothar schrieb:
> Ist das eine Art Sicherung gegen Stacküberlauf?

Ich habe für eine PC-Software eine Funktion zur Datenkomprimierung 
gemacht. Die hat grosse lokale Arrays. Die will ich nun auch auf uC 
nutzen. Zuerst auf 8051: hier ist natürlich klar - die grossen lokalen 
Arrays müssen global gemacht werden da sonst Stacküberlauf. Auf Arduino 
musste ich erstaunt feststellen dass es scheinbar keinen Unterschied 
macht ob die grossen Arrays lokal bleiben oder global gemacht werden. 
Wenn man sich darauf verlassen kann müssten PC Funktionen nicht mehr 
angepasst werden. Wenn nicht würde ich sicherheitshalber auch auf 
Arduino immer alle grossen Arrays global machen. Dann bekomme ich ja vom 
Compiler angezeigt wenn der Speicher voll ist.

foobar schrieb:
> volatile auto vars sind schon ziemlich merkwürdig

Habe ich nur in den Beispielen so gemacht da nicht verwendete Variablen 
sonst wegoptimiert werden.

Axel S. schrieb:
> "Arduino" ist keine einheitliche Hardware-Plattform

Das Board hat einen ATmega2560

Ich habe mal ein Assembler Listing aus der *.elf Datei erstellt, die der 
Compiler (mit dem 3-Byte Array) erzeugt hat:

avr-objdump -h -S /tmp/arduino_build_482746/test.ino.elf > test.txt

Die Ausgabe von
avr-size /tmp/arduino_build_482746/test.ino.elf
ist:

1

   text     data      bss      dec      hex  filename

2

    712        4        9      725      2d5  /tmp/arduino_build_482746/test.ino.elf

Offensichtlich addiert die IDE die Größen vom data und bss Segment 
(siehe https://www.nongnu.org/avr-libc/user-manual/mem_sections.html).

Wenn ich ein komplett leeres Programm compiliere, ist auch bei mir die 
Ausgabe:

1

   text     data      bss      dec      hex  filename

2

    656        0        9      665      299  /tmp/arduino_build_482746/test.ino.elf

Ebenso, wenn ich die beiden kürzeren Arrays einkommentiere.

Ich bin jetzt auch ratlos.

> Ich bin jetzt auch ratlos.

Wieso? Was ist denn noch unklar?  Die 9 Byte im .bss sind timer0_millis, 
timer0_fract und timer0_overflow_count. Und die Initialisierungsdaten 
der auto-Variablen landen im .data.

Hier der Code, den GCC erzeugt (meiner macht erst ab 5 Elementen die 
Kopierschleife; Listing ohne Prolog etc):

1

// void foo() { volatile char var[] = { 1, 2 }; }

2

foo:

3

  ...

4

  ldi r24,lo8(1)

5

  ldi r25,lo8(2)

6

  std Y+2,r25

7

  std Y+1,r24

8

  ...

9

  ret

10

11

// void bar() { volatile char var[] = { 1, 2, 3, 4, 5 }; }

12

  .section  .rodata

13

.LC0:

14

  .byte  1

15

  .byte  2

16

  .byte  3

17

  .byte  4

18

  .byte  5

19

  .text

20

bar:

21

  ...

22

  ldi r24,lo8(5)

23

  ldi r30,lo8(.LC0)

24

  ldi r31,hi8(.LC0)

25

  movw r26,r28

26

  adiw r26,1

27

  0:

28

  ld r0,Z+

29

  st X+,r0

30

  dec r24

31

  brne 0b

32

  ...

33

  ret

Dass das Arduino Framework 9 Bytes belegt, überrascht mich nicht.

Aber das was darüber hinaus geht:

1

volatile unsigned char var1 = 1;            ---> 0 Bytes

2

3

volatile unsigned char var2[] = {1, 1};     ---> 0 Bytes

4

5

volatile unsigned char var3[] = {1, 1, 1};  ---> 4 Bytes

Wie kann das sein?

Das ist einfach ein Aspekt des Codegenerators oder des Optimizers. Wie 
er genau dazu kommt, ist doch Peng.

Ein Entscheidungsgang könnte bei meinem geposteten Kode z.B. sein: er 
braucht 2 Instruktionen pro Arrayelement wenn er jedes Element einzeln 
initialisiert; für die Schleife braucht er 9 Instruktionen, egal wie 
viele Elemente es sind. Also ist es ab 5 Elementen günstiger, die 
Schleife zu benutzen. Ob das jetzt wirklich das Kriterium ist (besonders 
gut ist es ja nicht), weiß ich nicht - dazu müsste man in den GCC 
reinschauen und wird wohl deutlich komplexer sein.

Das ist noch eine andere Baustelle. Da der Arduino C++ Compiler 
scheinbar das Codewort flash nicht unterstützt müssten alle 8051 code 
const Array Zugriffe auf pgm_read_byte geändert werden. Da das Aufwand 
ist mache ich die meist auch global - bis das RAM voll ist.

Lothar schrieb:
> Da der Arduino C++ Compiler
> scheinbar das Codewort flash nicht unterstützt

Das ist so richtig und auch falsch.

Es gibt keinen Arduino C++ Compiler.
Hat also nichts mit Arduino an sich zu tun.

Es ist wird z.B. der AVR-Gcc genutzt.
Und dort gibt es flash nur für C, nicht in C++


Andere Compiler, für andere µC, mögen das unterstützen.... KA