kleine Frage zum Int16 auf nen 8-Bit controller

[kautz]

Hallo,
der atmega8 ist doch ein 8-Bit-Controller.
Wenn ich jetzt folgenden code nehme:

uint8_t high,low;
uint16_t ui16;
ui16 = (high << 8) + low;

Wird der Controller dann in dem ui16 Wert das Richtige stehen?
Macht der compiler das für mich? Da stecken ja dann mehrere Assembler-Befehle dahinter.

[Ceos]

jo ist völlig in ordnung so, mahc ich auch immer so

[Besserwessi]

Genau für so etwas hat man den Compiler, damit man sich nicht um die Details kümmern muß.

[SprinterSB]

Die Operationen bedingen implizite Typ-Erweiterungen auf int. Je nachdem, wie groß ein int ist, funktioniert es also (mindestens 16 Bit) oder nicht. Letzteres kann passieren, wenn man avr-gcc mit der Option -mint8 verwendet.

[Ceos]

ah stimmt , der part (high << gibt bei (high << 16) nur 0 aus, du müsstest bei allem was grüßer 16bit iss also auch explizit nen cast machen damit er weis womit errechnen soll

[SprinterSB]

Im Zweifalsfalle ein C-Buch fragen. Oder einfach anschauen, was der Compiler draus bastelt...

[yaro]

Anstatt es 8 mal logisch nach links zu schieben, könnte es unter Umständen sogar besser sein, es mit 256 zu multiplizieren, denn die Mega-Familie verfügt über hardware-Multiplikation, die bei zwei bytes nur 2 Takte dauert. Dann kommen noch ca. 3 Takte zusätzlich für interne Registerbefehle hinzu. Macht insgesammt ca. 5 Takte anstatt der sonstigen (mindestens) 8 Takte.

Gruß, Yaro

[Besserwessi]

Ein guter Compiler sollte erkennen das <<8 ein shift um ein Byte stattfindet und gleich das richtige Byte nehmen. Wenn man den Compiler auf die Sprünge helfen will, da wohl besser geleich indem man die variabel als Union definiert und so auf die einzelenen Bytes zugreifen kann.

Für Zugriffe auf 16 Bit breite Register (z.B Timer, ADC) hat GCC Vorkeherungen für den direkten Zugriff. Da kümmert sich der Compiler sogar um die Reihenfolge in der H/L Byte gelesen bzw. geschrieben werden.