Curious things with brackets...

[Brian Alvarez]

This compiles and runs fine:

Code: [Select]

   BYTE grr
   grr = 325
As expected, this overflows to 69.

However, this fails:

Code: [Select]

   BYTE grr
   grr = (325)
It complains about this:

Code: [Select]

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?

[JRS]

I wonder If this would fail?

grr = (325+0)

() means expression included to me. Looks like an expressionless constant .

[Brian Alvarez]

Yes, it fails. Which doesnt make much sense...

[JRS]

Looks like you discovered a core BASIC missing feature. 

[Brian Alvarez]

Is this a bug?

 Nah... more likely an inconsistency. Lets see what Charles says.

[JRS]

I figured it out.

Solution

[Charles Pegge]

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

[Mike Lobanovsky]

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.

[Charles Pegge]

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..

[Brian Alvarez]

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.

[Charles Pegge]

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.

[Brian Alvarez]

Will it do the same?

[Charles Pegge]

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.

[Brian Alvarez]

 I fixed it, and it now gives correct results.

Code: [Select]

byte b

b += 325
b = 325
incr b by 325
b = 255
b++
b = 255
incr b