Farben nach R,G,B umwandeln in 4-stell. hex-code?

[Ceos]

Ja, so meinte ich Früher zu Zeiten, als IBM-Computer die ersten PCs waren und dort noch TTL-Schaltkreise verbaut waren, da war das sicher so, beim 286er glaub ich auch noch. Weil jeder Shift-Befehl normalerweise pro verschobenem Bit einen Takt benötigt

bist du dir sicher dass der AVR compiler das automatisch konvertiert?! ein lsr hat den barrel shift aber mir ist kein single clock rsr >1 bekannt. Ich mein ich kann mich irren, aber das ginge glaube ich zu OT. (Schicks mir mal per PM weil ich kenns wirklich nicht)

[Moppi]

Das kann ich auch so beantworten: ich hatte schon geschrieben, dass ich das nicht weiß. Auch nicht, was kompiliert wird. Da muss jemand anders mal was dazu sagen.
Ich kenne Maschinensprache noch vom 80x86. Irgendwann brauchte ich das aber auch nicht mehr. Deshalb ist vieles eingeschlafen. Aber Grundlagen sind noch da. Heute brauche ich Maschinensprache eigentlich auch gar nicht mehr.

- - - Aktualisiert - - -

jap, kommt das gleiche raus, danke!
Ich dachte allerdings bis jetzt, dass shiften in C immer schneller geht als Multipl./Division.
(Rein akademisch, denn das ist momentan absolut nicht zeitkritisch bei mir.)

Kannst Du ausprobieren. Normalerweise kann man eine Schleife bauen, die die Befehlszeile enthält. Der Schleifenzähler muss möglichst groß gewählt werden. Vor der Schleife Timer auslesen und nach der Schleife ebenfalls. Dann kann man sehen wie lange unterschiedliche Lösungsvarianten so brauchen, bzw. welche schneller ist. Kommt ja auch immer drauf an, was der Compiler für einen Maschinencode erzeugt.

[HaWe]

ja, ich habe ja schon mal einen Benchmarktest für verschiedene MCUs geschrieben, könnte ich mal machen



- - - Aktualisiert - - -

edit: Code aktualisiert nach Ceos' Einwand (s.u.!)

#define TimerMS() millis()  //for  cross plattform compatib
uint32_t time0;

long test_Int_multdiv2() {
  uint32_t  x,y;
  volatile uint32_t  s;

  for(y=0;y<10000;y++) {
    s=11;
    for(x=1;x<=16;x++) { s*=2;}
    for(x=16; x>0;x--) { s/=2;}
    s=7;
    for(x=1;x<=8;x++) { s*=8;}
    for(x=8; x>0;x--) { s/=8;}
  }
  return s;
}


long test_Int_shl_shr() {
  uint32_t  x,y;
  volatile uint32_t  s;

  for(y=0;y<10000;y++) {
    s=11;
    for(x=1;x<=16;x++) { s=(s<<1);}
    for(x=16; x>0;x--) { s=(s>>1);}
    s=7;
    for(x=1;x<=8;x++) { s=(s<<3);}
    for(x=8; x>0;x--) { s=(s>>3);}
  }
  return s;
}


// *SNIP*


  time0=TimerMS();
  s=test_Int_multdiv2();
  runtime[0]=TimerMS()-time0;
  sprintf (buf, "%3d %9ld  Int_multdiv2",   0, runtime[0]); Serial.println( buf);


 time0=TimerMS();
  s=test_Int_shl_shr();
  runtime[1]=TimerMS()-time0;
  sprintf (buf, "%3d %9ld  Int_shl_shr",   1, runtime[1]); Serial.println( buf);

Ergebnis: doch identisch, anders als vermutet (Angaben in ms):


Plattform: AVR (Arduino Mega2560, 16 MHz)

start test
  0      1220  Int_multdiv2
  1      1220  Int_shl_shr

Plattform: ARM Cortex M0 (Adafruit Itsybitsy M0, 48 MHz)

start test
  0        93  Int_multdiv2
  1        93  Int_shl_shr

Plattform: ARM Cortex M3 (Arduino Due, 84MHz)

start test
  0        49  Int_multdiv2
  1        49  Int_shl_shr

Pattform: ESP8266 (nodeMCU, Xtensa LX106, 80 MHz)

start test
start test
  0        56  Int_multdiv2
  1        55  Int_shl_shr

edit:
gleiches Ergebnis auch für Zuweisung an 2. Variable:

long test_Int_multdiv2() {
  uint32_t  x,y;
  volatile uint32_t  s,t;

  for(y=0;y<10000;y++) {
    s=11;
    for(x=1;x<=16;x++) { t=s*2;}
    for(x=16; x>0;x--) { t=s/2;}
    s=7;
    for(x=1;x<=8;x++) { t=s*8;}
    for(x=8; x>0;x--) { t=s/8;}
  }
  return s;
}


long test_Int_shl_shr() {
  uint32_t  x,y;
  volatile uint32_t  s,t;

  for(y=0;y<10000;y++) {
    s=11;
    for(x=1;x<=16;x++) { t=(s<<1);}
    for(x=16; x>0;x--) { t=(s>>1);}
    s=7;
    for(x=1;x<=8;x++) { t=(s<<3);}
    for(x=8; x>0;x--) { t=(s>>3);}
  }
  return s;
}

[Ceos]

hey moment mal, du schummelst doch :P

mach mal aus (s << 1) ein s = (s << 1) bzw. 3 natürlich, du schiebst hier eine zahl aber sie wird nicht gespeichert, wenn dem so ist optimiert er den inhalt der schleife wahrscheinlich einfach weg und du hast nur eine leere schleife gemessen

bei der multiplikation und division machst du ja auch eine zuweisung

EDIT: by the way hab cih das mit dem barrel shifter wohl falsch verstanden, den gibt es wohl für links als auch für rechts, aber atmel benutzt beim rsr scheinbar nicht immer den barrel shifter, das warum hat sich mir aus den bisherigen topics nicht wirklich erscshlossen, aber es scheint wohl ein bekanntes phänomen zu sein (primär englische atmel foren die sich mit komplexerer verwendung beschäftigen und nciht mit so trivialen tests)

[HaWe]

hey moment mal, du schummelst doch :P

kleiner Aufmerksamkeitstest

ich korrigiere es sofort!

edit:
Korrektur, sind doch immer jeweils identisch, ist oben korrigiert!

[Moppi]

s=(s<<1); dürfte Quatsch sein. s<<1 genügt und ist dasselbe, solange Variable s existiert. Wozu soll der nach s<<1 nochmal s=s ausführen? Korrigiere mich, wenn ich falsch liege!

[HaWe]

Ceos hatte Recht, es ist ein Unterschied, ich hatte es zuvor auch falsch vermutet. Zu Vergleichszwecken muss die Zuweisung in beiden Fällen gemacht werden, das macht dann im Ergebnis einen Unterschied zu vorher (s.o.), denn jetzt sind die Messwerte identisch nach beiden Methoden (vorher war ja fälschlich shiften schneller) !

[Moppi]

Ja, aber ich bin der Meinung, da wird was verwechselt.

s<<1; verschiebt Variable#S um 1 Bit nach links.

shl var_s,1

Bei Multiplikation (s=s*2)passiert was anderes. Ich denke in etwa so:

mov ax,var_s
mov bx,2
mul bx
mov var_s,ax

oder so:

mov ax,var_s
mul 2
mov var_s,ax

oder so, falls es möglich wäre:

mul var_s,2

Vom Prinzip her kommt es drauf an, was der Compiler für Maschinencode erzeugt.

Mit S=S<<1 machst Du in etwa so etwas:

mov ax,var_s
shl ax,1
mov var_s,ax

Das meine ich, ergibt keinen Sinn. Unnötige Operationen einzufügen. Wenn dann optimiert man einen Code, damit er schneller abgearbeitet wird. Und nicht, damit eine Befehlssequenz, die schneller ist, genau so schnell wird, wie eine andere, die langsamer ist.
Wichtig wäre zu wissen, ob s<<1 zum selben Ergebnis führt, wie s=s*2.

[HaWe]

interessanter Gesichtspunkt...
s ist ja immerhin volatile, also darf der Compiler diese Operation nicht wegoptimieren (was gpp sonst automatisch macht).
Dadurch wird das Shiften also keine Null- oder Leernummer.


Da müssen jetzt mal die hier einschlägig bekannten C/C++ Spezialisten etwas sagen...

- - - Aktualisiert - - -

habe jetzt mal den Mess-Code per Zusatz-Variable auf einen gemeinsamen Nenner gestellt:

long test_Int_multdiv2() {
  uint32_t  x,y;
  volatile uint32_t  s,t;

  for(y=0;y<10000;y++) {
    s=11;
    for(x=1;x<=16;x++) { t=s*2;}
    for(x=16; x>0;x--) { t=s/2;}
    s=7;
    for(x=1;x<=8;x++) { t=s*8;}
    for(x=8; x>0;x--) { t=s/8;}
  }
  return s;
}


long test_Int_shl_shr() {
  uint32_t  x,y;
  volatile uint32_t  s,t;

  for(y=0;y<10000;y++) {
    s=11;
    for(x=1;x<=16;x++) { t=(s<<1);}
    for(x=16; x>0;x--) { t=(s>>1);}
    s=7;
    for(x=1;x<=8;x++) { t=(s<<3);}
    for(x=8; x>0;x--) { t=(s>>3);}
  }
  return s;
}

auch hier: beide identisch!

ARM Cortex M0

start test
  0        93  Int_multdiv2
  1        93  Int_shl_shr

AVR (Mega2560)

start test
  0      1220  Int_multdiv2
  1      1220  Int_shl_shr

Fazit:
wenn einfach nur eine Variable erhöht werden soll, ist shiften schneller als Multipl./Division.

Wenn aber Werte zugewiesen und damit weiter gerechnet werden soll, sind beide gleich schnell, und das war ja hier die vorrangige Fragestellung

[Moppi]

wenn einfach nur eine Variable erhöht werden soll, ist shiften schneller als Multipl./Division.

Variable erhöhen: v=v+1 (bspw.: inc)
Multiplizieren mit 2: v=v*2 oder eben v=v<<1 (bspw.: shl)

Aber das ist ein ganz anderes Thema, gehört hier nicht mehr rein, denke ich.