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

[Jonas Maebe]

R. Diez wrote:

> The only thing I found when searching for "FreePascal disadvantages" was
> a general dislike of the Pascal language, which may be justified if
> there are many more gotchas like this:
>
> "for loop variable value reliable after loop?"
> http://lists.freepascal.org/pipermail/fpc-pascal/2015-October/045446.html

I'm not sure what you mean by "more gotchas like this":
* language behaviour that is not in the documentation (i.e., 
documentation bugs)
* 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 
the page numbered as 104, which is at page 116 of the PDF document).
* something else?

In the first two cases, the answer is definitely "yes".

> C's 'volatile' semantics are not perfect, but you need something along
> that line when writing multi-threaded programs, or when writing embedded
> software. If you take a look at the software libraries for STM or Atmel
> microcontrollers, you will see tons of 'volatile' (or ARM CMSIS' synonym
> '__IO') around. All of the peripheral registers are defined like that,
> and there are many of them in a modern microcontroller.

The reason the need for volatile on embedded systems is far less in FPC, 
is the existence of the "absolute" keyword. In C, you have to declare 
all of those memory mapped registers as volatile pointers, because 
otherwise things will get optimised wrongly. In FPC, you can declare 
them as variables that are "absolute" at some address, and the compiler 
will never optimise their accesses. 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.

> The lack of 'volatile' probably means constant paranoia and never-ending
> work-arounds when porting multithreading code to FreePascal,

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.

> or when
> writing embedded software with it. From what I have seen, it also means
> that the compiler will never be able to optimise across units,
> preventing the kind of global optimisation that GCC's LTO does. If you
> haven't got the time to make sure that everything a loop needs is inside
> the same unit, LTO can make a huge difference. Or did I get the wrong
> impression from FreePascal in this area?

I think there will indeed be some issues related to volatile-like 
behaviour, moreover since calls to external routines effectively act as 
compiler-level memory barriers right now (e.g. a call to give up a time 
slice in a spinlocking loop -- although in that case there probably 
won't be any problems, since such a routine would be a black box even to 
GCC/LLVM).

> Maintaining your own independent compiler is hard, and I would have
> expected that FreePascal had turned to GCC or LLVM a long time ago.

It's not so hard if you have a modular compiler design implemented in a 
language you're very familiar with (like Object Pascal :). Keeping up 
with the insane rate of change in LLVM, and/or being forced to write 
everything in C or C++, would be much harder.

> There is some effort in the LLVM front, but without 'volatile' in the
> main compiler, LLVM is probably not going to fix this issue, at least in
> the short or medium term. I had a quick look, and there does not seem to
> be any documentation about the reason why the LLVM port was started.

It was started for the same reason that pretty much everything else in 
FPC was started: because it seemed interesting to someone who was 
willing to invest time in it. In this case, that was me, because I think 
it's interesting to see what its optimisers can do with our code.

> Therefore, before I delve any deeper: are there any other serious
> drawbacks that I should know about before I invest more time looking at
> FreePascal?

 From the top of my head:
* there is no official language standard we follow, there is only the 
Delphi "de facto" standard (which often has to be reverse-engineered 
through writing tests, and it's seldom completely documented) and 
occasionally our own extensions. For non-ISO modes, the official Pascal 
standards serve as broad guidelines, or to define a particular behaviour 
if we don't have a personal preference either.
* we are not backed by any big industry players (although that's also an 
advantage)
* we don't follow any hypes, nor do we launch any ourselves (may be a 
pro or a con, depending on the hype and your opinion about it)
* the compiler and RTL mainly get improved in the areas for which people 
write (good quality) patches. I.e., there is no grand strategy, other 
than the very general and subjective "build a good and usable Pascal 
compiler that supports multiple dialects and architectures"
* there are still a number of compiler switches left from the early days 
when pretty much everyone's personal "hey, this may be interesting one 
day and it seems to work for this one liner or this one platform, so it 
should be fine"-hack got committed, and which hence may not work very 
well or at all. In other cases it's simply functionality that bit rotted 
over time. These get gradually cleaned up, but there are probably still 
some left
* similarly to the above, there are some areas of the compiler that are 
less well-tested than others because fewer people exercise them, and 
hence you may be more likely to encounter bugs in them (for example the 
Intel-style external assembler writers)


Jonas