Smallint: -1 Longint: 2147483647 Int64: 9223372036854775807
Smallint: 32767 Longint: 2147483647 Int64: 9223372036854775807
i think that have something to do with typed constants.If I ran your code I still get -1, even the sequence
D:\Work\Dev>D:\FPC304\bin\i386-win32\fpc.exe shr1.pas
Free Pascal Compiler version 3.0.4 [2017/10/06] for i386
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling shr1.pas
Linking shr1.exe
10 lines compiled, 0.1 sec, 26560 bytes code, 1300 bytes data
D:\Work\Dev>shr1.exe
Smallint: -1 Longint: 2147483647 Int64: 9223372036854775807
D:\Work\Dev>fpc64304 shr1.pas
D:\Work\Dev>D:\FPC304\bin\i386-win32\ppcrossx64.exe shr1.pas
Free Pascal Compiler version 3.0.4 [2017/10/06] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling shr1.pas
Linking shr1.exe
10 lines compiled, 0.1 sec, 31072 bytes code, 1348 bytes data
D:\Work\Dev>shr1.exe
Smallint: -1 Longint: 2147483647 Int64: 9223372036854775807
and attached the FPC.CFG file.D:\FPC304\bin\i386-win32\fpc.exe shr1.pas -O1
Okay, what does this give you?Yes, with -O1 I get 32767 with var vs: smallint = -1. But with my original program using typed constants I still get -1.QuoteD:\FPC304\bin\i386-win32\fpc.exe shr1.pas -O1
(-O1 optimization level is default in Lazarus)
An implicit typecast and extension to a larger unsigned type may be performed before the shift operation.So, it's not always promoted to a larger unsigned type.
But to have SAR and SAL, would be really nice.Are you aware that 2.6.0 introduced the intrinsics:
I found a inconsistent behaviour for the shr operator: The output of the following programRules:Code: [Select]Smallint: -1 Longint: 2147483647 Int64: 9223372036854775807
Since shr is a logical shift right
Rules:If rule 2 were correct, how do you explain
1. shr operation is always a logical shift (unsigned).
2. shr operation is 32 bits for the size of the operands <= 32 bits and 64 bits otherwise.
WriteLn(ShortInt(-1) shr 1); // 9223372036854775807
If rule 2 were correct, how do you explainDid you read my PS: ?QuoteWriteLn(ShortInt(-1) shr 1); // 9223372036854775807
Yes, but then the rules are not very clear. It looks like the same disclaimer applies as withIf rule 2 were correct, how do you explainDid you read my PS: ?QuoteWriteLn(ShortInt(-1) shr 1); // 9223372036854775807
An implicit typecast and extension to a larger unsigned type may be performed before the shift operation.I would like do have definite rules.
when shifting a signed integer the smallest value is -1, so shifting -1 will result in -1.Your understanding is wrong. shr is a logical right shift, that means the lowest bits go to nirvana and zero bits are inserted at the highest positions instead. As shown by
0 and up are positive numbers which is why you can shift all the way to 0.
and if you were to shl 7 with a -1 you would get -128, one more you get 0
...
This is how I understand it...
shrTheoretically the results are clearly defined by the bit-size of the variables and the shift count. The problems in practice come from the promotion of small-bit-sized types to signed longint or int64, to which the logical shift is applied (and constant expressions are handled by the compiler with int64). Your `shifting -1 will result in -1` is seen to be completely wrong by looking at the results for longint and int64.
1111111111111111 ----> 0111111111111111 = 32767