memcpy vs for-loop bei AVR

[Obs (Gast)]

Hallo Community,

ich nutze eine AVR-MCU und möchte einen Puffer umkopieren und wollte mal 
fragen, ob es einen großen Performance Unterschied gibt zwischen 
memcpy() und dem "manuellen" umkopieren in einer for-Schleife? Ich weiß, 
dass memcpy für das Umkopieren von Daten hochgradig optimiert sein soll 
und so weiter, aber wollte mal fragen, ob jemand konkret Erfahrung damit 
hat und ob es wirklich so den großen Unterschied macht. Danke schon mal.

[holger (Gast)]

>in einer for-Schleife?

Ich nehm immer do{}while();
Das ist viel schneller als for() :)

[Rufus Τ. F. (rufus)]

Obs schrieb:
> aber wollte mal fragen, ob jemand konkret Erfahrung damit
> hat und ob es wirklich so den großen Unterschied macht.

Das kannst Du selbst rausfinden. Schreib Dir Deine Kopierschleife so wie 
Du sie Dir denkst, übersetze das ganze (mit Optimierung) und sieh Dir 
den Assemblercode an, den der Compiler daraus gemacht hat.

Und den vergleichst Du mit dem Sourcecode von memcpy.

[Michael (Gast)]

Rufus Τ. Firefly schrieb:
> Und den vergleichst Du mit dem Sourcecode von memcpy.

Noch einfacher ist es, wenn du dir im Simulator die Stopuhr anguckst. 
Dann siehst du u.a. direkt die Anzahl der Prozessortakte.

[c.m. (Gast)]

Rufus Τ. Firefly schrieb:
> sieh Dir
> den Assemblercode an, den der Compiler daraus gemacht hat.

wie eigentlich? braucht man einen speziellen disassembler, oder wird das 
"irgendwie mitgeliefert"?
wäre schon nett den unterschied einer schleife und einem avr equivalent 
von "repz movsb" zu sehen.

[Tom M. (tomm)]

c.m. schrieb:
> wie eigentlich? braucht man einen speziellen disassembler, oder wird das
> "irgendwie mitgeliefert"?

Im einfachsten Fall kannst du das Zwischenformat "zurück-übersetzen", 
etwa mittels:

avr-objdump -d meine.elf

[Tom M. (tomm)]

holger schrieb:
>>in einer for-Schleife?
>
> Ich nehm immer do{}while();
> Das ist viel schneller als for() :)

Quark, das ist wohl eine urban legend. Zumindest erzeugt mein Compiler 
praktsich identischen Code für beide Konstrukte. Taktzyklen habe ich 
nicht gezählt, aber ich denke das gibt sich nix.

Hast du ein Beispiel, wo du einen signifikanten Unterschied festgestellt 
hast?

[Michael (Gast)]

c.m. schrieb:
> wie eigentlich? braucht man einen speziellen disassembler, oder wird das
> "irgendwie mitgeliefert"?

Das kommt drauf an, was du geliefert bekommen hast. Bei ATMEL-Studio 6.0 
kannst du dir nach dem Build einfach den List-File (.LSS) ansehen.

[holger (Gast)]

>Quark, das ist wohl eine urban legend.

Du hast den Smiley übersehen.

[Andreas B. (andreas_b77)]

Rufus Τ. Firefly schrieb:
> Das kannst Du selbst rausfinden. Schreib Dir Deine Kopierschleife so wie
> Du sie Dir denkst, übersetze das ganze (mit Optimierung) und sieh Dir
> den Assemblercode an, den der Compiler daraus gemacht hat.
>
> Und den vergleichst Du mit dem Sourcecode von memcpy.

Das muss man genauer ausdrücken, den Sourcecode von memcpy gibt es 
unter Umständen so allgemein nicht. Der Compiler kann (und der gcc wird, 
bei eingeschalteter Optimierung) den memcpy Aufruf durch äquivalenten 
Code ersetzen und den Gegebenheiten entsprechend optimieren.

Also die eigene Implementierung vergleichen mit einer Implementierung, 
die memcpy verwendet.


Beispiel:

#include <string.h>

char x[40];
char y[40];

void func(void)
{
  memcpy(x, y, 40);
}

Aus func() macht avr-gcc mit -Os das:

  ldi r24,lo8(40)
  ldi r30,lo8(y)
  ldi r31,hi8(y)
  ldi r26,lo8(x)
  ldi r27,hi8(x)
  0:
  ld r0,Z+
  st X+,r0
  dec r24
  brne 0b
  ret

[Johann L. (gjlayde)]

Andreas B. schrieb:
> Das muss man genauer ausdrücken, den Sourcecode von memcpy gibt es
> unter Umständen so allgemein nicht. Der Compiler kann (und der gcc wird,
> bei eingeschalteter Optimierung) den memcpy Aufruf durch äquivalenten
> Code ersetzen und den Gegebenheiten entsprechend optimieren.

Aus
 

#include <string.h>
#include <stdint.h>

float next_float (float f)
{
    uint32_t i;

    memcpy (&i, &f, sizeof (i));
    i++;
    memcpy (&f, &i, sizeof (i));
    
    return f;
}

wird zum Beipiel:
 

next_float:
  subi r22,-1
  sbci r23,-1
  sbci r24,-1
  sbci r25,-1
  ret