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).

> > 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). The run-time is hand-crafted as a very thin layer (currently  
> around SmallIntegers, Characters and Floats and other basic material like  
> ByteArray, OrderedCollection and BytesWriteStream [a companion of  
> aByteArray>>writeStream] and analog to that String and CharsWriteStream,  
> plus FileDirectory and the bit of refactoring done with Magnitude).
> 
> 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".
 
> 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.

> 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.

> 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.

-- Jecel