[Bug]: Differnt results from equivalent math operations

[NMMT76]

Contact Details

No response

Compiler version

v.1.18.4

What happened?

First off, thank you for ZX Basic, without it I'd never have gotten so far on my "virtual expansion device" work ( Zero-EM )

Now onto the issue. As i was writing/testing some new webcam related functions in Zero-EM i came across a strange behavior, so i dug a bit deeper.

As you can see from the example, two different results for an equivalent operation. My guess is that the - sign at the beginning of the first one forces some sort of type expansion/coercion that doesn't happen on the second.

While its easy to work around it, by only using INTEGER's or "hinting" at the need for type expansion/coercion, its still "unexpected behavior".

DIM adjbri,adjcon,adjgam as UBYTE
adjbri=99
adjcon=99
dim brires,conres as INTEGER

CLS

brires=-100+adjbri
conres=-100+adjcon
Print at 0,0;"Bri:";str(brires);" Con:";str(conres)
brires=adjbri-100
conres=adjcon-100
Print at 1,0;"Bri:";str(brires);" Con:";str(conres)

Kind regards and many thanks for your work

Error and Warning messages

Code of Conduct

• I agree to follow this project's Code of Conduct

[pfisher-godaddy]

I haven't run the code, but I'm guessing -1 falls out as 255.

I think you're right - the issue is that it uses the "smallest" type that fits. In the second case, that's a ubyte as defined, and subtract 100 - another thing that fits into ubyte. So we end up with ubyte-ubyte wraparound.

In the first one, the unary operator on -100 makes a difference: -100 doesn't fit into a ubyte, so we drop into byte, which is -127 to +128. And the calculation fits in this.

I don't think this is a compiler bug, actually. It's the code falling into assumptions about types and going off the edge of permitted values. If you made the variables bytes, or did a cast, it wouldn't happen.

[boriel]

The compiler does not automatically do type promotion when the final result is to be stored in a smaller type (this is a feature to be implemented, but in a Z80 - 8bit tiny CPU will lead to performance and memory overhead :-(). Consider using either a larger type (Integer, UInteger) or a temporary CAST.

Anyway, for the case reported, I'll check it since it must return the same (overflowed) result in both cases, as @NMMT76 said.