Math with constans

[Janne]

Today i noticed that PE does the calculation between constants during runtime, instead of consolidating them into one token. For example, it's useful when setting lcd locations:

SYMBOL FIRSTLINE		= $80	'LCD LINE ADRESSES
SYMBOL SECONDLINE		= $C0
.
.
' to move cursor to position 12 on second lcd line
CHAR =  SECONDLINE + 12 'end up wasting extra program space, but is more readable
CHAR = 204 'works, but makes no sense compared to the previous line

Any chance of mayby fixing this feature in the future? Not a big issue, but I see really no point in doing the constants math during runtime.

 

[hippy]

It's a complicated debate as to when and how to apply 'constant folding' within expressions as the technique is known. Some issues are philosophical, some technical, some practical.

The PICAXE primarily generates code for exactly what is written and any hidden optimisation changes that, sometimes for the better but sometimes confusingly, for example, with constant folding -

w0 = 512
b0 = 512

The two look identical ( and currently generate the same code sizes ) but could generate very different code sizes with folding as the optimised code could be generated equivalent to -

w0 = 512
b0 = 0

There are more esoteric examples where one can potentially end up with code sizes getting smaller or bigger when the opposite may normally be expected to occur.

PICAXE current leaves it to the user to optimise, to decide whether to do the maths at runtime or compile time. Though "CHAR = 204" may make no sense, or rather is unclear in intent, one can use ...

Symbol SECONDLINE_PLUS_12 = SECONDLINE + 12

CHAR = SECONDLINE_PLUS_12

to regain that clarity.