Frage:
Das ganze läuft auf einem 16Bit, PIC24F
Meiner Ansicht nach würde der zweite code deutlich schneller ablaufen
als der erste.
Jedoch ist genau das gegenteil der Fall.
Warum?
Naja nur das ist schon nen gewaltiger unterschied.
Ich will mich ja nicht über die paar instruction cycles aufregen, nur
wenn der das überall so macht, mir ist das ja nur durch zufall
aufgefallen.
Simon M. schrieb:> Meiner Ansicht nach würde der zweite code deutlich schneller ablaufen> als der erste.
Warum sollte es das? Beim 2. If machst du eine &-Verknüpfung, beim 1.
übergibst du nur ein Bit. Ist doch klar, dass der 1. Code viel schneller
sein muss.
Rainer U. schrieb:> Weil es der Compiler so übersetzt hat, dass er sinnloserweise mit 16bit> statt 8 bit Variablen arbeitet?
Die PIC24 sind 16-Bitter
Simon M. schrieb:> #define STATUS1_SEQERR 0x00080000
Ich sehe da 32 Bit
MfG Klaus
Klaus schrieb:> Die PIC24 sind 16-Bitter>> Simon M. schrieb:>> #define STATUS1_SEQERR 0x00080000>> Ich sehe da 32 Bit
wo?
auch eine 000000000000000000000008 sind nur 8 bit.
ein define ist überhaupt keine Variable und hat sogar 0 bits.
Peter II schrieb:> wo?>> auch eine 000000000000000000000008 sind nur 8 bit.>> ein define ist überhaupt keine Variable und hat sogar 0 bits.
absolut richtig. Wenn dann müsstest du schon explizit casten, wenn du
sicher 32bit haben willst
Simon M. schrieb:> Meiner Ansicht nach würde der zweite code deutlich schneller ablaufen> als der erste.
Mit dieser Ansicht bist du deutlich in der Minderheit.
> Jedoch ist genau das gegenteil der Fall.> Warum?
Weil der Compiler aus der & Verknüpfung von Variable und Bitmaske nicht
abliest, daß er in Wirklichkeit nur ein Bit testen muß. Ein exzellent
optimierender Compiler könnte die konstante Bitmaske natürlich daraufhin
abklopfen. Aber der real existierende Compiler macht es offensichtlich
nicht, sondern implementiert das
1
if (variable & maske)
auf die kanonische Weise, indem er alle Bits der Variable mit allen Bits
der Maske ver-UND-et und dann testet, ob irgend ein Bit gesetzt ist.
Auf einer Architektur mit einer 32-Bit ALU wäre das gleich schnell. Dein
16-Bitter braucht aus offensichtlichen Gründen länger.
Interessant wäre, was der Compiler hieraus macht:
Axel S. schrieb:> Ein exzellent optimierender Compiler
... ist das in diesem Fall jedenfalls nicht - oder die Optimierung war
abgeschaltet. Denn der ASM2 Code ist für optimierten Code wirklich unter
aller Sau.
Ich meine mich zu erinnern, dass Microchips freie Compiler-Version bei
Optimierung eingeschränkt ist. Intern ist der Compiler von Microchip der
GCC plus etwas proprietärem Kram. Und der GCC sollte sich nicht so doof
anstellen. Wenn man ihn lässt.
Steffen N. schrieb:> volatile unsigned long x;
Das "volatile" zwingt den Compiler, alle 32 Bit zu lesen. Ansonsten wäre
es ein Fehler.
Besser ist für vergleichende Tests, den Code jeweils in eine
Unterfunktion zu packen mit den Variablen als Argument bzw. Returnwert.
Dann entfallen alle Seiteneffekte.
Und ein Leser kann den Code compilieren, ohne hellsehen zu müssen,
welchen Typ Deine Variablen haben.
Hallo Peter,
Danke für den Tipp. Ja ich hatte die Variable als volatile deklariert,
da sonst das ganze if-Konstrukt wegoptimiert wurde. Jetzt hab ich es
nochmal, wie von dir vorgeschlagen, als Funktion getestet. Hier das
Ergebnis.
So lange der Vorrat reicht.
... ist eine Strategie, die die Compiler klaglos unterstützen.
Der Bug sitzt meist an der Tastatur.
Werden einfach, kritiklos Variablen definiert, so gehen die Compiler, im
Allgemeinen, davon aus, dass das Ganze auch ernst gemeint ist. Ihn
interessiert nicht, ob eine 32-Bit Variable nur im Bereich vom 0 bis 20
genutzt wird. Setzt also die passenden Rechenalgorithmen ein.
Thread beobachten
Seitenaufteilung abschalten