switch case vs. Tabelle

[Kapitän Nuss (Gast)]

Hallo,
ich habe hier ein Programmfragment in C
Ist es nicht besser das als Tabelle zu machen, anstelle von switch/case?

        parameter1 = 0;
  if(~GP0DAT & (1 << 1)) parameter1 += 1;
  if(~GP4DAT & (1 << 6)) parameter1 += 2;
  if(~GP0DAT & (1 << 6)) parameter1 += 4;
  if(~GP3DAT & (1 << 0)) parameter1 += 8;

  switch(parameter1)
  {
    case  0: I_mul =        1; break;
    case  1: I_mul =        2; break;
    case  2: I_mul =        5; break;
    case  3: I_mul =       10; break;
    case  4: I_mul =       20; break;
    case  5: I_mul =       50; break;
    case  6: I_mul =      100; break;
    case  7: I_mul =      200; break;
    case  8: I_mul =      500; break;
    case  9: I_mul =     1000; break;
    case 10: I_mul =     2000; break;
    case 11: I_mul =     5000; break;
    case 12: I_mul =    10000; break;
    case 13: I_mul =    20000; break;
    case 14: I_mul =    50000; break;
    case 15: I_mul =   100000; break;
    default: I_mul = 0; // um Compiler Warnung los zu werden!
  }

Wie am besten?

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

Bei wie hier sequentiellen Werten ist eine Tabelle vorzuziehen.

[Karl H. (kbuchegg)]

Kapitän Nuss schrieb:
> Hallo,
> ich habe hier ein Programmfragment in C
> Ist es nicht besser das als Tabelle zu machen, anstelle von switch/case?

Mit ein bischen Glück macht der Compiler sowieso daraus eine Tabelle.

Ich würds allerdings trotzdem händisch in Tabellenform überführen. Schon 
alleine deswegen, weil das den Code nicht so in die Länge zieht.

[Jörg W. (dl8dtl) (Moderator)]

Kapitän Nuss schrieb:

> Ist es nicht besser das als Tabelle zu machen, anstelle von switch/case?

$ cat foo.c
#include <stdint.h>

uint32_t x(uint8_t parameter1)
{
uint32_t I_mul;
switch(parameter1)
  {
    case  0: I_mul =        1; break;
    case  1: I_mul =        2; break;
    case  2: I_mul =        5; break;
    case  3: I_mul =       10; break;
    case  4: I_mul =       20; break;
    case  5: I_mul =       50; break;
    case  6: I_mul =      100; break;
    case  7: I_mul =      200; break;
    case  8: I_mul =      500; break;
    case  9: I_mul =     1000; break;
    case 10: I_mul =     2000; break;
    case 11: I_mul =     5000; break;
    case 12: I_mul =    10000; break;
    case 13: I_mul =    20000; break;
    case 14: I_mul =    50000; break;
    case 15: I_mul =   100000; break;
    default: I_mul = 0; // um Compiler Warnung los zu werden!
  }
return I_mul;
}
$ avr-gcc -mmcu=avr5 -Os -S foo.c
$ cat foo.s
        .file   "foo.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
        .text
.global x
        .type   x, @function
x:
        push r16
        push r17
/* prologue: function */
/* frame size = 0 */
/* stack size = 2 */
.L__stack_usage = 2
        cpi r24,lo8(16)
        brsh .L3
        ldi r25,0
        movw r30,r24
        lsl r30
        rol r31
        add r30,r24
        adc r31,r25
        subi r30,lo8(-(CSWTCH.2))
        sbci r31,hi8(-(CSWTCH.2))
        ld  r24,Z
        ldd r25,Z+1
        ldd r26,Z+2
        movw r16,r24
        mov r18,r26
        ldi r19,0
        rjmp .L2
.L3:
        ldi r16,0
        ldi r17,0
        movw r18,r16
.L2:
        movw r22,r16
        movw r24,r18
/* epilogue start */
        pop r17
        pop r16
        ret
        .size   x, .-x
        .section        .rodata
        .type   CSWTCH.2, @object
        .size   CSWTCH.2, 48
CSWTCH.2:
        .byte   1
        .byte   0
        .byte   0
        .byte   2
        .byte   0
        .byte   0
        .byte   5
        .byte   0
        .byte   0
        .byte   10
        .byte   0
        .byte   0
        .byte   20
        .byte   0
        .byte   0
        .byte   50
        .byte   0
        .byte   0
        .byte   100
        .byte   0
        .byte   0
        .byte   -56
        .byte   0
        .byte   0
        .byte   -12
        .byte   1
        .byte   0
        .byte   -24
        .byte   3
        .byte   0
        .byte   -48
        .byte   7
        .byte   0
        .byte   -120
        .byte   19
        .byte   0
        .byte   16
        .byte   39
        .byte   0
        .byte   32
        .byte   78
        .byte   0
        .byte   80
        .byte   -61
        .byte   0
        .byte   -96
        .byte   -122
        .byte   1
        .ident  "GCC: (GNU) 4.7.2"
.global __do_copy_data

Der GCC 4.7.2 scheint da deiner Meinung zu sein. :-)

[Kapitän Nuss (Gast)]

ich hab es mal als Tabelle geschrieben:

  {
    unsigned char mouse_piano = 0;
    const unsigned long int mul_tab[16]=
    {1,2,5,10,20,50,100,200,500,1000,2000,5000,10000,20000,50000,100000};
    if(~GP0DAT & (1 << 1)) mouse_piano += 1;
    if(~GP4DAT & (1 << 6)) mouse_piano += 2;
    if(~GP0DAT & (1 << 6)) mouse_piano += 4;
    if(~GP3DAT & (1 << 0)) mouse_piano += 8;
    I_mul = mul_tab[mouse_piano];
  }

So besser?

[Kapitän Nuss (Gast)]

@Autor: Jörg Wunsch (dl8dtl)

Wow, der GCC 4.7.2 ist ja voll schlau.
Besten Dank dafür!

Aber Sorry, ich hätte erwähnen müssen, das mein µC ein ADuC7126 und der 
Compiler der Keil Realview??? ist.
Mein Fehler.

Ich denke, ich lasse das jetzt so als Tabelle.

Kann man (nur so interessenhalber) das noch anders programmieren?
Diese Tabelle wird ja nur einmal lokal benötigt.

[Mac (Gast)]

Da du mouse_piano aus Zweierpotenzen abfragst, kannst du die Werte für 
mouse_piano auch direkt aus den abgefragten Bits bestimmen.

z.b. ist (GP0DAT & (1<<1)) enweder 2 oder 0. Bei 2 addierst du aber 1 
zu mouse_piano, also:

   mouse_piano += (~GP0DAT & (1 << 1))>>1;

Wenn man alle vier Fälle zusammenfasst ergibt sich:

    mouse_piano=((~GP0DAT & (1 << 1))>>1)
               +((~GP4DAT & (1 << 6))>>5)
               +((~GP0DAT & (1 << 6))>>4)
               +((~GP3DAT & (1 << 0))<<3);

[Jörg W. (dl8dtl) (Moderator)]

Kapitän Nuss schrieb:
> Aber Sorry, ich hätte erwähnen müssen, das mein µC ein ADuC7126 und der
> Compiler der Keil Realview??? ist.

Tja, du schreibst aber gerade im GCC-Forum ...

[Karl H. (kbuchegg)]

Kapitän Nuss schrieb:

> Kann man (nur so interessenhalber) das noch anders programmieren?

Natürlich.

Schau dir die case Werte an. Die sind schön regelmässig aufsteigend. 
Schau dir die zugewiesenen Werte an. Auch dort ist so etwas wie ein 
regelmässiges Muster zu erkennen.
Das legt es nahe, dass es eine Formel geben muss, die das eine in das 
andere überführt.

Sieht man sich die Zahlen mal genauer an, dann entdeckt man schnell eine 
Art 3-er Gruppierung. Zugewiesen werden im Grunde immer nur die 3 Zahlen 
1, 2 und 5 mit jeweils einem anderen Faktor einer Zehnerpotenz.

nimmt man also den Rest von parameter1 bei der Division durch 3, dann 
sagt einem dieser Rest, ob man jetzt mit 1, 2, oder 5 zu hantieren hat. 
Und das Divisionsergebnis selber sagt einem, wieviele 0-en noch an diese 
1, 2 oder 5 anzuhängen sind.

Aus dieser Beobachtung jetzt eine Idee für ein algorithmisches Verfahren 
(zb auch unter Zuhilfenahme 1 oder 2 Tabellen) herzuleiten, ist dann 
nicht mehr weiter schwer.

Nur lohnt sich das in diesem Fall bei 15 Zahlen nicht. Anders sieht es 
aus, wenn man eine wirklich große Tabelle hätte, die auch regelmässig 
gewartet werden muss. Dann wird eine einzige Tabelle mit vielen 
Einträgen schnell unübersichtlich.

[Kapitän Nuss (Gast)]

Jörg Wunsch schrieb:
> Tja, du schreibst aber gerade im GCC-Forum ...

sorry stimmt, war aber keine böse Absicht, nur Gedankenlosigkeit.

Schade das wir hier kein Keil-Realview-Forum haben!

[Karl H. (kbuchegg)]

Kapitän Nuss schrieb:
> Jörg Wunsch schrieb:
>> Tja, du schreibst aber gerade im GCC-Forum ...
>
> sorry stimmt, war aber keine böse Absicht, nur Gedankenlosigkeit.
>
> Schade das wir hier kein Keil-Realview-Forum haben!

Schreib einfach dazu, dass du den Keil Compiler benutzt.
Abgesehen davon wird das gcc Forum sowieso immer mehr zu einem "C 
Fragen, die auf einem µC auftreten" Forum. (Im Gegensatz zu all dem 
PC-spezifischen Dingen, die gehören ins PC-Forum).
Die Moderatoren hatten das mal untereinander diskutiert und ich glaube 
mich zu erinnern, dass wir darüber soweit Konsensus hatten, das gcc 
Forum mehr als "C Forum für den AVR" anzusehen.

In diesem Sinne hat Jörg schon recht: gcc ist die Default-Annahme. Wenn 
die nicht stimmt, sollte man das erwähnen.

[Roland H. (batchman)]

Kapitän Nuss schrieb:
> Ist es nicht besser das als Tabelle zu machen, anstelle von switch/case?

Es gibt Fälle, in welchem switch/case besser abschneiden kann:

- Im Falle von switch/case mit einem const Parameter optimiert der 
Compiler den Rest u. U. weg (evtl. auch nur bei C++).

- Ebenso im Falle von templates, in welchem das switch/case vom 
Template-Parameter abhängt.

[Johann L. (gjlayde)]

A. K. schrieb:
> Bei wie hier sequentiellen Werten ist eine Tabelle vorzuziehen.

Das kann GCC selba mit -ftree-switch-conversion, automatisch aktiviert 
ab -O<guckst-du-in-doku>.

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

Johann L. schrieb:
> Das kann GCC selba mit -ftree-switch-conversion, automatisch aktiviert
> ab -O<guckst-du-in-doku>.

Yep, siehe oben. Tabelle ist jedenfalls nicht schlechter, bei sicherlich 
vielen Compilern aber besser. Wie hält sein Keil das?

[Johann L. (gjlayde)]

A. K. schrieb:
> Johann L. schrieb:
>> Das kann GCC selba mit -ftree-switch-conversion, automatisch aktiviert
>> ab -O<guckst-du-in-doku>.
>
> Yep, siehe oben.

Ja, lesen hilft ;-)

> Tabelle ist jedenfalls nicht schlechter, bei sicherlich
> vielen Compilern aber besser.

Bei avr-gcc liegt die Tabelle jedenfalls im RAM (.rodata), siehe auch 
PR49857:

http://gcc.gnu.org/PR49857