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