SHL in QWord

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut
Antworten
Vbxler
Beiträge: 129
Registriert: Sa 25. Mai 2013, 07:43
OS, Lazarus, FPC: Win7_x64 (FPC:4.7.1)
CPU-Target: 32Bit

SHL in QWord

Beitrag von Vbxler »

Ich vesuche vier Word's in ein Qword zu packen.

Code: Alles auswählen

var    
    aFileVersion    : array[1..4] of Word;   
    qwVersion       : QWord = &0;
    dwVersion       : DWORD = &0;  
Wenn ich die Doppelwortgrenze nicht überschreite geht es:

Code: Alles auswählen

dwVersion := (aFileVersion[1] shl 24) or (aFileVersion[2] shl 16) or (aFileVersion[3] shl 8)  or aFileVersion[4]; 
Wenn ich aber auf Qword erweitere kommt ein blödsin raus:

Code: Alles auswählen

qwVersion:= (aFileVersion[1] shl 48) or (aFileVersion[2] shl 32) or (aFileVersion[3] shl 16)  or aFileVersion[4]; 
Hat jemand eine Idee, woran das liegen kann?


Danke!
Vbxler
-------------------------

indianer-frank
Beiträge: 134
Registriert: So 30. Nov 2008, 21:53

Re: SHL in QWord

Beitrag von indianer-frank »

Was kommt denn wohl raus, wenn ein word 48 bits nach links geshiftet wird? Eine Lösung ist

Code: Alles auswählen

 qwVersion := (QWord(aFileVersion[1]) shl 48) or
             (QWord(aFileVersion[2]) shl 32) or
             (aFileVersion[3] shl 16)  or aFileVersion[4];
 

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: SHL in QWord

Beitrag von mschnell »

AFAIK:

Operationen werden mit einem Typ durchgeführt, der mindestens so groß ist wie der größere der Operanden. Der Type der Variablen, auf die das Ergebnis zugeordnet wird ist für die Operation egal.

Das gilt auch für die inneren Operationen in längeren Termen.

Also wird in Deinem zweiten Beispiel innen nicht mit QWords gerechnet.

-Michael

indianer-frank
Beiträge: 134
Registriert: So 30. Nov 2008, 21:53

Re: SHL in QWord

Beitrag von indianer-frank »

mschnell hat geschrieben:AFAIK:
Operationen werden mit einem Typ durchgeführt, der mindestens so groß ist wie der größere der Operanden. Der Type der Variablen, auf die das Ergebnis zugeordnet wird ist für die Operation egal.
Das ist wohl richtig, allerdings ist es nicht immer ganz einsichtig was, wann, wo gemacht wird. ZB wird

Code: Alles auswählen

aFileVersion[1] shl 20
'richtig' berechnet, obwohl 'eigentlich' 0 rauskommen müßte. Noch schlimmer ist das Durcheinander bei Fließkomma:

Code: Alles auswählen

var
  d: double;
  n: integer;
begin
  n := 3;
  d := 1.0/n;
  writeln(d:30, n*d - 1.0:30);
end. 
Dies ergibt in der 64-Bit-Windowsversion das Ergebnis 3.33333343267441E-001 2.98023223876953E-008, ist also völlig falsch, das gleiche Programm mit 32-Bit-Windowsversion liefert erwartungsgemäß 3.33333333333333E-001 -5.55111512312578E-017. Dummerweise betrachten die FPC-Entwickler dies als Feature und nicht als Bug! (Erklärung: 1.0/n in single gerechnet!)

Vbxler
Beiträge: 129
Registriert: Sa 25. Mai 2013, 07:43
OS, Lazarus, FPC: Win7_x64 (FPC:4.7.1)
CPU-Target: 32Bit

Re: SHL in QWord

Beitrag von Vbxler »

Danke für eure Hilfe.

ich mache es jetzt mit:

Code: Alles auswählen

    aFileVersion    : array[1..4] of Word = (&0, &0, &0, &0);
    qwVersion       : QWord absolute aFileVersion;
Ih finde auch, dass das kein besonders gutes Feature ist.
Vbxler
-------------------------

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: SHL in QWord

Beitrag von mschnell »

indianer-frank hat geschrieben:Das ist wohl richtig, allerdings ist es nicht immer ganz einsichtig was, wann, wo gemacht wird. ZB wird

Code: Alles auswählen

aFileVersion[1] shl 20
'richtig' berechnet, obwohl 'eigentlich' 0 rauskommen müßte.
Es wird nur garantiert, dass das Ergebnis richtig (also wie mathematisch erwartbar) ist, wenn die besagte Typ-Regel beachtet wird.
Dass etwas falsch (also anders als mathematisch erwartbar) ist, wird nicht garantiert.

Vermutlich wird auf 64-Bit Systemen oft mit 64 Bit Integer gerechnet, auch wenn das entsprechend der Regel nicht notwendig ist. Damit ist das Ergebnis möglicherweise anders (also "richtiger") als bei 32 Bit Systemen.

Bei Gleitpunkt kann man sich grundsätzlich auf Exaktheit nicht verlassen. Dafür ist Gleitpunkt - allein schon Hardware-mäßig) nicht gemacht.
indianer-frank hat geschrieben: 1.0/n in single
Single ist "Default", solange der Programmierer dem Compiler nichts anderes angibt. Da sehe ich keinen "Bug".

-Michael

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: SHL in QWord

Beitrag von mschnell »

Vbxler hat geschrieben:Ih finde auch, dass das kein besonders gutes Feature ist.
Wie sollte es sonst sein ? C macht es genauso.

-Michaek

indianer-frank
Beiträge: 134
Registriert: So 30. Nov 2008, 21:53

Re: SHL in QWord

Beitrag von indianer-frank »

mschnell hat geschrieben:Single ist "Default", solange der Programmierer dem Compiler nichts anderes angibt. Da sehe ich keinen "Bug".
Das kann ja wohl nicht ganz stimmen bzw. nicht alles sein, denn sonst müßte ja auch beim 32-Bit-Windows-Compiler so gerechnet werden. Das ist ein Aspekt von dem was ich mit Durcheinander bei Fließkomma meinte.

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: SHL in QWord

Beitrag von mschnell »

indianer-frank hat geschrieben: denn sonst müßte ja auch beim 32-Bit-Windows-Compiler so gerechnet werden.
Nö !

Was genau "Single" ist, hängt von der Architektur ab. Das kann bei einem 64 Bit System völlig anders sein. Es ist nicht zulässig, darüber irgendwelche Annahmen zu machen (außer man liest die Dokumentation für beide Implementierungen)

-Michael

Antworten