Ich lese oft ähnliche code snippets wie diesen, aber variables Shiften
ist ganz ungünstig vom Compiler zu optimieren und es ist auch (immer)
unnötig und auch die shift Orgie ist unüberlegt. Dieser Mist wird dann
oft x-fach auf github immer und immer wieder in anderen Projekten
verwendet ...
ABER dieser und ähnlicher Code lässt sich im Grunde stark optimieren
unter Beachtung der genannten Schwachpunkte! Gibt es Ideen/Vorschläge?
for(uint8_t i=0; i!=14; i++) {
if((((ncrc14 << (i + 2)) & 0x8000) >> 15) & 1)
{
tempchar[i + 77] = 1;
}
else
{
tempchar[i + 77] = 0;
}
}
Wieso ist dynamisches Shiften "ungünstig vom Compiler zu optimieren"? Wenn die Zielarchitektur sowas unterstützt ist es doch überhaupt kein Problem. Klar der AVR kann das nicht. Da sollte man überlegen ob man den Code nicht ohne dynamischen Shift machen kann. Irgendwie sieht der Code nach Hausaufgabe aus.
Gast
#6941621
Apollo M. schrieb: > lässt sich im Grunde stark optimieren Ja. Warum schreibst du dann nicht den optimaleren code hin der eine temporäre Variable immer nur um 1 Stelle schiebt ?
Gast
#6941638
z.B. so:
1 | |
2 | |
3 | |
4 | |
Andi schrieb: > z.B. so: interessant und hardcore! Ich dachte an das hier ncrc14 <<=2; for(uint8_t i=0; i!=14; ncrc14<<=1, i++) { tempchar[77+i] = !!(ncrc14 & 0x8000); } und da erkenne ich dann auch noch die ursprüngliche Bitstruktur. Mein Gedanke ist keine Maske zu shiften sondern immer das Datenwort selbst. Mal schauen was der Compiler aus den zwei Varianten zaubert und ob es eine ähnliche code size ergibt.
Sebastian V. schrieb: > Wenn die Zielarchitektur sowas unterstützt Auch dann eher kein Argument (z.b. ARM), weil dann immer noch ein Register ständig modifiziert werden muss, das die shift Breite definiert - also weiterhin Mehraufwand im Vergleich zu shift um 1bit Position. Sebastian V. schrieb: > rgendwie sieht der Code > nach Hausaufgabe aus. Wer das schön, nochmal jung zu sein!