A simple C subset compiler

kjstol parrotcode at gmail.com
Tue Jun 5 12:35:10 UTC 2012


hi there,

M1's getting more complete by the day. Function invocations and
returns are working, _almost_ (making a few minor manual fixes in the
generated M0 code makes it work). The problem is that the called
function needs to know about which function it called, so its caller.
This is a problem, because obviously, any function can call any other
function. In particular, for a function to return, it needs to know
the name of the caller, which it takes from the CONSTS segment.

One way to do this is of course to pass the name of the caller. I
suspect this has something to do with continuation-passing style,
where you pass a continuation chunk, which is then invoked in order to
return. This will have to be figured out. So, please consider this
email as a request for further spec. of M0 :-)

Meanwhile, I'll continue with more basic stuff; enumerations, variable
scoping, and perhaps namespaces are next. Suggestions and feedback and
requests for features are welcome.

Comments welcome,
kjs



On Sun, May 20, 2012 at 2:59 PM, kjstol <parrotcode at gmail.com> wrote:
> hi there,
>
> Attached a new version; this does some basic code generation. I'm not
> really familiar with M0 instructions yet, but I made a few guesses.
> Expression handling seems to work well.
>
> There's many todos', but it's quite close to generating valid M0
> (acceptable by the perl assembler script). Conditional and iteration
> statements are not done yet (needs handling of labels etc.) but could
> easily be added.
>
> I'm not entirely sure what kind of syntax and functionality is needed
> at the M1 level. Is the idea to write PMCs at this level? In that case
> you'd want to have a "PMC" keyword I think, and allow writing member
> functions in such a PMC. Also, allocating memory could be built-in,
> rather than copying C's malloc and free function implementations.
> Also, do exceptions live at this level? In that case you'd probably
> want some kind of "try/catch" or alternative notation.
>
> to run:
> ====
> unzip the zip file
> cd m1
> make
> ./m1 t2.m1
>
> Feedback would be appreciated.
> thanks
> kjs
>
> On Sun, May 20, 2012 at 3:06 AM, kjstol <parrotcode at gmail.com> wrote:
>> hi!
>>
>> On Sun, May 20, 2012 at 2:55 AM, Vasily Chekalkin <bacek at bacek.com> wrote:
>>> Hello.
>>>
>>> Welcome back :)
>>
>> thanks :-)
>>
>>>
>>> For the record, current nqp-rx based ops compiler does parse subset of
>>> C already. In opsc_llvm branch it does parse even more. I would
>>> suggest to join efforts in defining "C subset" which we are going to
>>> use as m1 ops language.
>>>
>>> Most problematic parts iirc was:
>>> 1. Macros. C macros are pure evil. If we are going to support
>>> free-defined C macros it will require a lot of work. Limiting them to
>>> VTABLE macros will reduce this issue to trivial.
>>> 2. Ambiguous casting.
>>> 3. Implicit string concatenation.
>>
>> Thanks for sharing. I can see how scattered efforts are not helpful.
>>
>> It wasn't so much an effort to implement parts of C per se, more that
>> it's inspired by C: it's easy to read, easy to learn, and easy to
>> implement so far. Also, my efforts so far were an expression of my
>> self indulgence in some good hacking sessions, which I hadn't done for
>> a long time. It's been fun :-)
>>
>> In my opinion, for M1, we shouldn't strive for a subset of C per se.
>> There's many things wrong with C, and those things cause a lot of pain
>> and bugs. If there's going to be a language M1 or Lorito to implement
>> most of parrot (incl PMCs) it would be a good idea to define a
>> language that prevents many of those bugs, to create a language that's
>> really stable, clearly defined, and so on, and that forbids bad
>> constructs. For instance, no goto statement! (I'm even no fan of break
>> and continue statements). C's preprocessor is a cheap way of doing
>> modules properly, but it's kindof awful. There's better ways I'm sure
>> to support multi-file programs. I think it would be a good idea to
>> think well about how to encourage sound programming practices (C
>> doesn't really), and implement a language that does that well, while
>> still being easy to learn by C programmers.
>>
>> Meanwhile, my goal was to (1) indulge in my need for some hacking
>> creativity, and (2) create a clean and simple language implementation
>> that targets M0. Consider it a prototyping effort to identify gaps in
>> M0 and see how far we can get with little effort.
>>
>> cheers
>> kjs
>>
>>>
>>> --
>>> Bacek
>>>
>>>
>>> --
>>> Vasily
>>>
>>> On Sat, May 19, 2012 at 6:15 AM, kjstol <parrotcode at gmail.com> wrote:
>>>> hi there,
>>>>
>>>> I've indulged in some hacking time, and implemented a simple subset of C.
>>>> Attached is a zip file, just type "make" and it should work (assuming
>>>> you have bison and flex).
>>>>
>>>> What it currently does, it generates the parsed code from the AST (mostly).
>>>> Not everything of the language is supported yet (e.g., parameters
>>>> etc.) The parser would have to be fixed a bit, it has some known
>>>> limitations.
>>>>
>>>> The idea next is to implement a simple code generator to generate the
>>>> M0 ops that have been spec'ed so far.
>>>> There are many todos (e.g, thread-safety of the compiler),
>>>> register-allocator, etc.) most of which would be easy to implement.
>>>> For now, the focus would be on a simple and clean language
>>>> implementation that generate M0.
>>>>
>>>> Comments welcome,
>>>> kjs
>>>>
>>>> _______________________________________________
>>>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>>>


More information about the parrot-dev mailing list