Dear Sirs ,

A discussion started on representation of Russian language in FPC ( Free Pascal Compiler ) and continues toward about the general design and future of FPC .

As a Computer ( let's say Scientist and/or Engineer ) I consider every idea exchanging as a good activity .

I want to present the following points for your consideration :

(A)

Multithreading , for me . it is NOT an important contribution to the FPC because , please , think the following model :

Assume that n ( n > 1 ) processes required to be running in parallel .

Solution : Write n simple programs ( let say command-line programs ) able to use DDE ( Dynamic Data Exchange ) or any message passing ability .
In your program , when a button is clicked let the some processes spawn any number of programs as "independently" started programs . They may start new programs , and they may cooperate in any way by message passing .

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.

By using such programs even computations may be distributed over different computers .

(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 .

The other issue is how many programmers will use this facility on which operating systems ?

To extent wish lists is very easy , but when task comes to implement those wishes many things appear uprightly like an iceberg and a hit to it gives very undesired results .

(C)
I am not an operating system expert . My expertise is on scientific computing
( theory and mathematical/statistical analysis ) and Design of Data Base Programming Languages and their implementation .

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

To try to carry this task toward user programs through a compiler can only be
a disaster and waste of whole efforts . I am in this profession ( since 1970 as
student of Computer Science courses ,) since 1974 as a System Analyst , ... .

I saw many products which tried to complement some operating system deficiencies
but they went to cemetery of software business because next release of the
operating system removed those deficiencies and the task remained to the other firm
was to disappear from the market .

It is not necessary to repeat the same history for the FPC .

(D)

When mathematical/statistical computing is considered ( if I say my own intention : I am working toward writing a whole set of such procedures to integrate
into my other programs ( because they are in Pascal ) but very slowly ) Pascal language may be
( , perhaps not the last , but at least)
not considered because its procedure parameter passing , especially when compared
to Fortran object-time DIMENSION facility and many other points . There are some efforts ( for example , Scientific Pascal ) to extend the Pascal language toward a similar structure
with Fortran but up to now there is no a widely accepted product ( or I do not know ).

(E)

When Free Pascal is concerned I may say that it is a very good compiler ,
really I present my heartiest congratulations to its developers ( although it is not compiling my program ) .

(F)

Let's ask :

Are there any points which should be improved ?

I can say : "PLENTY ..."

If you wish to learn my ideas I am ready to make remarks .

Thank you very much ,

Mehmet Erol Sanliturk

Hi Mehmet,

This is an extremely narrow vision, and I am afraid you are missing a lot of approaches developed in the last few years. I advise you to visit www.intel.com. They have a number of article of different compiler approaches for multicore CPU utilization. They cover everything from the classic multiprocessing and multithreading all the way to execution of single thread over multiple cores trough instruction distribution. I am sure you will be amused at what possibilities are there for compilers to employ ;-) .

With best regards,
Boian Mitov

-------------------------------------------------------------------- Mitov Software
http://www.mitov.com
--------------------------------------------------------------------

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.

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.

Op woensdag 30-07-2008 om 04:42 uur [tijdzone -0700], schreef Mehmet Erol Sanliturk:

As a Computer ( let's say Scientist and/or Engineer ) I consider every idea exchanging as a good activity .

Before we start to talk, it's important to make the difference between the engineer and the scientist.

The scientist is always in favour of discussing and exchanging everything. Regardless of if it will lead to anything. I would say that those kind of discussions could be held elsewhere. ;)

The engineer only tries to resolve problems that arise. And will only discuss something if it can lead to something usefull.

That's more my thing.

Joost.