flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
edemko
Code: db (-1) shl 1 ; = $ffffffff'fffffffe ; allows db $FF shl 1 ; = $00000001'fffffffe ; does not allow |
|||
![]() |
|
baldr
edemko,
-1*2 == -2, fits in (signed) byte; 255*2 == 510, doesn't fit in byte. |
|||
![]() |
|
edemko
isn't $FF same -1
edit #2 $FF would have to be internally byte_into_qword extended by fasm as DB was used |
|||
![]() |
|
edemko
decision: use hex and binary
|
|||
![]() |
|
edemko
thanks
due my logics db -1 would be impossible |
|||
![]() |
|
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. |
|||
![]() |
|
revolution
But also note that this assembles okay:
Code: db 0xffffffffffffffff |
|||
![]() |
|
Tomasz Grysztar
revolution wrote: But also note that this assembles okay: |
|||
![]() |
|
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. |
|||
![]() |
|
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. Code: db 1 shl 999 |
|||
![]() |
|
baldr
revolution,
Do you think it should? May I ask why, then? |
|||
![]() |
|
revolution
baldr wrote: Do you think it should? May I ask why, then? How can 2^999 be stored in one byte? |
|||
![]() |
|
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. ![]() 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. |
|||
![]() |
|
Tomasz Grysztar
Actually, fasm can easily detect such overflow condition. It ignores it just for convenience.
|
|||
![]() |
|
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. |
|||
![]() |
|
baldr
revolution wrote: If you are happy to say that 2^999==0 then fine, it is not a bug under that definition. |
|||
![]() |
|
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. |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.