Pascal code instrumentation as a compilation part?

[FPK]

Can you perhaps try to give some idea about what it is you want to do more specifically? Maybe with an example with how that would be done with Clang or GHC?

I don't think it would be that easy, since the problem lies in the architecture. Both Clang and GHC (and GCC since 4.something) has pluggable architecture that inserts several callbacks in the compilation stages. People may write plugins for any of those callbacks to alter the intermediate result (or simply reading it and doing something with it), without recompiling the compiler.

This is the point: recompiling FPC takes a few seconds. So plugins have no real advantage with FPC.

[Leledumbo]

This is the point: recompiling FPC takes a few seconds. So plugins have no real advantage with FPC.

Not really, Florian. Unless we have the same machine as yours. I still need around 5 minutes on my i3/i5 machine. The plugins have real advantage in turning the compiler into something else (other than compiling of course), making use of the AST without the need to understand the other part of the compiler.

[Laksen]

Recompiling the compiler itself only takes a few seconds (9 seconds on mine). You wouldn't be able to instrument the RTL and packages code at random times anyway even with plugins. They would need to be recompiled from source. That's the same situation as with Clang and GCC.

[Leledumbo]

Recompiling the compiler itself only takes a few seconds (9 seconds on mine). You wouldn't be able to instrument the RTL and packages code at random times anyway even with plugins. They would need to be recompiled from source. That's the same situation as with Clang and GCC.

Ah, yes. The compiler only (and without full 3-step bootstrapping + 2-step wpo) takes only seconds.

[Rel]

This is the point: recompiling FPC takes a few seconds. So plugins have no real advantage with FPC.

That is a strange point. Plugins should be a well defined and documented interface. Compiler's code is neither documented, nor defined (compiler internals can be changed in anyway). I can take compiler's code and modify it, but when the newer version come out introducing some breaking changes, then what should I do? Should I repeat all the work that I've done all over again for each new version or each new commit?

[marcov]

Not really, Florian. Unless we have the same machine as yours. I still need around 5 minutes on my i3/i5 machine.

A *nix + SSD + carefully selected options can get you under 2 minutes or even in the vincinity of 1 minute.  On my Windows i7 laptop with 5400rpm harddisk I can do 2-3 minutes, but only when it is hot (the second time)

The plugins have real advantage in turning the compiler into something else (other than compiling of course), making use of the AST without the need to understand the other part of the compiler.

IMHO plugins just slow down for the bulk to give a few people the feeling that they have all the power on their fingertips.   I'm against standarized preprocessing (external, or worse internal), since it only makes such hacks more common, and pseudo legitimate.

People with a *real* need will simply do a bit of extra work.  Afaik prologue and epilogue can already be simply hooked by providing your own gcrt and compiling with profiling support.

[marcov]

This is the point: recompiling FPC takes a few seconds. So plugins have no real advantage with FPC.

That is a strange point. Plugins should be a well defined and documented interface.

Yes, but they rarely have. Most of it is just an excuse for the project team to not do stuff. Just add a
pluginsystem, and say if they want it they can do it themselves.

Compiler's code is neither documented, nor defined (compiler internals can be changed in anyway). I can take compiler's code and modify it, but when the newer version come out introducing some breaking changes, then what should I do? Should I repeat all the work that I've done all over again for each new version or each new commit?

That depends on the features. Many parts are fairly static.  If it is too troublesome, just run it over the whole tree. I know various schools  used patched runtime sources to benchmark their students projects.

[FPK]

This is the point: recompiling FPC takes a few seconds. So plugins have no real advantage with FPC.

Not really, Florian. Unless we have the same machine as yours. I still need around 5 minutes on my i3/i5 machine.

See Marco's comment. I'am talking about the compiler only.

The plugins have real advantage in turning the compiler into something else (other than compiling of course), making use of the AST without the need to understand the other part of the compiler.

Why would you need to understand the other parts of the compiler if you use only the node tree (FPC never generates a real AST)?

Just an example from another part: Nico aka _masta_ implemented a lot of arm assembler peephole optimizations without knowing much about the rest of the compiler.

This is the point: recompiling FPC takes a few seconds. So plugins have no real advantage with FPC.

That is a strange point. Plugins should be a well defined and documented interface.

And you think this would be the case of a plugin interface? It is very likely that it changes with every version as well because the compiler supports new features.

Compiler's code is neither documented, nor defined (compiler internals can be changed in anyway). I can take compiler's code and modify it, but when the newer version come out introducing some breaking changes, then what should I do? Should I repeat all the work that I've done all over again for each new version or each new commit?

The same applies for plugins. Nobody would gurantee that a plugin interface does not change if the plugin interface has at least a certain complexity to be usefull.