> 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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
