mikrocontroller.net

Forum: Compiler & IDEs Bitshift + long geht nicht (WinAVR)


Autor: ABu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab hier ein seltsammes Verhalten des GCC-Compilers:

unsigned long Var;

Var = 1 << 24; // Compiler: warning: left shift count >= width of type


Die Zeile mit dem Bitshift wird immer rausgeworfen, egal wie der 
Optimizer eingestellt ist.

Die Variable REG ist aber definitiv 4Byte lang, im Disassembler ist zu 
sehen, dass 4Bytes angelegt werden.

Hat jemand eine Idee woran das liegen kann?

Danke
ABu

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ ABu (Gast)

>Var = 1 << 24; // Compiler: warning: left shift count >= width of type

Ein Klassiker. Versuchs mal damit.

Var = 1L << 24;

>Die Variable REG ist aber definitiv 4Byte lang, im Disassembler ist zu
>sehen, dass 4Bytes angelegt werden.

Ja, aber die Konstante 1 wird als 16 Bit INT gewertet ;-)

MfG
Falk

Autor: sch_michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist eigentlich ganz richtig, dass du dies im Assembler Code nicht 
findest, da ja der Präprozessor bereits diese Shiftoperation umsetzt. 
Eigentlich willst du ja nichts anderes als der Variable den Wert 
0x1000000 zuweisen und genau das erkennt der Präprozessor und setzt dies 
gleich in den oben genannten Wert um.

Autor: ABu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prima -Danke!

ABu

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sch_michael wrote:

> ..., da ja der Präprozessor bereits diese Shiftoperation umsetzt.

Das fällt in den Bereich `urban legend'.

Der Präprozessor ersetzt Texte, und zwar alle die, die mittels
#define in einem Makro definiert worden sind, und er zieht die
#include-Dateien rein.  Mehr macht er nicht.

Das hier ist teil des Optimierers im Compiler.  Es bewirkt eine
Ersetzung von Ausdrücken, die zur Compilezeit konstant sind, durch
ihre Äquivalenten Rechenergebnisse.

Aber selbst ohne Optimierung wäre hier nichts anderes herausgekommen
(da die Rechnung ja im 16-bittigen Bereich gemacht worden ist), es
hätte nur länger gedauert. ;-)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sch_michael wrote:

> 0x1000000 zuweisen und genau das erkennt der Präprozessor und setzt dies
> gleich in den oben genannten Wert um.

Um genau zu sein macht das nicht der Präprozessor sondern
der Compiler selbst.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.