round() and trunc()

BradC

While trying to figure out why bstc generated code different to the Propeller Tool when using complex compile time float expressions, I noticed that round() and trunc() are handled inconsistently by the Parallax compiler :

Con
  A = 1.234
  B = 2.345
PUB Fred | X
  X := Trunc(A+b)/Trunc(A-B) <-- is valid
  X := X + Trunc(A+B) <-- is valid
  X := Trunc(A+B) + X <-- is not

The oddity here is if the expression begins with trunc() or round() the Parallax compiler treats the entire expression as a constant and reduces it in the compiler. If not then the expression is parsed and compiled normally.

I can't find this behaviour documented in the manual and it appears inconsistent and broken. Can someone else verify this behaviour?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.

whicker

as soon as you throw in the + for something that isn't a constant, like that local var X, it's telling it to treat both sides as LONGs and add them together. That it has a floating-point bit pattern is irrelevant, it's just blindly going to add them as if they were integers.

it is my understanding that people shouldn't be using the + or any other math operator on floating point numbers, unless it is all constants or literals, so the compiler can pre-calculate it.

i mean, it's insightful, but I don't really expect it to work.

BradC

Further investigation :

Trunc() and Round() turn the remainder of the expression into a constant expression.

If you have something like
X := Y + Z / Trunc(A+B) + 2 + U

It will fail on the "U" as anything after the Trunc() must be a constant.

On the flip side, the compiler calculates the Trunc() and any expressions after it into a single constant value completely ignoring the overall precedence rules.

That above expression is passed to the interpreter as Y + Z / (Trunc(A+B) + 2 + U) (or it would be if it compiled. Substitute the U for a constant to see it),
whereas it *should* parse as Y + (Z / Trunc(A+B)) + 2 + U if it followed the precedence rules.

Parallax, is this a bug in the compiler?

This is the output from the Propeller Tool.

X := 1 + 2 / Trunc(3.0) + 4 / 5
0:1 : 0018 :             36  : Constant 2 $00000001
0:1 : 0019 :          37 00  : Constant Mask Y=0 00000002
0:1 : 001B :          37 21  : Constant Mask Y=33 Decrement 00000003
0:1 : 001D :             F6  : Math Op /
0:1 : 001E :             EC  : Math Op +
0:1 : 001F :             65  : Variable Operation Local Offset - 1 Write

X := 1 + 2 / 3 + 4 / 5
0:1 : 0020 :             36  : Constant 2 $00000001
0:1 : 0021 :          37 00  : Constant Mask Y=0 00000002
0:1 : 0023 :          37 21  : Constant Mask Y=33 Decrement 00000003
0:1 : 0025 :             F6  : Math Op /
0:1 : 0026 :             EC  : Math Op +
0:1 : 0027 :          37 01  : Constant Mask Y=1 00000004
0:1 : 0029 :          38 05  : Constant 1 Bytes - 05 
0:1 : 002B :             F6  : Math Op /
0:1 : 002C :             EC  : Math Op +
0:1 : 002D :             65  : Variable Operation Local Offset - 1 Write

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.

BradC

whicker said...

it is my understanding that people shouldn't be using the + or any other math operator on floating point numbers

Trunc() and Round() both generate integers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.