Hallo Leute, ich steh grad auf dem Schlauch. Unter WinAVR 3.4.5 wird 1<<15 zu 0xFFFF8000. Gibts ein WorkAround (außer aufsplitten auf 4 einzelne Bytes;-)? Gibts noch andere Fallen mit 32-Bit? Bekannt wird es ja wohl sein?! Gruß Frank
Frank N. wrote: > Hallo Leute, ich steh grad auf dem Schlauch. > > Unter WinAVR 3.4.5 > > wird 1<<15 zu 0xFFFF8000. > Ja das ist auch richtig so :-) Wie kommts? 1 ist ein int. 15 ist ebenfalls ein int. Daher wird die ganze Operation 1 << 15 im Zahlenraum int ausgeführt und ergibt 0x8000 Der Datentyp dafür ist natürlich ebenfalls int. Da du aber ein long Ergebnis angegeben hast, gehe ich mal davon aus, dass du diese 0x8000 an einen long zugewiesen hast. Dabei muss der int natürlich auf einen long erweitert werden. Das geschieht selbstverständlich unter Berücksichtigung des Vorzeichens. Und da 0x8000 eine negative Zahl ist, lautet die identische negative Zahl in long 0xFFFF8000 > Gibts ein WorkAround? Aber sicher doch. Du musst nur dafür sorgen, dass der Compiler von vorne herein alles in long, bzw. unsigned long sieht. Und schon ist dein Problem vom Tisch: 1UL << 15
Ja und schon geht es... Danke Karl Heinz - für's Augen öffnen und Lösung finden :-)
Laufzeitmässig könnte es allerdings besser sein, die Schiebeoperation in int machen zu lassen und vor der Erweiterung auf long das Vorzeichen mit einem cast auf unsigned zu unterdrücken (unsigned int)(1<<15)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.