Jochen Hoenicke wrote:
> 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've actually implemented something similar to this (or was in the process of
implementing it) in my jit written in java, called Aladdin.
so,
bipush 14
istore 1
would become:
v1 = 14 <push v1 onto name stack>
<pop name off stack when you see istore>
vars[1] = v1
you don't need to keep track of how many stack slots an item takes up, since all
that gets compiled away - there is no stack. pop, dup, all those instructions
go away. ElectricalFire works in much the same fashion.
> I know that good register allocation might cause some overhead when
> compiling methods (i.e. long startup time).
Yeah, electrical fire had this very problem with the Character class's static
initializer. it was huge, and would take a large amount of time to build/color
the interference graph.
> 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.
Yeah, then you run into the interesting problem of what to do if a method is in
an infinite loop, calling other methods. you'd never compile the method with the
loop in it. The interesting problem is how to reliably replace the running
interpreted code with jitted code - or more generally how to replace running
code with more highly optimized code.
> 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.
very cool :)
Chris
>
>
> > 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
--
<saturn5> do { addMoreFeatures(); } until (engineers = 0);
