Schieben vs. Tabelle

Bertram Bügler schrieb:
> der Compiler den Armen uC jetzt
> tatsächlich 255 x schieben lassen? Oder limitiert der Compiler die
> Schieberei auf 8? Oder legt der Compiler netterweise eine für den User
> unsichtbare Tabelle mit 10 Einträgen an?
Wie er will. Er kann auch intern ein paar Floating-Point Berechnungen 
machen, wenn er meint, dass das notwendig ist und am Ende alles richtig 
ist.

> Ich sollte einen C Compiler für Handy suchen.
Ein Compiler liefert Dir ein Compilat. Das sagt nichts aus über das 
Compilat eines anderen Compilers oder das beim nächsten Start.

Bertram Bügler schrieb:
> Die Frage, nach 8 mal schieben ist alles raus, maske ist dann 0. Würde,
> falls n jetzt zum Beispiel 255 ist, der Compiler den Armen uC jetzt
> tatsächlich 255 x schieben lassen? Oder limitiert der Compiler die
> Schieberei auf 8? Oder legt der Compiler netterweise eine für den User
> unsichtbare Tabelle mit 10 Einträgen an?

Ein Shift der Breite des Typs oder mehr ist undefined behavior

Bertram Bügler schrieb:
> Ich sollte einen C Compiler für Handy suchen.

Oder einen online c- compiler nutzen
https://www.programiz.com/c-programming/online-compiler/

ohne eine programiersprache benutzen die dein Handyresp. App native 
kann. (Java-scripz o.ä.).

Dergute W. schrieb:
> Oder einfach mal 'nen Apfel essen.

Dachte sich Schneewittchen auch:
https://youtu.be/6B3EncbvLnA

Bertram Bügler schrieb:
> Die Frage, nach 8 mal schieben ist alles raus, maske ist dann 0. Würde,
> falls n jetzt zum Beispiel 255 ist, der Compiler den Armen uC jetzt
> tatsächlich 255 x schieben lassen? Oder limitiert der Compiler die
> Schieberei auf 8? Oder legt der Compiler netterweise eine für den User
> unsichtbare Tabelle mit 10 Einträgen an?

Servus,

keine der genannten Variablen ist volatile und falls in "ein paar 
Berechnungen" nirgends ein volatile-Wert genutzt wird, von dem "n" 
abhängt, dann sollte der Compiler das Ergebnis von "maske = 0xFF >> n;" 
bereits zur compile-zeit berechnen können und dann (bei höherer 
Optimierungsstufe) einfach entsprechend zuweisen.

Gruß,
Michael

Michael F. schrieb:
> keine der genannten Variablen ist volatile und falls in "ein paar
> Berechnungen" nirgends ein volatile-Wert genutzt wird, von dem "n"
> abhängt, dann sollte der Compiler das Ergebnis von "maske = 0xFF >> n;"
> bereits zur compile-zeit berechnen können und dann (bei höherer
> Optimierungsstufe) einfach entsprechend zuweisen.
> Gruß,
> Michael

Natürlich wird n berechnet und maske wird weiterverwendet. Und

maske = 0xFF >> n;
seriell_out(maske);
/* seriell_out(0xFF >> n); */
Liegt in einer zeitkritischen Schleife und wird ganz häufig aufgerufen!
Ich könnte natürlich schreiben :

if (n > 8) n = 8; // nötig?!

Aber da ich NICHT "volatile" verwendet habe ist meine Frage ob C 
Compiler (GCC) in hoher Optimierungsstufe mir automatisch die 
Limitierung der Schiebevorgänge auf 8 abnehmen?

Oliver S. schrieb:
> Alles in allem solltest du aber zunächst laufen lernen, bevor du zu
> sprinten beginnst.

Dummer Spruch.


> Das es dazu auf einem AVR viel schneller wäre, die Maske jedes mal um 1
> zu shiften, an statt den Ausgangswert um n,

Wertvoller Hinweis.


Bei Programmieren geht es darum, es gleich von Anfang an richtig zu 
lernen und sich nicht widersinnige Beispiele einfallen zu lassen, nur um 
irgendwelchen Akadämikern was zu beweisen.

Michael F. schrieb:
> keine der genannten Variablen ist volatile und falls in "ein paar
> Berechnungen" nirgends ein volatile-Wert genutzt wird, von dem "n"
> abhängt, dann sollte der Compiler das Ergebnis von "maske = 0xFF >> n;"
> bereits zur compile-zeit berechnen können

Nee, falls da irgend ein Argument der Funktion an den ominösen 
Berechnungen beteiligt ist oder ein HW-Register oder irgend eine globale 
Variable, dann kann das eben nicht zur Compilezeit berechnet werden. Ein 
'volatile' ist da nicht nötig.

W.S.

Oliver S. schrieb:
> Das es dazu auf einem AVR viel schneller wäre, die Maske jedes mal um 1
> zu shiften, an statt den Ausgangswert um n, sei hier nur angemerkt.

Nein n ist nicht etwa der Schleifenzähler, n ergibt sich aus wilden 
Berechnungen mit dem Cordic-Algorithmus. (Der Attiny10 ist 
wahrscheinlich zu klein für float Berechnungen und so mache ich 
Sinus/Cosinus mit dem Cordic-Algorithmus)

Als Tabelle würde das so aussehen

unsigned_8t[9]={0xFF,0x7F,0x3F,0x1F,0x0F,0x07,0x03,0x01,0x00};

unsigned_8t maske[9]={0xFF,0x7F,0x3F,0x1F,0x0F,0x07,0x03,0x01,0x00};

uint_8t
 maske[9]={0xFF,0x7F,0x3F,0x1F,0x0F,0x07,0x03,0x01,0x00};

Irgendwann wirds...

Bertram Bügler schrieb:
> Würde,
> falls n jetzt zum Beispiel 255 ist, der Compiler den Armen uC jetzt
> tatsächlich 255 x schieben lassen?

Er shiftet nur ein mal. Aber gleich um x Bits (und nicht x mal). 
Außerdem ist 0xFF eine int-Varialbe (wieder undefined behaviour sogar 
wenn n klein genug ist).

0xFFU schrieb:
> Er shiftet nur ein mal. Aber gleich um x Bits (und nicht x mal).

Äh nö, die kleinen Attiny haben keinen Barrelshifter AFAIK.
Deshalb habe ich diesen Thread überhaupt gestartet...

Bertram Bügler schrieb:
> maske = 0xFF >> n;
> seriell_out(maske);
> /* seriell_out(0xFF >> n); */
> Liegt in einer zeitkritischen Schleife und wird ganz häufig
> aufgerufen!
> Ich könnte natürlich schreiben :
>
> if (n > 8) n = 8; // nötig?!

Wenn n größer als 8 sein kann, dann ist es absolut nötig, sonst darf der 
Compiler auch Code erzeugen der in dem Fall Deine HDD formatiert, alle 
GPIOs auf wechselnde Zufallswerte setzt oder was ihm sonst lustiges 
einfällt. Wird er zwar wahrscheinlich nicht machen, wäre ja auch 
unnötiger Aufwand, aber falls er es macht, hättest Du keinen Grund Dich 
zu beschweren.

Besser wäre allerdings (weil es den - zumindest bei breiteren Datentypen 
ebenfalls problematischen - Fall n=Bitbreite des zu schiebenden Typs 
auch korrekt abfängt):

1

  maske = (n>7) ? 0 : 0xFF >> n