PureBoard

Kann mir einer erklären, warum der Compiler(x64) hier meckert?"AND" kann man genauso gut durch XOR, OR usw. ersetzen....alles fail!


Aber DAS hier funktioniert:
PB 5.24 LTS
Edit by NicTheQuick: Threadtitel angepasst

Wäre das jetzt x86, hätte ich es mir noch dadurch erklären können, dass alles über $7FFFFFFF negativ ist. In der Tat geht nämlich dieser Code hier: Als ob er die Zahl als Long interpretiert, sie dadurch als negative Zahl interpretiert wird, und er dann eben meckert.
Das erklärt aber nicht, warum $FFFFFFFFFFFFFFFF funktioniert.

Vielleicht kannst du dir mit einer Konstanten behelfen:

Nee, ist kein Bug ! Wichtig ist zu wissen, das für aktuelle (AMD-/Intel-) CPUs (x86, x64 oder sonstwas) der an die CPU für eine Instruktion übergebene Opcode max. 15 Bytes lang sein darf. Im 64-Bit-Modus ergäben sich aber schnell längere Sequenzen (zusätzliche Prefixe, direkte Adressierung 8 Bytes usw.). Dies wird durch Restriktionen verhindert; eben z.B. das nur MOV Register64 mit einem 64-Bit-Wert erlaubt ist. ALLE anderen Operationen sind auf einen positiven 32-Bit-Wert begrenzt. Aber natürlich keine Regel ohne Ausnahmen, wobei diese Ausnahmen Eigenheiten der Opcode-Codierung widerspiegeln. Erlaubt sind Werte-Kombinationen, die max.4 Byte (Wert) lang sind, aber real längere Werte repräsentieren. Also, wer denkt, das im Opcode mit 16x "F" daherkommt, der irrt. Der Opcode lautet nämlich simple Die Regeln dafür sind rel. simpel (z.B. AND RAX , EFFFFFFFFFFFFFFF würde nicht funktionieren), aber meine Empfehlung: Nur MOV mit 64-Bit-Werten, ansonsten Zwischenschritt eben mit MOV und Hilfs-Register zwischenschalten. Und: Was mit Register RAX (EAX) funktioniert, kann mit anderen Registern schon schief gehen (RAX/EAX haben mitunter eigenen Opcode).

Gruß
Helle

Cool, super Antwort! Danke!

Danke Helle! Du machst deinem Namen alle Ehre

(Ich war in den '80ern mal bei Control Data/Frankfurt. Da kannte ich auch einen "Helmut aus Magdeburg" (Nachnamen leider vergessen). Warst das vielleicht du?)

Ich nix Helmut, ich Helle ! Ist von meinem Nachnamen abgeleitet, und das schon seit Beginn der Schulzeit. Und das ist weiß Gott schon etwas her...
Aber nochmal Richtung Topic 64-Bit: Nicht nur die Immediates sind auf 4 Bytes begrenzt (MOV s.o.), auch z.B.Sprungadressen. Bei 32-Bit kann man die Sprung-Ziel-Adresse im Code noch direkt auslesen. Bei 64-Bit könnte die ja (muss nicht!) größer 4 Bytes sein. Also hat man dort die relative Adressierung mit 4 Bytes eingeführt. Es wird nicht mehr die tatsächliche Adresse verwendet, sondern der Offset von Sprung-Ausgang zu Sprung-Ziel; d.h. das Sprung-Ziel muss erst berechnet werden.

Gruß
Helle