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