Hello,

Then again when I think about this some more it doesn't seem to make much sense... since free pascal does have RTL for other platforms.

And it also has "cpu's" for other platforms.

So perhaps what is needed is the following:

The RTL which is necessary for the other platform must first be compiled for the current/hosting platform/cpu.

The CPU which is necessary for the other platform must first be compiled for the current/hosting platform/cpu.

This would then produce a FreePascalCompiler.exe which would be able to run on Windows/i386 but which would be capable of compiling towards the RTL/CPU of the target platform. The only difference is that internally that either RTL/CPU was compiled for the host platform but that doesn't matter... that's just so the executable can run the code which will ultimately produce the correct assembly for the target platform...

The correct assembly would then contain the "translated/converted" RTL/CPU code which would be in the applications produced with this "cross compiler".

Thus I think free pascal compiler should be able to function as a "cross compiler" as well ?

So I think this conceptually involves the following steps:


1. Download free pascal sources codes and executables for current host operating system. (For example windows)

2. Specify what the target platform should be. (Tell the compiler this somehow via options/switches)

3. Then simply compile any application source code for the target.



However this conflicts with what other people have been telling me... and it also conflicts with the source code of the compiler itself which includes "defines" and "conditional compilation" for all the different platforms... I am not sure if all those platforms can actually be enabled all at the same time and be all compiled at the same time for a single compiler...


In theory this should be possible... but in practice it seems the sources where created in such a way that cpubase.pas is pretty much an alias for the folder of the target platform, which is specified via "search paths" this is probably done via the make files.


A solution to be able to compile to multiple "true" targets would be the following:

1. Rename all units in the "platform" subfolders so that they have unique names.

2. Rename all their classes and methods/routines so that they have unique names.

3. Use routine pointers/function pointers/method pointers inside the compiler itself which uses them to call a platform.

4. Hook-up the platform routines to these pointer variables.

(An alternative could be virtual functions/methods but I saw one post saying that this is unwanted in the compiler for some reason... why exactly wasn't explained... except that this would be "harder" ? perhaps harder to debug/or patch the compiler itself in case of problems ?)

None the less pointer variables don't seem that complex...



From documentation/manuals/tutorial/and/or postings I also saw some mention
about language specific features/platform specific features/or platform specific code which might be in the compiler/parser itself... I am not completely sure about this and how much of a problem it would be for this new idea... but I supposed some branches/if statements here and there would probably be sufficient to solve such "specializations towards certain platforms".



So I shall now ask the free pascal compiler "core/main" developers or "big bosses" ;) =D the following question:

1. Why is it not possible for a single free pascal compiler executable to support and compile towards multiple targets ? (One target selected out of multiple target options)

Would there be any big technical hurdles to turn the free pascal source code into such a beast ? What would be disadventages and potential problems now or in the future ?

Is it perhaps lazyness ? Not wanting to turn lot's of code into something that can do this ? Or you tired with the sources and don't want to change them towards something like this ? Is it fear for breaking things ?

I can imagine perhaps some technical drawbacks or perhaps some physical/emotional drawbacks.

If it's the latter then at least there is a possibility that this could be done be it by others with a little guidance from you.


I am not saying that this should happen immediatly... but I do want to know what could be possible in the future ;)

Bye,
 Skybuck.




_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to