C-Code optimieren

> Im späteren Verlauf des Projektes wird der
> µController gewechselt (kleineres Package) bei dem die Pins dann zwar am
> selben Port hängen, aber wild verstreut (reicht von Pin 4 bis Pin 27).

Hier steht, dass es sich später nicht mehr so verhält wie im 
Codeschnipsel! Dass es zurzeit so geht, wie du es vorschlägst, ist mir 
klar.

Tarek T. schrieb:
> Hier steht, dass es sich später nicht mehr so verhält wie im
> Codeschnipsel! Dass es zurzeit so geht, wie du es vorschlägst, ist mir
> klar.

Hier kann aber keiner in die Zukunft sehen und daher eher schlecht einen 
Vorschlag machen, wie Code, der später mal entstehen wird, optimiert 
werden könnte.

Es geht mir auch eher um einen generellen Hinweis. Aber vielleicht 
sollte ich mal ein Beispiel reinstellen. Das momentane Design sieht 
folgende Pinbelegung vor:

1

  /* IPMS Controllerpins definieren */

2

  #define GPIO_IPMS_DB0  AVR32_PIN_PD11

3

  #define GPIO_IPMS_DB1  AVR32_PIN_PD13

4

  #define GPIO_IPMS_DB2  AVR32_PIN_PD14

5

  #define GPIO_IPMS_DB3  AVR32_PIN_PD21

6

  #define GPIO_IPMS_DB4  AVR32_PIN_PD27

7

  #define GPIO_IPMS_DB5  AVR32_PIN_PD28

8

  #define GPIO_IPMS_DB6  AVR32_PIN_PD29

9

  #define GPIO_IPMS_DB7  AVR32_PIN_PD30

ein Gast schrieb:
> Da es sich um 8bit handelt, würde ich die bytes per Tabelle übersetzen.
> Das sollte der uc3 ressourcentechnisch noch frei haben. Vermute ich mal.

Die Tabelle hat bei Bits 4..27 zusammen 24 Adressbits, benötigt also 
16MB. Müsste segmentiert werden, d.h. mindestens 2 Tabellen.

Tarek T. schrieb:
> Wie kann ich hier Taktzyklen einsparen?

Was kommt denn bisher hinten raus? Müsste sowas wie
  BLD  ...
  ORNE ...
sein, pro Bit.

Wird hier vielleicht keine grosse Rolle spielen, ist aber generell 
beachtenswert: Bei einer 32-Bit RISC-CPU sind lokale Variablen kleiner 
als 32 Bits summarum ineffizient.

Tarek T. schrieb:
> Das momentane Design sieht
> folgende Pinbelegung vor:

Dann sind PD27..30 per Shift zu ermitteln und der Rest wie oben.
Das "& 0x1F" ist allerdings witzlos, es ergibt immer 0.

A. K. schrieb:
> Bei einer 32-Bit RISC-CPU sind lokale Variablen kleiner
> als 32 Bits summarum ineffizient.

Merkbaren Overhead wird das kaum geben.
Wenn der Compiler erkennt, daß Bit 8..31 nicht geändert werden, wird der 
Code gleich groß sein.
Nur bei einem möglichen Überlauf wird er zum Schluß ein "& 0xFF" 
anfügen.

Tarek T. schrieb:

> Wie kann ich hier Taktzyklen einsparen?

Ist das denn ein reales Problem, daß der Code zu langsam ist?

Oder ein ästhetisches Problem mit der 8 Quellzeilen?

Johann L. schrieb:
> ein ästhetisches Problem
Vermute ich auch...

Tarek T. schrieb:
> /* Pinzustände abfragen */
Der Kommentar ist redundant. Wer sieht nicht, dass in der Folgezeile ein 
paar Pins eingelesen werden?

Tarek T. schrieb:
> /* Byte wieder zurecht biegen */
Das seh ich auch, dass da was zurechtgebogen-bitgefummelt wird.
Was ist der Zweck der Aktion?
Wenn dir das im Laufcode zu hässlich aussieht, schreib doch eine kleine 
Funktion, die dir das Pin-Einlesen/Zurechtbiegen erledigt. Oder eine 
Inline-Funktion oder ein Makro...

mfg mf

@ MaWin
Bist Du Dir sicher, dass die umcodier_tabelle[] nicht doch besser 4GB 
groß sein sollte?

Peter Dannegger schrieb:
> Merkbaren Overhead wird das kaum geben.

Je nach Quellcode kann das schon etwas ausmachen. Hier nicht unbedingt, 
was ich auch erwähnt hatte.

MaWin schrieb:
> Die Tabelle ist 256 Bytes lang,

Bei einem 32-Bit breiten Port eines AVR32 eher nicht. Und die später 
verwendeten Bits sind "wild verstreut (reicht von Pin 4 bis Pin 27)", 
was auf eine Spanne von 24 Bits rausläuft, also eine 16MB Tabelle.