[fpc-devel] Forwarded message about FPC status

[Sven Barth]

On 25.12.2012 19:30, Dimitri Smits wrote:
>
>
> ----- Oorspronkelijk e-mail -----
>> Van: "Florian Klaempfl" <florian at freepascal.org>
>> Aan: "FPC developers' list" <fpc-devel at lists.freepascal.org>
>> Verzonden: Dinsdag 25 december 2012 14:15:24
>> Onderwerp: Re: [fpc-devel] Forwarded message about FPC status
>>
>>
>> I see no way to speed up the 2.x FPC significantly only by stripping
>> something down or whatever. The whole 2.x design is geared towards
>> portability and maintainability, speed is only 2nd level goal (and
>> being
>> honest, self compilation in ~10 sec even on my >5 year old Core 2 Duo
>> is
>> not that bad ;)).
>
> I'm guessing that is NOT on a Windows platform? Every full build (it has been a while) I've ever done of the compiler on windows was at least a few minutes.
>

That's likely because of the slower process startup time of Windows. 
Also the GNU utilities we use (make, etc.) aren't the fastest on Windows 
either. Also command line output can slow down things dramatically 
(cmd.exe or the PowerShell aren't that fast).

> what I *think* is a large hog on compilation/linking is the spawning of multiple executables in the different steps as opposed to the monolithic exe(+dll) that dcc32.exe is.

If you use the internal assembler and linker on Windows you get the same.

>> The only approach I see to speed it up is to kick the whole back end
>> and
>> generate directly some close to i386 intermediate code directly in
>> the
>> parser.
>
> lovely, but isn't that what Embarcadero is doing for their future compiler? Using the llvm toolchain, they will provide a front compiler to an intermediate "language" or interpreted code. Then they have a few optimisations for the middle layer and use the back-ends that are already available to make stuff architecturally compile to whatever back-end (ARM v?, intel x86, powerpc, motorola 68k, jvm, dalvik, .net il, compiled php, ... or any community or custom backend)

But it is very likely that they won't gain a speed advantage by that. 
They need to decouple their frontend from their backend and here it is 
very likely that they get a performance penalty if they need to go 
through some indirections or callbacks to get the necessary information 
from frontend to backend (or they need to stuff all information 
potentially needed by the backend into the backend). Basically the same 
that FPC does...

Also LLVM does not support that many backends. Currently the most 
important ones are x86(_64), ARM and PowerPC. What LLVM definitely does 
not support is m68k...

Regards,
Sven