On 10/20/2013 3:10 PM, victorgarcia...@gmail.com wrote:
> On Sunday, October 20, 2013 3:56:46 PM UTC-2, Philip Herron wrote:
>> I've been working on GCCPY since roughly november 2009 at least in its
>> concept. It was announced as a Gsoc 2010 project and also a Gsoc 2011
>> project. I was mentored by Ian Taylor who has been an extremely big
>> influence on my software development carrer.
>
> Cool!
>
>> Documentation can be found http://gcc.gnu.org/wiki/PythonFrontEnd.
>> (Although this is sparse partialy on purpose since i do not wan't
>> people thinking this is by any means ready to compile real python
>> applications)
>
> Is there any document describing what it can already compile and, if
> possible, showing some benchmarks?
After reading through a vast amount of drivel below on irrelevant
topics, looking at the nonexistent documentation, and finally reading
some of the code, I think I see what's going on here. Here's
the run-time code for integers:
http://sourceforge.net/p/gccpy/code/ci/master/tree/libgpython/runtime/gpy-object-integer.c
The implementation approach seems to be that, at runtime,
everything is a struct which represents a general Python object.
The compiler is, I think, just cranking out general subroutine
calls that know nothing about type information. All the
type handling is at run time. That's basically what CPython does,
by interpreting a pseudo-instruction set to decide which
subroutines to call.
It looks like integers and lists have been implemented, but
not much else. Haven't found source code for strings yet.
Memory management seems to rely on the Boehm garbage collector.
Much code seems to have been copied over from the GCC library
for Go. Go, though, is strongly typed at compile time.
There's no inherent reason this "compiled" approach couldn't work,
but I don't know if it actually does. The performance has to be
very low. Each integer add involves a lot of code, including two calls
of "strcmp (x->identifier, "Int")". A performance win over CPython
is unlikely.
Compare Shed Skin, which tries to infer the type of Python
objects so it can generate efficient type-specific C++ code. That's
much harder to do, and has trouble with very dynamic code, but
what comes out is fast.
John Nagle
--
https://mail.python.org/mailman/listinfo/python-list
