tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] llvm IR target


From: Jared Maddox
Subject: Re: [Tinycc-devel] llvm IR target
Date: Tue, 11 Mar 2014 23:54:58 -0500

> Date: Mon, 10 Mar 2014 13:14:03 +0100
> From: mobi phil <address@hidden>
> To: Thomas Preudhomme <address@hidden>, address@hidden
> Subject: Re: [Tinycc-devel] llvm IR target
> Message-ID:
>         <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thomas,
>
> wanted to keep low noise, thus did not disclose more details, but here it
> is:
> I am experimenting with some language extensions, such as classes/objects,
> fibers, etc. For some parts of the could just use C++ but among other
> annoyances for me in C++ is that I do not have "official" access to the
> virtual
> function pointer table. The list is long. I call these extensions
> decorators.
>
> One can think this as a macro and preprocessor replacement, where the
> replacement preprocessor is supposed to understand part of the syntax
> context.
>
> I tried to do all that with macros... but after really lot of work in
> hacking around with
> macros like in boost preprocessor, I decided to stop fighting the wind
> mils.
> Though ended up in writing nice macros for class declaration/initalization,
> for method calling etc.
> With macros, I could have stayed 100% C, but the price was too high.
>

Was the lack of a looping mechanic the problem? The C preprocessor
doesn't have intentional looping capabilities because of a desire to
avoid infinite loops, but the current status-quo (where, as Boost has
demonstrated, you can get limited looping) can be maintained in
conjunction with loops by only allowing "count-down" loops and/or
variadic-template-styled "consume input until underflow" loops. For
code generation (I think my original use case was an obnoxious switch
statement), this should be enough for most or all cases.

Another option is to just pull out the TCC parser into a separate
piece of code. The actual parser code is fairly straightforward, so
once copied into another project/sub-project/file it should be fairly
easy to extend. If your extensions are going to have similar syntax to
existing TCC constructs (e.g. if class/object declarations are similar
to structure declarations) then you should even be able to copy&paste
syntax forms. From that point you would just need to provide the
function that the parser actually calls. I assume that this would also
be a good way to dip your toes into compiler design without jumping
into the deep end all at once.

> So I am trying to add these decorators through minimum language extensions.

Do they need to be keywords, or can you hook into the GCC-style
attribute system?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]