[fpc-devel] Present and Future of Free Pascal Compiler .

Florian Klaempfl florian at freepascal.org
Wed Jul 30 14:15:58 CEST 2008


Mehmet Erol Sanliturk schrieb:
>           For that reason , I consider such a problem is in the domain of
>           operating systems .
> 
>           FPC is able to generate such programs . Therefore in my opinion
>           it is not a vital problem to solve this problem "WITHIN" the FPC.

This is only possible if the tasks are independent. If they are strongly 
  interdependent, this no option. Just consider the compiler itself: a 
lot could be done in parallel: different procedures could be compiled at 
once, assembling could be done in the background etc. However, this is 
not done because it's far too complicated and unmaintainable with the 
current available tools. For example, we need ways to detect things like 
possible race conditions or deadlocks automatically or e.g. attributes 
like multireadsinglewrite for variables: a runtime check like range 
checking should complain if more than one thread writes such a variable. 
I like also something like the asyncronous keyword:

The programmer writes
procedure p;asynchronous;
A call to such a procedure immediatly returns and the procedure is 
executed in a seperate thread taken from a thread pool if compiled for 
an smp system.

This could be used e.g. for freemem or in the compiler for the assembler 
function (simplified):

var
   assemblercalls : longint;

procedure Assemble(AModule : TModule);asynchronous;
   begin
     { do assembling }
     ...
     InterlockedDecrement(assemblercalls);
   end;

main code:

assemblercalls:=0;
while ModulesLeftToCompile do
   begin
     Compile(current_module);
     InterlockedIncrement(assemblercalls);
     Assemble(current_module);
   end;
{ wait the finishing of assembling }
while assemblercalls>0 do
   Sleep(0);

Nobody has to bother about the number of cores or thread starting or 
whatever. The compiler and the rtl can take care in a efficient way of 
pushing the asynchronous call into a queue handled by a thread pool.


> 
> (B)
> 
>     Generation of parallel processable code within a program part
>     in general is the responsibility of code generator of the compiler .
>     Therefore over time code generator of FPC may be improved for
>     some operating systems which can execute the code in parallel .
>     At this moment insertion of some language syntax extensions can only
>     ruin transportability of the FP programs to other Pascal compilers .

In the other thread people said we should ruin compatibility for 
advanced futures.

>    I can say that use of multi-cores is the responsibility of the 
> OPERATING systems
>    but not of the user programs .

Unlikely. While for example compiling FPC with itself, only one of my 
CPU cores is busy. The OS can do nothing about this.



More information about the fpc-devel mailing list