Python compiler?

CyberGuest rickymz at yahoo.com
Tue Apr 24 11:55:34 EDT 2001


can't wait to see it!


Jeff Epler wrote:

> On Tue, 17 Apr 2001 22:35:56 GMT, news-server.columbus.rr.com
>  <antediluvianistic at columbus.rr.com> wrote:
> 
>> Has everyone contemplated upon creating a python 'compiler',  which can
>> produce a self-contained binary executable?  (for when speed is an absolute
>> neccessity)  ..or does such a thing exist already?  I'd love to give game
>> development in Photon a run,  and feel that it's simply not fast enough to
>> perform some operations.
>> 
>> Any thoughts/comments are appreciated.
>> Brian
>> 
>> 
> 
> 
> I started work on a project of this type.
> 
> I implemented basic type information (ints, floats, sequences, mappings,
> functions, the last three with parametric types), the concept of
> "type widening" (a type which contains at least the union of the two given
> types) and the concept of the result of an operation such as addition,
> subscripting, slicing, and calling.  (actually, I think slicing was not
> yet implemented)
> 
> Then I implemented a type inference engine which worked on Python
> bytecodes.  At each bytecode, the types of each local and each active
> stack position are determined.  In the presence of looping constructs,
> the code is repeated until the type information "settles" (So it's
> possible to write functions which currently take infinite time in the
> inferencer.  Example:
> 	def f(t):
> 		x = None
> 		for i in range(t):
> 			x = [x]
> 		return x
> ).  About a
> dozen bytecodes were actually implemented, not the full set.  Since a
> function's result type is parametric on its input type, calling the
> inference function with a bytecode function and proposed arguments.
> Thus, given
> 	def f(x):
> 		return x*x
> you might propose that f be given an integer:
> 	>>> infer(f, (IntType())
> 	IntType
> or a float:
> 	>>> infer(f, (IntType())
> 	FloatType
> 
> Another concept I introduced is the "solidification" of a function.
> Certain globals and module contents can be marked as "solid", and loads
> of them will be hoisted into constant loads.  Typically, builtins like
> 'range', the 'math' module, and its contents would be marked as "solid".
> This sidesteps the issue of whether the type inference is correct given
> the possible future modification of range(), and is a small
> optimization.  (These builtins are given type information by hand)
> 
> Next I implemented a native code generator using GNU Lightning for JIT
> compilation (Emitting C code would be another alternative).  Using the
> type information, it was hoped that the following optimizations could
> be performed:
> 	* Float and integer arithmetic done inline
> 	* Calls from JIT functions to JIT functions as native calls
> 	* Overhead of the bytecode interpreter loop gone
> I implemented a similar subset of bytecodes in the JIT compiler as in
> the inference system.
> 
> This system can't JIT compile any useful code yet, and much of it has
> become outdated by bytecode changes since Python 1.5.2.  Exception
> handling was another big issue which I hadn't made so much as a nod to.
> 
> If anybody's interested in this code, I'll be happy to send you what I
> have.  It's covered under a Python-style license.
> 
> Jeff





More information about the Python-list mailing list