bitshifting in GCC mit einem Byte

Gast #1803703
Lesenswert?

Hallo

Ich hab ein komisches Problem an dem ich schon seit heute Vormittag 
sitze und einfach nicht die Lösung finde.

Ich schreibe eine Bibliothek für ein LCD mit mehreren Grafikfunktionen.

Nun hab ich ein Problem mit einer Bitshifting Operation, wo ich einfach 
nicht den Fehler finde.

Folgender Code (auszugsweise):

uint8_t pattern = 0x66; // 0b 0110 0110

pattern >>=2 ; // um 2 Bit nach rechts schieben


Nun würde ich mir das folgende Ergebnis erwarten:

1001 1001

Ich erhalte jedoch 0001 1001

Es sieht so aus als würde die Operation die 2 Bit nur rechts 
hinausschieben jedoch nicht links wieder einfügen, wie das bei der 
Assember Funktion rol bzw ror ist.

Wie kann ich den GCC dennoch davon überzeugen so ein bitweises Shiften 
durchzuführen?

MfG Gregor
Gast #1803733
Lesenswert?

Die Operatoren << und >> sind Shift -Operatoren. Deine rol und ror 
sind rotate -Befehle.
Shift  == Schieben
Rotate == Rotieren
Rotieren musst du in C selber bauen oder mal Inline-Assembler testen. 
Bei [1] scheint die richtige Funktion von Inline-Assembler angezweifelt 
zu werden, also probiere es vorher aus, oder baue dir selbst eine 
Funktion in C.

[1] 
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=454612
[2] http://www.rn-wissen.de/index.php/Inline-Assembler_in_avr-gcc
#1803797
Lesenswert?

Floh schrieb:
> void ror(uint8_t &var)
> {

Erheblich kürzer, auch im generierten Code:
1
var = (var << 7) | (var >> 1);

Schneller in Punkto Taktzyklen ist es allerdings nicht, braucht nur 
weniger Speicher.

Andreas

PS: das mit den Taktzyklen war natürlich jetzt AVR-zentrisch, der OP 
hatte aber nicht erwähnt, dass er das verwenden würde. Andere 
Architekturen können andere Ergebnisse liefern, der x86-GCC z.B. macht 
bei -O2 aus meiner Zeile oben sogar wirklich ein ROL (um 7 Bits, also 
effektiv ROR), im Gegensatz zu der Variante mit Verzweigung, die mehr 
oder weniger "wörtlich" übersetzt wird.
Gast #1803874
Lesenswert?

@ Andreas Ferber (aferber)
Oder gleich [1] befolgen, bei mir hat es geklappt.
Die Vermutung aus [1], dass das nur schiebt und nicht rotiert, stimmt 
nicht auf meinem x86_64 zumindest nicht. Bei einem µC sollte man das 
wohl nochmal simulieren oder mit ein paar LEDs testen...

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren