Recent

Author Topic: FPC is not good designed: humble opinion  (Read 8187 times)

AlexTP

  • Hero Member
  • *****
  • Posts: 2384
    • UVviewsoft
FPC is not good designed: humble opinion
« on: May 14, 2018, 07:45:06 am »
I was talking with a mate about FPC. He told me that FPC is not good designed, what he means:
good designed compiler must be of two parts:

part 1- it translates Pascal syntax to some internal format (internal: better suited to convert to binary)
part 2- it translates internal format to any machine code, with any arch: x32, x64, arm...

Part 1 allows to improve pascal syntax, to add more syntaxes...
Part 2 allows to separate binary creation from pascal syntax. and to add more archs.

Is it right?
« Last Edit: May 14, 2018, 07:48:12 am by Alextp »

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: FPC is not good designed: humble opinion
« Reply #1 on: May 14, 2018, 09:19:32 am »
Your mate might think about past times of FPC (pre 2.0). Since then FPC already has that separation between frontend and backend with the internal format being a node tree that allows for easy conversion to the machine code. How do you think we'd be able to support as many platforms as we do otherwise?  ;)

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: FPC is not good designed: humble opinion
« Reply #2 on: May 14, 2018, 09:22:55 am »
Well actually that is exactly how FreePascal is designed, so he is talking rubbish.
sourcecode --> parsetree --> high level code generator (abstraction) --> low level code (specialization) to CPU. (even to NOCPU!)
The reason FPC can support so many platforms is because of the HLCG which makes it comparatively easy to add a new platform. (still 11 on a scale of 1..10, but..)
Specialize a type, not a var.

guest58172

  • Guest
Re: FPC is not good designed: humble opinion
« Reply #3 on: May 14, 2018, 09:41:23 am »
IMO there should be several semantic phase so that forward declarations work automatically, without the need to declare that the stuff is a class. More generally a language that doesn't accept out of order declarations has certainly certain limits in semantic processing.

Quote
part 1- it translates Pascal syntax to some internal format (internal: better suited to convert to binary)
part 2- it translates internal format to any machine code, with any arch: x32, x64, arm...

Compiling a PL is generally more decomposed in 4 phases

1/ transform into tokens (lex / scan)
2/ transform tokens into grammatical constructs (parse, make the AST)
3/ semantic, i.e meaning of the program
4/ intermediate representation (e.g SSA, LLVM IR)
5/ IR to CG (produce byte code)

1-2-3-4 is the "frontend"
5 is the "backend"

I think that in Pascal the phase 3 is too limited. There should be several passes for example to solve the types like forward / out of order declarations. This would also allow cycles in uses (major limit in current design), as long as there's no initialization in mutually dependent units.

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: FPC is not good designed: humble opinion
« Reply #4 on: May 14, 2018, 10:00:04 am »
That is basically a property of Pascal compilers in general and not FPC specific. It is also the reason for the compile speed compared to other languages which I would not give up for badly formed architectural dependencies that you seem to accept as an actual feature. Pascal compilers are essentially single pass compilers (on a conceptual level, fpc digresses a little in practice and has e.g. back propagation and other things like the virtual register allocator). Where multi-pass comes into its own right is in optimizations and that is already possible with WPO, which in itself relies on the HLCG part of the compiler. Pascal syntax is essentially a LL(1) grammar.

Your suggestion would inevitably lead to a major loss in compile speed.
« Last Edit: May 14, 2018, 10:10:09 am by Thaddy »
Specialize a type, not a var.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC is not good designed: humble opinion
« Reply #5 on: May 14, 2018, 10:15:08 am »
I was talking with a mate about FPC. He told me that FPC is not good designed, what he means:
good designed compiler must be of two parts:

part 1- it translates Pascal syntax to some internal format (internal: better suited to convert to binary)

It does, a parse tree. If your mate can't recognize that in the compiler, I somehow doubt his credentials :-)

Quote
part 2- it translates internal format to any machine code, with any arch: x32, x64, arm...

It a cg for each arch that does this.

Quote
Part 2 allows to separate binary creation from pascal syntax. and to add more archs.

Is it right?

It doesn't work that way. Changes to the frontend often necessitate changes to the backend too. Think of things like expanding RTTI that needs tables to be generated etc.

In toy compilers and C compilers (the latter because the syntax expansions are usually limited) it works that way. In production compilers with a nontrivial dialect it doesn't.

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: FPC is not good designed: humble opinion
« Reply #6 on: May 14, 2018, 11:53:59 am »
Yes, toy is a nice language.. :D
https://en.wikipedia.org/wiki/Toy_programming_language
I took the liberty of editing out Pascal and Logo because they are not toy languages as sane computer scientists know..
« Last Edit: May 14, 2018, 12:19:38 pm by Thaddy »
Specialize a type, not a var.

bee

  • Sr. Member
  • ****
  • Posts: 393
Re: FPC is not good designed: humble opinion
« Reply #7 on: May 15, 2018, 04:47:42 am »
FPC is surely pretty well designed. Some friends of mine who do knows about how to build a compiler and how a compiler works, said that FPC is in fact quite good. Because I don't really have enough knowledge to judge FPC as a compiler myself, I believe them.

In my opinion, the problem with FPC is not the compiler, or any technical things about it, which are good indeed. But it's more about the vision of its future, about what it's going to be for the next generation. I hope that FPC will adding more and more modern features, from trivial things like named parameter to advanced things like automatic memory management and asynchronous, built into its syntaxes. The same goes for Lazarus IDE. I wish there will be more and more smart developers join the project and contribute more features to FPC and Lazarus IDE. *finger crossed
-Bee-

A long time pascal lover.

Leledumbo

  • Hero Member
  • *****
  • Posts: 8746
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: FPC is not good designed: humble opinion
« Reply #8 on: May 15, 2018, 07:53:59 am »
I think that in Pascal the phase 3 is too limited. There should be several passes for example to solve the types like forward / out of order declarations. This would also allow cycles in uses (major limit in current design), as long as there's no initialization in mutually dependent units.
Florian won't like it, compilation speed is something he won't sacrifice to support something like that. Much to lose for little to no gain, could be a lose as well (out of order declarations make everything scattered, it hampers readability, so what gain do you get?).

Pascal

  • Hero Member
  • *****
  • Posts: 932
Re: FPC is not good designed: humble opinion
« Reply #9 on: May 15, 2018, 08:33:42 am »
I think that in Pascal the phase 3 is too limited. There should be several passes for example to solve the types like forward / out of order declarations. This would also allow cycles in uses (major limit in current design), as long as there's no initialization in mutually dependent units.
Florian won't like it, compilation speed is something he won't sacrifice to support something like that. Much to lose for little to no gain, could be a lose as well (out of order declarations make everything scattered, it hampers readability, so what gain do you get?).
The benefit is more readability as you can have classes reference each other without having them to be in the same unit!

I think you even can get rid of forward declarations in a unit. If the parser finds a type which is not defined it can handle it as if it has been forward declared.
laz trunk x64 - fpc trunk i386 (cross x64) - Windows 10 Pro x64 (21H2)

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: FPC is not good designed: humble opinion
« Reply #10 on: May 15, 2018, 08:57:21 am »
The benefit is more readability as you can have classes reference each other without having them to be in the same unit!
I think you even can get rid of forward declarations in a unit. If the parser finds a type which is not defined it can handle it as if it has been forward declared.
That won't work in a single pass compiler nor with a LL(1) parser (that's one level up). You can not resolve that unless at the cost of speed. Mind I see the point, but it is a bit naive (without being rude).
At one point the compiler needs to resolve forwards. HOW you do that has impact on compilation speed. There's a big difference in forwards in a interface section, resolved immediately in an implementation section and the syntax you suggest, which isn't resolvable until all units are parsed at least twice. That's basic compiler design. We are not talking about dynamic languages here. We are talking about a language with a high compile speed compared to other compiled languages and yes, that comes at some costs. You should try to build C++ code like we press F9: You will have time to actual grow and harvest the coffee, go on holiday and return for the last few hours of waiting for such a compiler to finish...So you can dry, roast and grind the beans (as I stated: much of my work is done in C++ or C)

And even after that it depends on the brand of compiler: FreePascal's code generation is not optimal but good enough to ignore the difference with - say - a GNU C++ compiler in the sense that it does the job in a near optimal way without having to use multiple passes. Actually: un-optimized GNU C++ generates worse code than un-optimized FreePascal: you can test that yourself. Both speed and memory use. Where the GNU C++ compiler has an edge is in multi-pass, which makes it slow to "unworkable" in real world code bases compared to FPC. Patience is an art that I still do not fully understand..... :D
« Last Edit: May 15, 2018, 09:09:00 am by Thaddy »
Specialize a type, not a var.

Pascal

  • Hero Member
  • *****
  • Posts: 932
Re: FPC is not good designed: humble opinion
« Reply #11 on: May 15, 2018, 09:11:44 am »
The benefit is more readability as you can have classes reference each other without having them to be in the same unit!
I think you even can get rid of forward declarations in a unit. If the parser finds a type which is not defined it can handle it as if it has been forward declared.
That won't work in a single pass compiler nor with a LL(1) parser (that's one level up). You can not resolve that unless at the cost of speed. Mind I see the point, but it is a bit naive (without being rude).
At one point the compiler needs to resolve forwards. HOW you do that has impact on compilation speed. There's a big difference in forwards in a interface section, resolved immediately in an implementation section and the syntax you suggest, which isn't resolvable until all units are parsed at least twice. That's basic compiler design. We are not talking about dynamic languages here. We are talking about a language with a high compile speed compared to other compiled languages and yes, that comes at some costs. You should try to build C++ code like we press F9: You will have time to actual grow and harvest the coffee, go on holiday and return for the last few hours of waiting for such a compiler to finish...So you can dry, roast and grind the beans (as I stated: much of my work is done in C++ or C)
I think this can be done in a single pass compiler. It just has to handle unknown types as forward declared like it is done in a single unit and check at the
end of the interface section if all foward declarations have been resolved. Of couse this takes speed and memory but the gain will be a more readable code
and less hacks/casts to make classes reference each other.

Not beeing able to make classes reference each other from different units and without casting is IMHO the biggest drawback of FPC at the moment.
In nearly every (bigger) project i stumble on this!
laz trunk x64 - fpc trunk i386 (cross x64) - Windows 10 Pro x64 (21H2)

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: FPC is not good designed: humble opinion
« Reply #12 on: May 15, 2018, 09:57:26 am »
You obviously have no clue about compiler engineering. (sorry)
Try reading this funny first: https://blog.acolyer.org/2016/09/08/computer-programming-as-an-art/
Then try some books about compiler engineering. Then try and get a degree.

What you propose is impossible in a single pass compiler. (I know, I have a degree and I am not nearly as good as the core compiler team)
That said my first major was in Political science... I got my computer science degree when I was much older...
« Last Edit: May 15, 2018, 10:10:06 am by Thaddy »
Specialize a type, not a var.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: FPC is not good designed: humble opinion
« Reply #13 on: May 15, 2018, 10:01:08 am »
I think that in Pascal the phase 3 is too limited. There should be several passes for example to solve the types like forward / out of order declarations. This would also allow cycles in uses (major limit in current design), as long as there's no initialization in mutually dependent units.

No, since the multiple passes still would only be within one unit, so it would change nothing inter-unit.

And as usual this thread is again about a vision for the language only.  And the "vision" is nothing but cheap borrowing of features from other languages that just happen to be not implemented because the compiler architecture is not geared to it.  It saves minor editing at best, and potentially introduces cases where one can introduce hard to find problems and complicates error message generation.

It doesn't make anything possible that can't be done now. Contrary to the MI discussion in a different thread. I don't believe in it, but it targets how you model a programming problem and that at least more than just typing/convenience features.

That is not "Vision", that is pathetic copy-catting.

« Last Edit: May 15, 2018, 10:41:20 am by marcov »

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: FPC is not good designed: humble opinion
« Reply #14 on: May 15, 2018, 10:16:53 am »
Marco, it is very hard for some people to understand the difference.
Opinions are valid when based on information, opinions based on absence of information are close to dangerous. Information does not have to be complete for opinion, however.
And some effort towards understanding such things (like studies) are both rewarding and interesting. (Well, at least to me)
Specialize a type, not a var.

 

TinyPortal © 2005-2018