Python Front-end to GCC

[Philip Herron]

Hey all,

Thanks, i've been working on this basically on my own 95% of the compiler is all my code, in my spare time. Its been fairly scary all of this for me. I personally find this as a real source of interest to really demystify compilers and really what Jit compilation really is under the hood.

For example if your really interested to see what jit compilation really is (not magic) look at:
http://compilers.iecc.com/comparch/article/10-03-063

And i really believe in this project. Though i really want to say away from comparing my project to any others out there. As they are much more mature than mine.

For example its only a few commits back your successfully able to compile:

import sys

So i think its fairly unfair comparisons could get me into trouble. Whats taken so long is i do not reuse the python runtime like the others. Other projects do this to maintain computability mostly. But i wanted to test doing this entirely from scratch partly for my own interest and that the python runtime was designed for an interpreter, not compilers at least ahead of time.

Its interesting a few things come up what about:

exec and eval. I didn't really have a good answer for this at my talk at PYCon IE 2013 but i am going to say no. I am not going to implement these. Partly because eval and exec at least to me are mostly from developing interpreters as a debugging exercise so the test doesn't have to invoke the program properly and feed in strings to interpret at least thats what i have done in the past with an virtual machine i wrote before gccpy.

I think anything you look up on eval and exec you shouldn't use them in production code as it could lead to a lot of issues. I can see their use in quick dirty uses but i don't think they really are part of the python language in my opinion its just some builtin functions that you can invoke. Another issue i had was:

class myClass: pass

I currently don't allow this but i've re thought this and i am going to try and implement this properly before i had a really complicated to pass to quess the type of a struct but i realise currently with how things work this may not be the case.

As a personal comment i think this is kind of funny as why not use a dict. But i can see the use for it now, and i want to implement it.

What i will say is gccpy is moving along with each milestone i will achieve over the course of the first half of 2014 i reckon i could at least compile half of a decnt python test suite. Its taken me so long to get used to the GCC code base and how i want to implement things i've re-wrote the runtime and the compiler probably at least 4 times and i am going to rewrite part of the runtime today for the next week or so. I think tis a worth while project.

I don't think this will ever be on par with PyPy or CPython as professional as those projects are i really respect their work i mean i look up to them (loads) i am just a guy who likes compilers and it isnt my day job i don't get paid for this i just enjoy the challenge and i hope you understand that this is my baby and i am very protective of my project :).

I hope in a few months when i start compiling testsuiites i will publish benchmarks what i will say is it looks pretty good right now only 1 case so far (that i have tested) where i am not faster than CPython and its only because i havent been compiling the runtime library with correct CFLAGS like -O2 etc i wasnt passing anything another is i have tonnnes of debugging malloc all over the show slowing it down because i need to rewrite part of the runtime so yeah. I've been fighting GCC for 4 years now i am fighting my own code ;).

Final note i am not saying JIT is bad or not the way to do things i personally think this question isn't answered and i can see the case for it there are down sides that jit people wont talk about.

The complexity of maintaining a j it in project is probably the main one and optimisations at runtime make it even more mental as they are hard to do is an under statement never mind they aren't as common as you would want to believe outside of target specifics which gcc already knows (-mtune*). I do believe JIT is the way forward but i think something in languages needs to really be designed from that perspective and maybe even cpu's to help with some kind of instructions to help maintain a destination between runtime and user code or something (making tail call optimisations easier on dynamic languages) maybe?

Thanks.