"Reinder Verlinde" <reinder@[EMAIL PROTECTED]
> wrote in message
news:reinder-68E55E.17351623022008@[EMAIL PROTECTED]
> In article <c05b0$47bfeebb$ca83b482$9782@[EMAIL PROTECTED]
>,
> "cr88192" <cr88192@[EMAIL PROTECTED]
> wrote:
>
>> well, recently I came up with an idea, but it has turned into a bit of
a
>> mess on me...
>>
>> I have an existing C compiler I wrote before, and it is organized about
>> like
>> this:
>> Preprocessor;
>> Parser;
>> Upper Compiler, converts syntax trees to RPNIL;
>> Lower Compiler, converts RPNIL to assembler;
>> Assembler;
>> Linker.
>>
>> so, the upper-compiler ends up being fairly sparse, mostly being a
fairly
>> dumb converter.
>>
>> the output, I call RPNIL, is a vaguely Forth or PostScript like
language
>> representing the intermediate version of the language.
>>
>> [lots of info removed]
>>
>> or, I can do the basic library (serving as a codegen), and possibly
later
>> write an SSA style frontend (and rework the upper compiler to target it
>> directly).
>>
>>
>> anyone have any thoughts?...
>
> Many people have thoughts, but I am not sure what you are looking for.
> What I miss in your description is what exactly you want to achieve.
> Possible answers could be:
>
> - getting to learn how to write a 'real' compiler chain
> - getting a better C compiler
> - getting a faster C compiler
> - fixing known code-generation problems in your existing code
>
actually, the goal is for dynamic compilation and blurring the line
between
compile time and runtime (basically, using C like we would many script
languages such as Python or Scheme, but still retaining the power and
performance of C).
for example, if I had lexical closures and eval in C (both eventual
planned
features), then that would be worthwhile.
another recent goal/feature was the addition of machinery to aid with
Persistent Storage, DSM (Distributed Shared Memory), and code possible
mobility (AKA: watch as lexically-scoped code objects migrate over the
network).
....
> I guess that, in all cases, you will want to look at
> <http://www.llvm.org/>
and <http://clang.llvm.org/>.
It might lead to
> one or more of:
>
> - ideas about organizing your code
> - ideas about using LLVM as your intermediate SSA language
> - ideas about ditching your code, and start contributing to LLVM
>
I already know about LLVM, and though an interesting project, I don't
entirely agree with it in some ways, nor do I really believe everyone
needs
to settle on the same implementation.
I also might have acted differently had I known about clang to begin with,
but once I learned about it, I figured, "well, I already have my own
implementation"...
also, it is written in C++, and follows an uber-centralized
class-heirarchy
based design (aka: 'OOP'), which I personally find disagreeable as well (I
prefer a modular aproach, and not an inheritence-based approach).
after all, it is good if I can rip out and replace parts of a project as
needed, rather than having to view it as some integrated whole...
having a single integrated lower compiler hinders this, in making it to
where I can't really "swap out" things for other things...
to what are my ends, I also feel I better achieve my goals than LLVM does
for me (after all, I already have a decently working framework in < 1
year).
actually, I had also vaguely considered using the LLVM IR language as the
SSA syntax, but for the time being figured it would be too much of a
hassle
to parse (allowing the low-level code generator to be swapped out could be
a
useful feature though, esp since LLVM sup****ts more targets than just x86
and x86-64, ...).
of course, right now I have some doubts as such that adding SSA will make
the code any simpler though (one of the original considerations for
considering splitting the upper and lower compilers). rather, it has
merits
in its own right, but these merits are not necessarily simplicity...
my lower compiler is as such a 30 kloc mass of highly-interconnected code,
and a 10/20 or 15/15 split would be nice, but more likely, such a split
(and
addition of SSA) would turn out as 20/25 or similar...
it may also make sense to have multiple possible backends around as well
(for example, I had once considered the possibility of a CPS-based RPNIL
backend, ...).
or such...
> Reinder
|
