Oxygen Basic
Information => Development => Topic started by: Brian Alvarez on June 02, 2019, 04:24:49 PM
-
This compiles and runs fine:
BYTE grr
grr = 325
As expected, this overflows to 69.
However, this fails:
BYTE grr
grr = (325)
It complains about this:
ERR: mov al,325!! Value out of range 325
LINE: 366
FILE: "main source
I would expect the byte to overflow to 69... why not?
-
I wonder If this would fail?
grr = (325+0)
() means expression included to me. Looks like an expressionless constant .
-
Yes, it fails. Which doesnt make much sense...
-
Looks like you discovered a core BASIC missing feature. 8)
-
Is this a bug?
Nah... more likely an inconsistency. Lets see what Charles says. :)
-
I figured it out.
Solution (https://t.co/AbZpKQfZZx)
-
I can fix this problem by setting the minimum accumulator width to 32 bits instead of relying on the bit-width of the destination.
Thanks for pointing it out!
Note:
The error will still be generated if you try this in assembler:
mov al,325
-
Gentlemen,
Silent overflows have been the source of countless headaches in the industry for decades. I think they should be intercepted and error-flagged wherever possible.
-
Hi Mike,
I think most unintended overflows are likely to be dynamic, and have to be trapped explicitly.
Beware the bank account when your savings exceed 2 billion..
-
I think most unintended overflows are likely to be dynamic, and have to be trapped explicitly.
Exactly.
Added:
But i also agree with Mike. Maybe i could add ACCOUNTING modules. Which would raise exceptions with dynamic overflows. Or even better....
allow TRY / CATCH to trap any dynamic overflows.
-
I can fix this problem by setting the minimum accumulator width to 32 bits instead of relying on the bit-width of the destination.
Unfortunately, my fix interferes with byte operations in o2 self-compilation so I won't be able to apply it.
But we could have types with built-in limit checks. This can be implemented with the new operator overloading system. It's worth pursuing.
-
Will it do the same?
-
Brian,
I'll keep the core behaviour as it is. The programmer can use a bit-mask if appropriate. (For instance working with unresolved equates)
byte a=0xff and 325
My other comment is just an idea. I understand ADA supports types with limits, and also specified values.
-
I fixed it, and it now gives correct results.
byte b
b += 325
b = 325
incr b by 325
b = 255
b++
b = 255
incr b