[pypy-dev] is anyone actively hacking on the JVM backend?

[Niko Matsakis]

Hopefully, these changes will not particularly affect anyone not  
actively touching the jvm directory.  The only changes in oosupport  
are the addition of various "prepare_" methods to the Generator  
class.  These methods give the jvm backend an opportunity to push a  
this pointer here and there, but for those methods I added a default  
"do-nothing" implementation.  For example, there is a  
"prepare_call_primitive()" which is called before the arguments for a  
primitive are pushed onto the stack.

I think that the oosupport code could probably be refactored, though  
I'm not precisely sure how right now.  Right now it is basically a  
thin layer that extracts some useful information from the 'op' objects  
and passes it to the generators; furthermore, it uses this stack-based  
API which doesn't give much information to the backend about why  
something is being pushed (i.e., is it a function argument?  if so, to  
what function? etc).  This is ok as far as it goes, but maybe there is  
something more elegant?  As I said, I don't have any precise  
suggestions right now, but it's something to think about.


Niko

On Nov 29, 2007, at 8:24 PM, amit wrote:

> Hi Niko,
>
> I am working on the "CLR" module --- ..pypy/module/clr/
> Just trying to play around with   "interp_clr.py"  and   
> "app_clr.py"  in there.
> Hope your commits will make it more better.
>
> regards,
> AmitReg
>
>
>
> Maciej Fijalkowski wrote:
>> As noone answers... I think amitReg is doing some CLI related  
>> stuff, which means you can stomp on each other on oosupport, but  
>> he's doing rather library integration, so sounds very unlikely.   
>> Besides, I'm not aware of anyone.
>>
>> Cheers,
>> fija
>>
>> On Nov 29, 2007 7:46 PM, Niko Matsakis <niko at alum.mit.edu <mailto:niko at alum.mit.edu 
>> >> wrote:
>>
>>    I have been making small improvements to the JVM backend: I am  
>> aiming
>>    towards eliminating any remaining conformance problems, and also
>>    towards fixing a few warts in the implementation.
>>
>>    Right now I am wringing out the last few bugs from a check-in that
>>    would allow multiple PyPy-generated interpreters to be used
>>    simultaneously.  Currently, the code uses a few static fields that
>>    would conflict if, for example, someone tried to load both a  
>> Python
>>    and a Smalltalk interpreter into the same JVM.  These static  
>> fields
>>    were used to allow the helper code (src/PyPy.java and friends) to
>>    create instances of exception classes and other RPython-generated
>>    code.  The new code creates a single instance of the PyPy helper  
>> class
>>    per generated interpreter and use non-static-methods instead,  
>> which
>>    should be better.
>>
>>    Anyway, I just want to be sure I am not stepping on anyone's  
>> toes if I
>>    check this in, since it makes small changes all over the place to
>>    ensure that the proper PyPy object is pushed onto the stack, etc.
>>
>>
>>    Niko
>>    _______________________________________________
>>    pypy-dev at codespeak.net <mailto:pypy-dev at codespeak.net>
>>    http://codespeak.net/mailman/listinfo/pypy-dev
>>    <http://codespeak.net/mailman/listinfo/pypy-dev>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> pypy-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/pypy-dev
>