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

[Tomas Hajny]

On Fri, December 18, 2015 09:59, Jonas Maebe wrote:
> R. Diez wrote:


Hello,

Please note that the original poster doesn't seem to be subscribed to the
list (in Cc: now).

Tomas


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