[fpc-devel] Coco/R usage for FPC
Marco van de Voort
marcov at stack.nl
Tue Jan 26 11:34:25 CET 2010
In our previous episode, Graeme Geldenhuys said:
> > (remember, I did the initial development of FPC on a 386-40 with 4 MB
> Wow, that must be long ago.
> > memory on DOS), debugging a yacc generated parser being table driven is
> > a pain etc.
> Not that I understand anything of this or compiler internals, I have
> read that yacc is table driven, and such tools are normally better at
> error reporting. Coco/R uses recursive descent <something or other>
> which is apparently better at performance and speed output.
(hmm, I thought RD was better at errorgeneration, at least with the same
amount of effort invested)
I discussed about this subject with a professional compilerbuilder (in
embedded circles). They used a commercial compiler construction tool, and I
asked why, and what the tradeoffs had been.
His answer was that they mostly retargeted compilers to a new embedded
target, with some target specific extensions (like register access etc), and
could reduce the impact of these changes due to formal validation methods of
the grammar. (and other grammar analysis tools), making them deliver more on
Keep in mind that in order for this to be useful, the tool must be more or
less stay validated, and thus can't be constantly modified (because then the
validation becomes uncertain too), so you have to live with certain
limitations. (which they usually worked around in code for the rather
Now look at FPC, and see how much new syntax arrives with a major version
(in trunk: d2006 extensions like for..in, classvars, fpc new syntax like
case of string, little modifiers are often added, generics etc, delphi
compat fixes). And then I'm not even talking about complete new modes like
objective Pascal, Delphi, Macpascal, TP obj syntax etc was added. (was tp
obj syntax in from the beginning? FPK?)
I think the main reason why gcc stayed so long with flex/yacc is more that
it is Unix tradition.
More information about the fpc-devel