|Pliant talk forum
Discussion: Bootstrapping Pliant
Reimplementing Gordon Matzigkeit's retargetable cross-compiler for Pliant project.
|Message posted by maybe Michael FIG on 2006/04/26 01:56:37
|I have some experience with Pliant compiler internals and an understanding of how
Are the Pliant compiler internals stable enough for me to attempt implementing a
Pliant compiler within the Pliant syntax?
I would follow a little of Gordon's design, which basically involves implementing
a distinction between the build, host, and target environments (the programmer
can choose which environment a function or meta can run in).
The rest of the design would be to rework the existing C-implemented compiler
functions as a Pliant object.
I estimate that if you (Hubert) agree that this would be an interesting idea,
it would take a month or two to get a working model going, since I would be able
to use the existing C sources as a guide for implementation and to help avoid bugs.
Please let me know what you think of this idea,
|Message posted by hubert.tonneau on 2006/04/26 08:41:38
|> Are the Pliant compiler internals stable enough for me to attempt implementing a
> Pliant compiler within the Pliant syntax?
. no plan at all to change the Pliant compiler internal machinery (I'm
satisfied with it)
On the planed changes that may impact in this area at some point I have:
. make a i86_64 version (quite a lot of work because Pliant interface with
the OS and external libraries is very dirty as far as the C int versus long
. improve the code generator
None of these fits in my next 12 monthes planning, at least.
So, unless some external contributions step in, you can expect Pliant compiler
to be perfectly stable within the next 12 monthes (it has been so now for years).
As far as my Pliant planning for the next year is concerned it is:
. finish the storage system core (experimental)
. start writting a book about computing culture (not at all a Pliant manual)
. slowly turn the Pliant UI from experimental to production quality
. improve the install and configuration interface (and switch it to using the UI)
> I estimate that if you (Hubert) agree that this would be an interesting idea,
> it would take a month or two to get a working model going, since I would be able
> to use the existing C sources as a guide for implementation and to help avoid bugs.
It is from the intelectual point of view, and even more from a teaching point
of view, so Patrice and Marcus may be even more interested with it. On the
practicle side it also solves the chicken and eggs problem of the current
implementation, but in order to fully benefit from that last point, we would
need to already have turned the Pliant code generator to state of the art (*).
From my point of view, switching to 64 bits is more important in order to be
abble to efficiently use several gigabytes of RAM to store more objects in the
cache and larger databases, so that's what I'll do first when back to the
compiler, also since contributions to free projects are not paid, it is the
right of the contributor to select what he likes most to work on.
So, you are welcome with your project to reborn the cross compiler.
(*) There used to be a GCC interface as an easier way to turn the code
generator to state of the art, but there is no easy way to parse GCC output,
so it broke when GCC switched from 2.95 to 3, and I was too lazy to upgrade it
since I don't use it on production servers.
|Message posted by maybe Michael FIG on 2006/04/27 03:08:44
|Alright, then... I'll post to the forum as I encounter problems or make progress.
|Message posted by maybe Michael FIG on 2006/04/27 22:38:53
|>Also, I'm interested to read an overview of your cross compiler plan.
>Some issues are complex so it may save time to exchange about the framework
>before too much code is written.
Each stage of this project preserves backward-compatibility with
existing Pliant code that uses the compiler internals.
The first phase is the existing Pliant compiler translated into Pliant
(*.c becomes *0.pli), using the CurrentProcessTarget as the compiler
target. The result makes it possible to compile and execute all
existing Pliant sources using the new implementation. It also gives
me the chance to read and understand the Pliant compiler C code.
The second phase is to provide different target objects. At this
point, it will be possible to instantiate multiple compilers in the
same process, and start creating simple native binaries like Gordon
Matzigkeit's retargetable Pliant compiler experiment did.
Each object that participates in code generation has a Target object
associated with it. Then, everything that currently uses a 'pliant ...'
symbol to control compilation instead asks the Target object to decide
what to do. The CurrentProcessTarget uses the 'pliant ...' symbols
just as before.
The third phase is to annotate the core PDEE code with `host' metas so
that it can be cross-compiled to other targets. To test this stage,
try bootstrapping the whole Pliant compiler on a new platform.
>On the other hand, what ever solution you select, translating line by line
>the C code to Pliant code is required (except if someone decides to write
>a Pliant C syntax parser) at some point, so it's ok to start that part without
Yes, that's what I thought. I had tried working with a C syntax parser earlier,
but I think that's more work and not as pretty as manually translating the code.
|Message posted by maybe Boris Reitman on 2006/04/28 06:50:36
|I think that enabling to compile C/C++ into pliant is a more important feature
to implement right now, for someone who wants to delve into pliant internals.
|Message posted by maybe Michael FIG on 2006/04/28 15:55:54
|It depends on your goals. My goal is to use Pliant for standalone executables,
embedded systems, and kernel development. Adding C/C++ support is still a
worthy goal, but I don't want to work on it until I'm certain that the
compiler internals won't change any more (which they may have to in order to
support multiple targets).
|Message posted by maybe Boris Reitman on 2006/04/28 19:21:02
|Ah, ok, you are right, this makes sense.