flat assembler
Message board for the users of flat assembler.

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

Author
Thread Post new topic Reply to topic
edemko



Joined: 18 Jul 2009
Posts: 549
edemko 19 May 2010, 10:15
Code:
db (-1) shl 1 ; = $ffffffff'fffffffe ; allows
db $FF shl 1  ; = $00000001'fffffffe ; does not allow
    
Post 19 May 2010, 10:15
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 19 May 2010, 10:27
edemko,

-1*2 == -2, fits in (signed) byte;
255*2 == 510, doesn't fit in byte.
Post 19 May 2010, 10:27
View user's profile Send private message Reply with quote
edemko



Joined: 18 Jul 2009
Posts: 549
edemko 19 May 2010, 10:32
isn't $FF same -1

edit #2
$FF would have to be internally byte_into_qword extended by fasm as DB was used
Post 19 May 2010, 10:32
View user's profile Send private message Reply with quote
edemko



Joined: 18 Jul 2009
Posts: 549
edemko 19 May 2010, 10:39
decision: use hex and binary
Post 19 May 2010, 10:39
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 19 May 2010, 11:05
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
Post 19 May 2010, 11:05
View user's profile Send private message Reply with quote
edemko



Joined: 18 Jul 2009
Posts: 549
edemko 19 May 2010, 11:30
thanks
due my logics db -1 would be impossible
Post 19 May 2010, 11:30
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 19 May 2010, 11:41
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.
Post 19 May 2010, 11:41
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20357
Location: In your JS exploiting you and your system
revolution 20 May 2010, 09:41
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.
Post 20 May 2010, 09:41
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 20 May 2010, 09:52
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.
Post 20 May 2010, 09:52
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 20 May 2010, 10:29
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.
Post 20 May 2010, 10:29
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20357
Location: In your JS exploiting you and your system
revolution 20 May 2010, 10:48
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.
Post 20 May 2010, 10:48
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 20 May 2010, 11:07
revolution,

Do you think it should? May I ask why, then?
Post 20 May 2010, 11:07
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20357
Location: In your JS exploiting you and your system
revolution 20 May 2010, 11:18
baldr wrote:
Do you think it should? May I ask why, then?
Overflow.

How can 2^999 be stored in one byte?
Post 20 May 2010, 11:18
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 20 May 2010, 12:22
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.
Post 20 May 2010, 12:22
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 20 May 2010, 12:24
Actually, fasm can easily detect such overflow condition. It ignores it just for convenience.
Post 20 May 2010, 12:24
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20357
Location: In your JS exploiting you and your system
revolution 20 May 2010, 12:26
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. 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.
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.
Post 20 May 2010, 12:26
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr 20 May 2010, 19:19
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.
Post 20 May 2010, 19:19
View user's profile Send private message Reply with quote
edemko



Joined: 18 Jul 2009
Posts: 549
edemko 24 May 2010, 11:33
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.
Post 24 May 2010, 11:33
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.