[pypy-dev] is anyone actively hacking on the JVM backend?
Antonio Cuni
anto.cuni at gmail.com
Fri Nov 30 10:38:00 CET 2007
Niko Matsakis wrote:
> Right now it's mostly in the JVM backend, though I had to insert a few
> hooks into oosupport. I wasn't sure whether the CLI had the same
> "interlinking" problem.
yes, the problems are nearly the same for the cli backend; basically, we
want:
1) to raise RPython exception from C#/Java code
2) to create records with a specific set of fields
Right now the solution for (1) is very hackish: I have a stub file
called main.exe which contains dummy functions to raise exceptions;
pypylib.dll is compiled against main.exe, but then we compile the real
executable so at runtime pypylib.dll is linked to a new main.exe which
contains functions with the same name&signature as the dummy ones.
Basically, we have a circular dependency between pypylib.dll and
main.exe; believe it or not, in .NET it works :-).
I know, this solution is very ugly and moreover it forces the executable
to be named main.exe. Interlink sound a much better approach :-).
For (2), the current solution is to write the records we want directly
in C#/Java, and let the backend to special case those when rendering the
name.
Unfortunately, I can't see a general solution here; the interlink
approach works only for records which you only need to create and not to
manipulate, but e.g. it can't work for StatResult because you still need
to set individual fields after its creation. I guess this is the cause
why StatResult is still implemented "the old way" in genjvm.
> I can look into whether more of the code could
> be pulled into oosupport, but if I recall the two main places I had to
> add hooks were:
>
> 1. When rewrite the opcode table, I check now if the action for an
> opcode is a virtual method: if so, instead of rewriting it to
> "PushAllArgs, Invoke Method, Store Result," I rewrite it to: "Push PyPy
> object, PushAllArgs, Invoke Method, Store Result."
Uhm... sorry, I can't see why this is necessary; could you explain a bit
more in detail please?
> 2. I added prepare_ hooks for oostring, oounicode, and primitives, which
> basically just push the receiver object.
>
> We could probably pull more into oosupport, particularly if it gained
> the ability to talk about static fields and things.
That would be nice; it would be a nice sprint topic, if only there were
a sprint planned soon :-).
ciao Anto
More information about the Pypy-dev
mailing list