Hi Jecel,
on Fri, 17 Nov 2006 00:22:08 +0100, you wrote:
Klaus D. Witzel wrote on Wed, 15 Nov 2006 05:35:21 +0100
This chip has the Jazelle 1 technology,
Ah, I didn't associate Jazelle with ARM9. I thought that Jazelle was still for the lab guys.
We had a thread about this before. ARM calls two entirely different technologies "Jazelle". I described the older one below and it is present in many commercially available chips. The new one is not out of the labs and is just a special variation of their Thumb instruction set optimized as a target for JIT compilers (so it would be nice for Exupery, for example).
Ah, IC.
which is unfortunately hardwired for Java. The most common bytecodes get translated on the fly into a single ARM instruction (just like Thumb) while the more complex ones trap into a software implementation. An equivalent circuit for
handling
Squeak bytecodes would be fantastic.
Well, even the JVM is an Universal Turing machine ;-)
Sure.
I have a Squeak compiler which emits the JVM's bytecodes (into regular class files).
...
Just sufficient support for the compiler compiling itself :)
Very nice. I think there have been other Smalltalks which ran on the JVM. At least I seem to remember something called "Bistro".
Robert Tolksdorf collected an impressive (200 different systems) list of system wich use JVM as is @ - http://www.robert-tolksdorf.de/vmlanguages.html
Now every JVM does dynamic dispatch if the correct opcodes are used (O.K. the bytecode verifier has to be convinced but that is only pro-forma and does not affect the run-time; recently Adrian Kuhn had the same idea how to do this; even GCJ knows how to do this :)
In the case of someone just wanting to use the Jazelle technology for Squeak instead of running it on a regular JVM there is no need to worry about thinking like the bytecode verifier. You can bend the rules as much as you like.
Sure :) The point I meant was just, to convince the verifyer while still debugging and testing on regular JVM platforms. Saves a lot of time and headaches. The first utility I wrote into this direction was for replacing CAST bytecodes by NOOP. Many CASTs are just required by stupid static-minded regular javac / GCC, not by the bytecode verifier nor the JVM ;-)
No "Invokedynamic" is needed (except if that would automagically do boxing/unboxing, then I'd employ "Invokedynamic"). And only field access (instVar, classVar) needs the CAST opcode ;-) Well, I think that especially Jazelle can live without the CAST opcode :)
Probably.
About the Invokedynamic - give how Jazelle works (essentially a bytecode->ARM translation ROM with all the complicated instructions translated to "call xxx") it is probably no more and nor less costly than the other invoke bytecodes. So some optimizations you might need on a normal JVM might not get the same results here.
Of course.
I would like to see this all running on Jazelle but lack the expertise for choosing the right platform for *not* producing an expensive failure. Can you help me with your expertise to choose a Jazelle platform, *that* would be fantastic.
That depends on many details. Since this is very off topic we should move it off squeak-dev.
O.K. can you email items / topics / concerns for starting an off-list discussion, please. Thank you. Even if it'd turn out to be infeasible, I'd like to find out why so. OTHO if it's feasible and not expensive I'd like to create such a system on as common HW+SW platform as possible :)
/Klaus
-- Jecel
squeak-dev@lists.squeakfoundation.org