Hi all, I've just added a dummy OpaqueType implementation and refactored the database wrt to pbc nodes. So pbcs are working for classes too now. 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. * review and update external function implementations for new way of doing things * overflows on ints/etc (more on that from Carl Friedrich...) 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? Cheers, Richard
On Fri, 15 Jul 2005, Richard Emslie wrote:
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?
This is generally done with global variables. The C++ front-end basically generates code like this: C++: throw 42; Pseudo LLVM code: int *E = allocate_exception_memory(4); *E = 42; add_to_current_exception_stack(E); unwind I imagine that something similar should work for pypy. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Hi Chris! Chris Lattner wrote: [snip]
This is generally done with global variables. The C++ front-end basically generates code like this:
C++: throw 42;
Pseudo LLVM code: int *E = allocate_exception_memory(4); *E = 42; add_to_current_exception_stack(E); unwind
I imagine that something similar should work for pypy.
This is indeed pretty much what I did in genllvm1 (note that we're already writing our second LLVM backend :-). It's even a bit easier since we don't need an exception stack but only one single exception. One problem is that exception matching is not entirely straightforward although this is a property of the PyPy model and has nothing to do with LLVM per se. Regards, Carl Friedrich
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. Regards, Carl Friedrich
participants (3)
-
Carl Friedrich Bolz
-
Chris Lattner
-
Richard Emslie