compiler and rtl seperation

[JazzMazz88]

This is one of two major improvements that Id like to see. Of course apps will need both the RTL and compiler. What Im recommending allows use of custom RTL. Somewhere in the documentation we are requested for new OS or custom function to use a custom RTL and system unit. However, in all actuality this is a pipe dream. Trying to do so WILL NOT WORK due to the ingrained compiler functions now missing from the new RTL. Try diagnosing the whole RTL for what you need. Its a nightmare and a half. I spent good most of three years trying a new RTL.

What I would up doing is duplicating the Linux RTL and dereferencing Linux during makefile build and doing same with the object functions, which were clearly unavailable on a Linux OS spin. This took some figuring out and minor work but the object code can be avoided.

We need to go back to the old days where the compiler wrote itself, as FPC should be able to do. However, the RTL should be compiled seperately, not function hooked into the compiler.Object, and other dialects and functions should be in the RTL, not the compiler. If you dont understand me, look at how TP7 does it. The system unit group is compiled with applications but not built into the compiler itself. If you need to lets say change out the crt unit:
You unpack the system unit
You replace the crt unit with another one
You repack the new system unit
And off you go.

You really cant do this with FPC as packaged.Not directly. Your custom units need to be part of your application(kernel, in my case).

This leads to a second issue.

Dont ask for my sources, I have replaced them on google code, which is now dying and I lost the backup set that the code was on.What remains is a very very basic barebones pascal kernel.

[Cyrax]

Er, even if you compile TP7 with TP7 you do have RTL included in it : System.

You are speaking of TURBO.TP(L) (library) which is just a archive containing of SYSTEM.TPU, special SYSTEM file which will be need to be extracted if you want to recompile SYSTEM.TPU, CRT.TPU and (maybe?) other compiled units.

[Thaddy]

@JazzMazz88:

I wonder if you ever tried what is possible with the embedded platforms? AFAIK and tested that proves you wrong all over the place. Which also means that @Cyrax: answer is not totally accurate.

[marcov]

This is one of two major improvements that Id like to see. Of course apps will need both the RTL and compiler. What Im recommending allows use of custom RTL.

There already are various custom RTLs. Of course you must adhere to all relevant requirements, and even might have the information of the compiler has about your target.

Everything is open source, and in general customization is much easier than other compilers.

There is a certain hurdle of course when you start to develop the system rather than just use it, but that can only be expected when venturing from the application developer into a more system developer role.

Somewhere in the documentation we are requested for new OS or custom function to use a custom RTL and system unit. However, in all actuality this is a pipe dream. Trying to do so WILL NOT WORK due to the ingrained compiler functions now missing from the new RTL. Try diagnosing the whole RTL for what you need. Its a nightmare and a half. I spent good most of three years trying a new RTL.

Strange. I wrote the core of the Unix rtl basically in during a week of christmas holidays (that is system unit), and then did the finishing touch and multiple targets in evenings in the 1,2 months after at fairly low intensity. How hard can it be?

What I would up doing is duplicating the Linux RTL and dereferencing Linux during makefile build and doing same with the object functions, which were clearly unavailable on a Linux OS spin. This took some figuring out and minor work but the object code can be avoided.

"object" functions? Please be clearer.

We need to go back to the old days where the compiler wrote itself, as FPC should be able to do.

Please explain how TP7 wrote itself. To my best knowledge the .EXE always remained the same.

However, the RTL should be compiled seperately, not function hooked into the compiler.Object, and other dialects and functions should be in the RTL, not the compiler.

How can language features be entirely in the RTL?

If you dont understand me, look at how TP7 does it. The system unit group is compiled with applications but not built into the compiler itself. If you need to lets say change out the crt unit:
You unpack the system unit
You replace the crt unit with another one
You repack the new system unit
And off you go.

So where in the TP rtl is the new for new(mobjinst,TMyobject.init); defined?

You really cant do this with FPC as packaged.Not directly. Your custom units need to be part of your application(kernel, in my case).

I don't understand this. You can simply make your modifications in the RTL dir, compiler the rtl, and other files you need, and put it in some directory that you reference with -Fu in the fpc.cfg.