Optimierung beurteilen?

[hal (Gast)]

Hallo,
in der (vermutlich) relativen einfachen Routine:

void lcd_string_P(const char *data)
{
  while(pgm_read_byte(data)!=0)
    lcd_data(pgm_read_byte(data++));
}

habe ich das Gefühl, dass die Funktion 'pgm_read_byte' nicht unbedingt 
2x innerhalb der Schleife aufgerufen werden muss. Deshalb habe ich 
alternativ die Funktion geändert:

void lcd_string_P(const char *data)
{
  uint8_t i = pgm_read_byte(data);
  
  while(i!=0)
  {
    lcd_data(i);
    i = pgm_read_byte(++data);
  }
}

unabhängig ob dies nun offensichtlich dämlich oder clever ist:

Wie kann ich sowas objektiv ermitteln?
(Speicher, Geschwindigkeit, ... was auch immer?)

danke
hal

[dunno.. (Gast)]

Hi,

läuft der Code auf nem Controller?

Eine Methode für Laufzeitbestimmung ist, sich im Debugger das 
Disassembly anzuschauen, und die Zyklen pro assembler- befehl 
aufzuaddieren, dann kannst dus ziemlich genau bestimmen. Speicher siehst 
du ja sowieso direkt.

Alternativ kannst du auch nen Pin toggeln lassen, zwischen den teilen 
die dich interessieren, und mit nem oskar die zeiten messen.

Gruß
Dunno

[Walter Tarpan (Gast)]

hal schrieb:
> uint8_t i = pgm_read_byte(data);

Also "i" ist in einer Schleife für einen Temp-Wert SEHR ungünstig. Der 
Variablennamen weckt falsche Erwartungen.

Mit einer do-while - Schleife kannst Du das auch noch etwas "schöner" 
machen:

void lcd_string_P(const char *data)
{
    do {
        uint8_t tmp = pgm_read_byte(data);
        lcd_data(tmp);
    } while (i!=0);
}

hal schrieb:
> Wie kann ich sowas objektiv ermitteln?
> (Speicher, Geschwindigkeit, ... was auch immer?)

Zähl die Assembler-Instruktionen oder miß mit einem Oszi. Aber ich 
vermute, die Funktion "lcd_data" wird den Hauptteil der Laufzeit 
ausmachen - da macht Deine "Optimierung" keinen Unterschied.

Viele Grüße
W.T.

[Walter Tarpan (Gast)]

Walter Tarpan schrieb:
> void lcd_string_P(const char *data)
> {
>     do {
>         uint8_t tmp = pgm_read_byte(data);
>         lcd_data(tmp);
>     } while (i!=0);
> }

Natürlich:

void lcd_string_P(const char *data)
{
    do {
        uint8_t tmp = pgm_read_byte(data);
        lcd_data(tmp);
    } while (tmp!=0);
}

"i" nervt.

[Leo C. (rapid)]

Walter Tarpan schrieb:
> Mit einer do-while - Schleife kannst Du das auch noch etwas "schöner"
> machen:

Schlecht, wenn das erste Zeichen bereits '\0' sein kann.

Die übliche Formulierung geht so:

void lcd_string_P(const char *data)
{
  char c;

  while((c = pgm_read_byte(data++)) !=0)
    lcd_data(c);
}

hal schrieb:
> Wie kann ich sowas objektiv ermitteln?

Den Compiler-Output anschauen. Gut möglich, daß der Compiler Deine erste 
Variante schon in diese Richtung optimiert.

[Walter Tarpan (Gast)]

Leo C. schrieb:
> void lcd_string_P(const char *data)
> {
>   char c;
>
>   while((c = pgm_read_byte(data++)) !=0)
>     lcd_data(c);
> }

Du hast Recht. Mal wieder die "keinen Quellcode vor dem Kaffee"-Regel 
verletzt.

Zumal meine Variante noch am Ende das Nullzeichen ausgäbe.

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

hal schrieb:
> habe ich das Gefühl, dass die Funktion 'pgm_read_byte' nicht unbedingt
> 2x innerhalb der Schleife aufgerufen werden muss.

Ich würde mir an ausgerechnet dieser Stelle keine Gedanken um 
Optimierung machen. Ein ggf. redundanter LPM Befehl braucht 
Nanosekunden, ein Zeichen an den LCD-Controller Mikrosekunden und 
Display wie Auge brauchen Millisekunden.

[hal (Gast)]

Danke mal an alle.
Der Code war auch nur als Beispiel gedacht. Ob es Sinn macht oder nicht 
ist an dieser Stelle mir mal egal.

Hab jetzt genügend Info zum weitersuchen und lesen.

Beim Interpretieren der lss-Datei hab ich allerdings teilweise Problem. 
z.Bps. verstehe ich nicht, warum 'voids' doppelt vorkommen?

[Karl H. (kbuchegg)]

hal schrieb:

> Beim Interpretieren der lss-Datei hab ich allerdings teilweise Problem.
> z.Bps. verstehe ich nicht, warum 'voids' doppelt vorkommen?


Weil es, nachdem sich ein Optimizer den C Code vorgenommen hat, im 
Normalfall keine eindeutige Entsprechung mehr vom Assembler Code zum C 
Code gibt. Nimm die eingestreuten C Schnipsel mehr als Hinweis, wo 
ungefähr die Originalstelle im C Code zu finden ist, aus der der 
fragliche Assembler Abschnitt entstanden ist. Letzten Endes interessiert 
nämlich sowieso nur der.