"db (-1) shl 1" and "db $ff shl 1"

Index > Compiler Internals > "db (-1) shl 1" and "db $ff shl 1"

Author

Thread

edemko

Joined: 18 Jul 2009
Posts: 549

edemko

Code:

db (-1) shl 1 ; = $ffffffff'fffffffe ; allows
db $FF shl 1  ; = $00000001'fffffffe ; does not allow

19 May 2010, 10:15

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr

edemko,

-1*2 == -2, fits in (signed) byte;
255*2 == 510, doesn't fit in byte.

19 May 2010, 10:27

edemko

Joined: 18 Jul 2009
Posts: 549

edemko

isn't $FF same -1

edit #2
$FF would have to be internally byte_into_qword extended by fasm as DB was used

19 May 2010, 10:32

edemko

Joined: 18 Jul 2009
Posts: 549

edemko

decision: use hex and binary

19 May 2010, 10:39

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr

edemko wrote:

$FF would have to be internally byte_into_qword extended by fasm as DB was used

Numeric expressions are evaluated in the same way regardless of intended usage of their results. Doesn't "byte should be sign-extended into qword because «define byte» is used" sound contradictory? $FF has no signs of sign. Wink

19 May 2010, 11:05

edemko

Joined: 18 Jul 2009
Posts: 549

edemko

thanks
due my logics db -1 would be impossible

19 May 2010, 11:30

Tomasz Grysztar
Assembly Artist

Joined: 16 Jun 2003
Posts: 7718
Location: Kraków, Poland

Tomasz Grysztar

edemko wrote:

isn't $FF same -1

No, $FF is 255, a positive number, it is NOT the same as -1. If you want negative number, you have to use the "-" sign, only then fasm is able understand what you are doing and adjust calculations accordingly (since in assembly you don't distinguish "unsigned" and "signed" data types, assembler needs to take them both into account.

19 May 2010, 11:41

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system

revolution

But also note that this assembles okay:

Code:

db 0xffffffffffffffff

since internally fasm stores -1 as 0xffffffffffffffff, thus it cannot distinguish between the two inputs.

20 May 2010, 09:41

Tomasz Grysztar
Assembly Artist

Joined: 16 Jun 2003
Posts: 7718
Location: Kraków, Poland

Tomasz Grysztar

revolution wrote:

But also note that this assembles okay:
Code:
db 0xffffffffffffffff    
since internally fasm stores -1 as 0xffffffffffffffff, thus it cannot distinguish between the two inputs.

Yes, this on the other hand is a kind of "bug", that comes from the limitations of fasm's architecture. Something that is planned to be better in fasm 2.

20 May 2010, 09:52

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr

Tomasz Grysztar,

It's not a bug as I see it. Argument for db is an expression, if it evaluates to something (signed 64-bit) that fits in byte (value>>7 is -1, 0 or 1) then it's OK to accept it.

20 May 2010, 10:29

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system

revolution

baldr wrote:

It's not a bug as I see it. Argument for db is an expression, if it evaluates to something (signed 64-bit) that fits in byte (value>>7 is -1, 0 or 1) then it's OK to accept it.

It depends upon one's interpretation of "bug". This:

Code:

db 1 shl 999

Gives no error.

20 May 2010, 10:48

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr

revolution,

Do you think it should? May I ask why, then?

20 May 2010, 11:07

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system

revolution

baldr wrote:

Do you think it should? May I ask why, then?

Overflow.

How can 2^999 be stored in one byte?

20 May 2010, 11:18

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr

revolution,

Exactly. For now, we're stuck with [-2**63, 2**63-1] range, thus 1 shl 999 equals to 0 and everything is fine. Wink

Without rules to define certain expression as being of certain type (s/ubyte and such), there is no chance to detect overflow condition. It's common issue for HLLs, they regularly define rules to attribute and coerce values.

20 May 2010, 12:22

Tomasz Grysztar
Assembly Artist

Joined: 16 Jun 2003
Posts: 7718
Location: Kraków, Poland

Tomasz Grysztar

Actually, fasm can easily detect such overflow condition. It ignores it just for convenience.

20 May 2010, 12:24

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system

revolution

baldr wrote:

Exactly. For now, we're stuck with [-2**63, 2**63-1] range, thus 1 shl 999 equals to 0 and everything is fine.

Without rules to define certain expression as being of certain type (s/ubyte and such), there is no chance to detect overflow condition. It's common issue for HLLs, they regularly define rules to attribute and coerce values.

Indeed. Like I said, it depends upon one's interpretation of "bug". If you are happy to say that 2^999==0 then fine, it is not a bug under that definition.

20 May 2010, 12:26

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr

revolution wrote:

If you are happy to say that 2^999==0 then fine, it is not a bug under that definition.

I'm not "happy", just "understanding the limitations". While (1 shl X) shr X seems to be equal to 1 for any X, in real world it's not.

20 May 2010, 19:19

edemko

Joined: 18 Jul 2009
Posts: 549

edemko

continuing numbers dispute: dt $20HexDigitsMayBeCool

Code:

macro tf name*, exponent*, significand*{
  label name tbyte at $
  dq significand
  dw exponent
}

tf f1,$3fff-0000,$8000000000000000 ;2^0*1
tf f2,$3fff-0064,$8000000000000000 ;2^-64*1

entry $

fld     tbyte[f2]
fld     tbyte[f1]
fadd    st0,st1   ;st0+st1=st0, here is why it sAcks!

%LAST_REMAINDER as a global variable, could it be good? More over with read/write access.

24 May 2010, 11:33

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum