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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
