reihenfolge der bits in einem byte umdrehen

Das musst Du schon selbst erledigen. Eine Funktion gibt es dafür nicht.

Kommt es auf Geschwindigkeit an, dann ließe sich eine Tabelle mit 256 
Einträgen verwenden ...

Und, hast du mal nachgerechnet, wie elegant das wirklich ist?

Das letzte Mal, als ich es nachgerechnet habe, war die simple Schleife
bei einem Byte, das es umzudrehen gilt, kürzer und schneller.

Abgesehen vom bekannten Problem der überflüssigen Bearbeitung der
high bytes, was bitte würdest du an diesem Code noch großartig
verbessern wollen?

Du hast vergessen, dass der "smart" aussehene C-Code auf einer
Maschine, die nicht shift/rotate N kann, sondern nur shift/rotate 1
zwangsläufig einen ganzen Batzen Code erzeugen muss.

Versuch mal das hier:

1

unsigned char mirror( unsigned char a )

2

{

3

  a = ((a >> 4) & 0x0F) | ((a << 4) & 0xF0);

4

  a = ((a >> 2) & 0x33) | ((a << 2) & 0xCC);

5

  a = ((a >> 1) & 0x55) | ((a << 1) & 0xAA);

6

7

  return a;

8

}

Peter

Peter wrote:

> Ich finde dazu dazu gehört auch dass er erkennen müsste, wenn int
> Konstanten auf 1 Byte reduziert werden dürfen, weil alle anderen
> Terme des Ausdrucks ebenfalls nur 8-Bit Werte sind.

Dass er das oft nicht (richtig gut) kann, ist ein alter Hut.  Das
liegt einerseits daran, dass das bei GCC sonst für kaum ein anderes
Target wirklich notwendig ist (weil deren natürliche Wortbreite den
Mindestforderungen an ein int gemäß C-Standard entspricht), zweitens
liegt es wohl (so hat mir mal jemand gesagt) daran, dass der AVR-GCC
nicht als richtige 8-bit-Maschine implementiert ist, sondern als
fiktive 16-bit-Maschine, bei der dann Ausnahmen für 8 bits separat
definiert worden sind.

> Das mindeste wäre, dass wenn ich schon die Konstanten explizit auf
> unsigned char caste, keine 16 Bit Operationen mehr erzeugt werden.

Du kannst die Konstante casten wie du willst, der C-Standard verlangt,
dass die Rechnung so auszuführen ist, als wären alle
Zwischenergebnisse wenigstens vom Typ "int".  Genau das macht der
Compiler dann folglich erst einmal (damit die compliance
sichergestellt ist), und beim anschließenden Erkennen, dass das obere
Byte nichts zum Ergebnis beitragen kann, fehlt's zuweilen.

Davon abgesehen funktioniert es mit Peters Version schon recht gut.
Dort fehlt eigentlich fast nur noch die Erkenntniss, dass

1

        mov r25,r24

2

        swap r25

3

        andi r25,0xf0

4

        swap r24

5

        andi r24,0x0f

6

        or r24,r25

7

        mov r25,r24

nichts weiter als

1

        swap r25

2

        mov r24,r25

macht.  Das müsste man wohl dem Optimizer wirklich mal beibringen
können, gibt's hier jemanden, der genügend RTL versteht das zu tun?
;-)

Dennoch, wenn du's insgesamt nachrechnest, selbst mit dem reparierten
swap ist das Ergebnis nicht wirklich besser (gleich schnell mit mehr
Code) als mit einer einfachen Schleife.  So genial dieser Algorithmus
für große Zahlen ist, bei 8 bits kann er seinen Charme nicht
ausspielen.

Peter wrote:

> Okydoky, der Loop ist dann offenbar tatsächlich die beste Lösung, wenn
> man nicht etwas in Assembler stricken möchte!

Du hast es immer noch nicht verstanden: selbst in Assembler wirst du
nicht besser werden als mit der Schleife.

<WAS> ist schon besser?
Wenn das selten gemacht wird, dann "besser" ggf. wenig Speicherbedarf 
haben, die Laufzeit ist nicht so wichtig.
Muss das sehr oft getan werden, ist es genau andersherum.
Im Extremfall lohnt es sich, eine Tabelle mit den gespiegelten Bitwerten 
anzulegen und darauf zugreifen:

1

PROGMEM uint8_t bit_revers_tab[256] = { 0x00, 0xF0, 0x40, 0x20, ...};

2

uint8_t my_revers_byte;

3

uint8_t my_byte;

4

5

  my_byte = 0x01;

6

  my_revers_byte = pgm_read_byte(bit_revers_tab + my_byte;);

Das ist zwar unschlagbar schnell, dafür schmerzen die 256 Tabbellenbytes 
vielleicht.


Gruß, Stefan

Stefan Kleinwort wrote:

> Wenn das selten gemacht wird, dann "besser" ggf. wenig Speicherbedarf
> haben, die Laufzeit ist nicht so wichtig.

Es ging ja darum, dass die mit der Hand entrollte und in Assembler
codierte Form dieses lustigen Algorithmus weder schneller noch
kürzer als die einfache Schleife ist, wenn man nur 8 bits hat.

> Im Extremfall lohnt es sich, eine Tabelle mit den gespiegelten Bitwerten
> anzulegen und darauf zugreifen:

Ja, das ist unbestritten die schnellste Variante.

1

PROGMEM uint8_t bit_revers_tab[256] = { 0x00, 0xF0, 0x40, 0x20, ...};

Spot-the-Error ... ich würde als zweites Byte 0x80 in die Tabelle 
eintragen, das gibt sonst witzige Effekte.

oh sorry .. 0x80 war doch im Kopf, wie kommt denn da 0xF0 hin?

Gruß, Stefan

Ein Kompromiss zwischen Codegröße und Geschwindigkeit wäre es, nur 16 
Nibbles abzulegen und aus der Tabelle zu holen.
So habe ich das bei meinen Bytes gemacht und es müsste auch für 16 und 
32 Bit Zahlen funktionieren.


PS: ich weiß dass der thread älter ist, aber es war der erste Treffer in 
meiner Suche und beinhaltet viele Lösungsvorschläge, da dachte ich 
sollte dieser nicht fehlen :)

Register Stunden "spiegeln". Ergebniss in temp speichern:

sbrs r16, 0
sbr r17, 0b10000000
sbrs 16, 1
sbr r17, 0b01000000
sbrs r16, 2
sbr r17, 0b00100000
sbrs r16, 3
sbr r17, 0b00010000
sbrs r16, 4
sbr r17, 0b00001000
sbrs r16, 5
sbr r17, 0b00000100
sbrs r16, 6
sbr r17, 0b00000010
sbrs r16, 7
sbr r17, 0b00000001

fertig... läuft... ganz ohne tabellen

Daniel Polz wrote:
> Register Stunden "spiegeln".

Stunden?  Nein, Jahre.  Später als die letzte vorhandene Antwort...

> fertig... läuft... ganz ohne tabellen

Aber halt auch mit 17 Takten.  Ein Tabellenzugriff in eine ROM-
Tabelle geht schneller.

Jörg Wunsch wrote:

> Aber halt auch mit 17 Takten.  Ein Tabellenzugriff in eine ROM-
> Tabelle geht schneller.

Wirklich? Ist der Flash tatsaechlich so schnell? Eine Lookup-Tabelle 
muss ja auch nur 254 Bytes gross sein, wenn man die Operation haeufig 
braucht koennte es sich auch lohnen, sie im SRAM zu halten.

@ Michael G. (linuxgeek) Benutzerseite

>Wirklich? Ist der Flash tatsaechlich so schnell?

RTFM. Der AVR braucht für einen Flashzugriff 3 Takte, für den SRAM 2.

>braucht koennte es sich auch lohnen, sie im SRAM zu halten.

Geringfügig.

MFG
Falk

dö schrieb:
> Peter Dannegger schrieb:
>
>>       Versuch mal das hier:
>> unsigned char mirror( unsigned char a )
>> {
>>   a = ((a >> 4) & 0x0F) | ((a << 4) & 0xF0);
>>   a = ((a >> 2) & 0x33) | ((a << 2) & 0xCC);
>>   a = ((a >> 1) & 0x55) | ((a << 1) & 0xAA);
>>
>>   return a;
>> }
>>
>>
>> Peter
>
>
> gehe ich richtig der annahme, dass wenn ich das ganze für 16 bit machen
> will, ich nur noch eine zeile mit 8 einfügen muss und die Vergleiche
> entsprechend ergänzen??

Warum probierst du es nicht einfach aus?


Würde ich so machen:

1

uint16_t mirror16( uint16_t a )

2

{

3

  return mirror( a >> 8 ) | ( mirror( a ) << 8 );

4

}