[pypy-dev] llvm2 update
Carl Friedrich Bolz
cfbolz at gmx.de
Sat Jul 16 00:44:41 CEST 2005
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
> * 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.
> * 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.
More information about the Pypy-dev