Pliant bootstrapping code

This documents explains how to dig in the Pliant bootstrapping code written in C.

Pliant C part configuration

Some constants specifying the environment, such as _GCC_ or _LINUX_ or _REGISTERS_ are defined directly in the script used to compile Pliant executables. Theses scripts are in /pliant/language/install/

Since Pliant is a true compiler, it needs to know how to generate the code for passing parameters to the function to be called. The calling conventions are surprisingly not processor related but rather C compiler and OS related, so a /pliant/language/declare/call.c module is defining extra constants providing detailed description of the compiler calling conventions.
This file has to be updated if you change of compiler, OS, processor, or simply change some compiler flags.

Then, extra constants and C structures are defined in /pliant/language/declare/struct.c
It is a global structure instead of C global variables as usual to make saving and restoring all of them from the dump file easier (see 'process_backup' and 'process_restore' in /pliant/language/os/dump.c).

The prototype of various C written functions of Pliant bootstrapping code is provided in /pliant/language/declare/proto.c because modern C compilers don't like (basic sanity check) calling functions they have not previously received the prototype of. A few constants also landed here.

Pliant process startup sequence

Assuming that the Pliant bootstrap executables have been compiled using GCC, just after loading the executable, control will be transfered to /pliant/language/startup/start.s

Then, control is transfered to a function (sometime named 'pliant', sometime 'main', sometime 'startup' depending on the execution model) at the beginning of /pliant/language/startup/startup.c
This function will parse the command line. Most of the time, it will result in calling 'initialize', then 'load_module'.

'initialize' (also in /pliant/language/startup/startup.c) is a very important function to understand the layout of the Pliant C bootstrapping code.
It will first try to call 'process_restore' to load a dump file. A dump file is a dump of the Pliant process memory that enables to start a Pliant process without recompiling all modules from scratch, so it's just a way to speedup startup. Another way to see the dump file notion is that it replace a feature lacking in Unix, which is the ability to freeze a process, save it to a file, then load the file and restart it at a later point. This is a feature now available at virtualization level, but strangely enough not yet available for standard processes in any mainstream operating system.
Now, if no dump file is loaded, 'initialize' execution will continue, and the Pliant global dictionary will be created and loaded with all types and functions defined in C. It is very import to understand that when you want to know how something written in the C part of Pliant works, you have to look here to determine how it is declared from the Pliant language point of view, find the name of the underlying C function that you can then search and review.

FAQ

Why is there a part of Pliant written in C, instead of self compiling Pliant compiler ?

In the early days, you need to write the compiler in another language to get something running. Then, with static languages such a C you can rewrite the compiler code in the new language itself and use the new language compiler to compile itself. It's a bit more complicated for a dynamic language like Pliant because Pliant compiler never outputs an executable, so I would have to use a modified version of Pliant compiler that generates C, assembly or an ELF executable.
It would be very satisfying from the intellectual point of view, but would not bring much on the practical side beyond a bit less chicken and eggs tricks and better error position reporting when the crash is in some C written function.
I just never found time and energy to do it.