Re: integer overflow in muli instruction

[Jose E. Marchesi]

> Jose E. Marchesi wrote:
>> So I think at this point we are good when it comes to detecting overflow
>> in signed operations.
>
> There is a problem, though: A literal that was printed cannot be parsed
> when viewed as an expression:
>
> (poke) .set obase 10
> (poke) -2*0x4000000000000000
> -9223372036854775808L
> (poke) -9223372036854775808L
> <stdin>:1:1: error: expression overflows
> -9223372036854775808L;
> ^

Oh, I think this is the origin of the problem:

(poke) 9223372036854775808L
-9223372036854775808L

The above should be an error instead: that number is not representable
in Poke.

So, seems like due to a bug in the lexer, you are doing:

- -9223372036854775808L

i.e. negating -9223372036854775808L, which overflows :)

So _overflow_ works fantastically! :P

Looking at the damn lexer...

> What's odd is that this works in base 16:
>
> (poke) .set obase 16
> (poke) -2*0x4000000000000000
> 0x8000000000000000L
> (poke) 0x8000000000000000L
> 0x8000000000000000L
>
> Apparently because in base 16, signed integers are printed as if they were
> unsigned. (Not sure whether this is intentional?)

Yeah it is intentional.