Index
> Compiler Internals > "db (-1) shl 1" and "db $ff shl 1" |
| Author |
|
|
edemko 19 May 2010, 10:15
Code: db (-1) shl 1 ; = $ffffffff'fffffffe ; allows db $FF shl 1 ; = $00000001'fffffffe ; does not allow |
|||
19 May 2010, 10:15 |
|
|
baldr 19 May 2010, 10:27
edemko,
-1*2 == -2, fits in (signed) byte; 255*2 == 510, doesn't fit in byte. |
|||
|
19 May 2010, 10:27 |
|
|
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 |
|||
|
19 May 2010, 10:32 |
|
|
edemko 19 May 2010, 10:39
decision: use hex and binary
|
|||
|
19 May 2010, 10:39 |
|
|
edemko 19 May 2010, 11:30
thanks
due my logics db -1 would be impossible |
|||
|
19 May 2010, 11:30 |
|
|
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. |
|||
|
19 May 2010, 11:41 |
|
|
revolution 20 May 2010, 09:41
But also note that this assembles okay:
Code: db 0xffffffffffffffff |
|||
|
20 May 2010, 09:41 |
|
|
Tomasz Grysztar 20 May 2010, 09:52
revolution wrote: But also note that this assembles okay: |
|||
|
20 May 2010, 09:52 |
|
|
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. |
|||
|
20 May 2010, 10:29 |
|
|
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. Code: db 1 shl 999 |
|||
|
20 May 2010, 10:48 |
|
|
baldr 20 May 2010, 11:07
revolution,
Do you think it should? May I ask why, then? |
|||
|
20 May 2010, 11:07 |
|
|
revolution 20 May 2010, 11:18
baldr wrote: Do you think it should? May I ask why, then? How can 2^999 be stored in one byte? |
|||
|
20 May 2010, 11:18 |
|
|
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. 
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 20 May 2010, 12:24
Actually, fasm can easily detect such overflow condition. It ignores it just for convenience.
|
|||
|
20 May 2010, 12:24 |
|
|
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. |
|||
|
20 May 2010, 12:26 |
|
|
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. |
|||
|
20 May 2010, 19:19 |
|
|
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. |
|||
|
24 May 2010, 11:33 |
|
< Last Thread | Next Thread > |
Forum Rules:
|