Albrecht Kleine writes:
> Jochen Hoenicke <[EMAIL PROTECTED]> writes:
>
> > I have nice ideas of generating a jit that will cache most values in
> > register, so that load instructions aren't translated at all. This
> > should give almost optimal code. I want to code something that
>
> Did not yet look on your web pages, but this sounds interesting.
> For TYA I always searched a way to keep track on registers, but
> en detail I did not found simple ways to differ between CPU register stuff
> and NPU registers because there are some Java bytecodes independent of
> data type, for example "DUP2" is one of them. (And the x86 architecture
> doesn't give help in fast move data from one or two 32bit general purpose
> registers into the NPU stack, as far as I know.)
This part is not at my web page, only in my mind :-) The trick is, to
keep track of the stack contents. You must do this anyway, to verify
the code. Then you know at compile time, if the arguments to a dup2
is a double, a long, or two single slot datas.
I actually don't want to put the stack values into the stack. I want
to keep as much as possible in registers and if no registers are free
spill some of them into the "stack" (which is modeled by a fixed
length local variable array).
I know that good register allocation might cause some overhead when
compiling methods (i.e. long startup time). But one could include a
fast and a slow, but good jit compiler and use the slow compiler only,
if the method gets called for the n-th time.
BTW: I have written a bytecode verifier in java as part of my
decompiler. It doesn't check for existence and access modifiers of
methods yet, but that should be easy to add. My decompiler is at
http://www.informatik.uni-oldenburg.de/~delwi/jode/jode.html
Maybe I will port it to japhar someday.
> Hope for some success you'll have.
Thanks, I hope I find the time to realize my ideas.
Angelo Schneider wrote:
> > > Jochen, do you like to treat jit compiled methods like
> > > native (JNI) methods? Isn't there an other way?
>
> I meant (missunderstanding above) the signature. Your proposal
> for method calls looks very similar to JNI calls. Thus the question.
Yes, they look similar to the
(*jnienv)->Call(Static|Nonvirtual)ReturntypeMethodV
(Nonvirtual, because the _caller_ chooses the correct method via the vtable).
I needed the same parameter and thus I decided to make them similar.
This also makes it easier, to implement the corresponding JNI methods,
or the JNI stub methods. The difference from the JNI interface is,
that I use a HungryEnv and a MethodStruct instead of the corresponding
JNI types and that I omit the class parameter in CallStatic, which is
already accessible via the MethodStruct.
Jochen
