[fpc-pascal] Lack of 'volatile' a serious issue. Any other such caveats?

[R. Diez]

 > The reason the need for volatile on embedded systems is far
 > less in FPC, is the existence of the "absolute" keyword.
 > [...]
 > Only if you would take the address
 > of one of these variables and store it in a pointer,
 > you would need "volatile" in this context.

Thanks for your detailed answer.

The issue with the pointers would definitely impact me, as my 
microcontroller has many GPIOs, and I have written classes like 
"ClassSpi" that take GPIOs as pointers. This way, I can implement 
generic functionality which does not depend on the exact GPIOs being used.

Lukasz Sokol mentioned the approach taken by the Linux community (I 
didn't get his e-mail address). They have a fat kernel with lots of 
synchronisation primitives, which you do not normally have when 
programming for Cortex-Mx microcontrollers.

Issuing a generic memory barrier is workable, but it kills performance, 
as all variables will be reloaded again. Performance does matter when 
working on microcontrollers.

Basically, the Linux approach would then boil down to writing a wrapper 
function for every "special" hardware-related memory access. For the 
simple case of GPIOs, the wrapper function would then take a pointer to 
the GPIO and would access that pointer within a type-cast to 'volatile'. 
So basically you have to wrap everyhing, which is a pain for "simple" 
embedded Firmware, but is doable.

However, FreePascal does not have 'volatile' at all. For such a routine 
that works with generic pointers, and not with fixed "absolute" global 
variables, I guess the only work-around would be to write some inline 
assembly, which would again kill performance, because FreePascal 
probably assumes that inline assembly can modify everything else, so all 
variables will be reloaded afterwards as in the case of a generic memory 
barrier. Is that right?


 > In FPC, every statement is basically considered to be a
 > compiler-level memory barrier for accesses to global
 > variables. So within a single statement multiple accesses
 > can be optimised, but that cannot happen not
 > across statements. It's not perfect since it inhibits
 > some optimisation, but on the flip side it's very simple
 > and easy to reason about.

I see. Based on that information, and on the issue of function calls 
crossing units, I guess you could rephrase that in much less-friendly 
way. I'm playing evil advocate now: "FreePascal is so simple it can only 
optimise properly the kind of hand-written tight loops that you normally 
find in artificial benchmarks."  }8-)


 > "for loop variable value reliable after loop?"
 > http://lists.freepascal.org/pipermail/fpc-pascal/2015-October/045446.html
 > [...]
 > language behaviour that may be unexpected if you are used to
 > e.g. C, but that is considered normal in Pascal
 > (the above behaviour was already
 > defined in the Extended Pascal standard in 1990/1991:
 > http://www.pascal-central.com/docs/iso10206.pdf , Section 6.9.3.9.1 on

I find that kind of answer disappointing. In this particular case, the 
FreePascal developers could  have just provided that guarantee. Is there 
at least a compilation warning if you access the variable after the loop?

If I have to learn a new programming language, I would avoid those with 
esoteric gotchas like that. The "it's in the spec" line is a lame 
excuse. The Java language, for example, is much cleaner and does not 
have such traps for the unwary (in my personal opinion).

At the risk of sounding too cynical, I'd like to say that I have been 
burnt many times. That's why I try to "poke around" a bit before 
investing too much time in the next cool thing. Besides, I hope this 
discussion helps other people. For example, I found the link to the 
Linux volatile discussion interesting.

Regards,
   rdiez