[pypy-dev] llvm2 update

Carl Friedrich Bolz cfbolz at gmx.de
Sat Jul 16 00:44:41 CEST 2005

Hi Richard

Richard Emslie wrote:
> I've just added a dummy OpaqueType implementation and refactored the 
> database wrt to pbc nodes.  So pbcs are working for classes too now.

Cool! Although I don't really understand anymore how the database works 
(although I haven't looked into it in detail, so it's probably my fault).

> Here is a brief overview of things that (I think) still need to me done.
> todo (probably in this order):
> * exception flow of control
> * any missing operations implementations (bit shifting for instance).
>   These can be added when they are needed and should be straight forward.

Bit shifting can probably be taken from genllvm1 (at least the ideas, 
the node model was of course completely different).

> * review and update external function implementations for new way of doing
>   things
> * overflows on ints/etc (more on that from Carl Friedrich...)

I think we can do this similarly to genc: have some header files which 
contain error checking implementations of the operations. This will be 
mostly easy as soon as we have exception support. Or lets rather say as 
easy as in C (which can be difficult for floats for example). The only 
tricky thing could be to find out how to instantiate exceptions on 
LLVM-level, but that, too, depends on exceptions so we have to wait 
until these are done.

> refactoring:
> * should is_atomic() be a method?
> * grep "XXX"s :-)
> Of the above I am guess that exceptions are most interesting.  The 
> unwind / invoke operations of llvm fits this quite well, but still need 
> somewhere to store the exception and do matching - unless I missed 
> something?  Any thoughts / takers?

Some notes from my experiences with genllvm1: LLVM's exception model is 
a nearly perfect match, it was really easy to implement exceptions. The 
idea is (at least if the operations is implemed as a function) that the 
last operation in an try block does not get called, but invoked. Normal 
operation resumes in the None block, if an unwind occurs control flow is 
transfered to an special block where we try to match the exception to 
the links from the original try block. If there is no match we unwind 
again, otherwise control is transfered to the matched block.

If we raise an exception we store the exception and the type in a global 
variable. The matching code has to be similar to what genc does, I think 
that's the only part that could get slightly complicated.


Carl Friedrich

More information about the Pypy-dev mailing list