cant figure out #DATA....#END use

[ESPsupport]

I'm a bit confused here, the only error I see is when you put a ram address into a constant and then 'back' into a data statement. I don't know of any compiler that could handle such a thing.

When you used the "word dta ..... (varC+1)" format you got the right address didn't you?

[Miroslav Kovar]

Please try to compile this example and you can see that address of (varC+1) is evaluated as two times more than varC only.
There is an easy comparison between produced lines (first is correct, second is wrong and third say why).
Or you can look into .aux file: [DATA] 0007: 01 01 03 01 05 02 02 01 05 02
After a few hours I found a workaround for correctly evaluated address as "word dta (varC/2+1 + idx)", where idx is an array index from 0 to ...
(Do you understand why assembly listing of a compiled program is important to me for debugging?)

Haven't you use constant address evaluation and address arrays in you programs? It can give you very easy grouping of a lot of variables (their addresses) into corresponding blocks. This lets you to make universal subroutines for data manipulation, visualisation and user interaction.

And so every standard compiler accepts to create arrays of variable's addresses. Standard construction to get address of anything is &myvar or addr(myvar) or @myvar. And any part of a variable can be addressed, like addr(myvar[2].xyz[3]). And address evaluation is accepted too, like (&myvar)+2. The only one requirement is that final evaluation must be a constant (when you create constant array) ...

The only 4DGL compiler didn't accept additional parenthesis and standard Address Modifier & ... Why?

Regards
Miroslav

[ESPsupport]

Sorry, I did try it, but now I see I tried the sample you sent which has your fix in it.

The compiler has to manage the different addressing schemes between RAM and Flash (#DATA).

This can become impossible for the compiler if you use other than a simple variable it assumes byte addressability, as it can't work out what it should be doing. Which is why it is correct for varC, but not varC+1.

This issue is usually only seen in #DATA statements.

Not sure why a detailed compiler listing would be easier to understand than a simple print, it certainly wouldn't be quicker.

Also, the compiler has been around for 10 years now and you are the first to mention this, not saying it isn't an issue, perhaps it is showing a unique coding style that was never considered.

[Miroslav Kovar]

The same problem is not only in #DATA block, but in #constant too (see a31).
Why is there in #constant and #DATA blocks other evaluation than in program code?
The clear solution will be to use standard & operator for addreses like "#constant a31 &(varC[1])".
(And it would be safer everywhere so that there can be no confusion between the address and the value of the constant, variable, indexed variable, function, which the compiler itself does not evaluate and does not warn the user ...)

Yes, I understand, this is only a problem of the first pass of compilation and is related to the evaluation of constants in subsequent passes, because it is not the same universal processing procedure ...
And we are at the same point again that not everything is treated the same, which again brings possible complications and potential errors...

Miroslav

PS: The fact that no one has not yet pointed out this does not mean that no one has encountered the same problem. Anyone who has any experience with a "support team" knows very well that it is often faster as a result to cough up the solution or find a solution yourself and not hesitate to explain the problem and create generic examples for support. In the same way, we practiced it for several years before the cup of patience overflowed, and I came across bugs that simply could not be avoided (PWM updates without double buffering). And unfortunately I find out that we will come across similar ones all the time ...

[ESPsupport]

We have noted this for resolving in the compiler.