Some words about Cibyl (MIPS to Java bytecode binary translation)

[John Rose]

On Mar 16, 2008, at 11:56 AM, Simon Kagstrom wrote:

> ...in crash dumps or profilers. From benchmarks I've made, the Cibyl
> approach also seems easier to achive good performance with, mostly
> because it always uses Java local variables for the MIPS register
> representation throughout.

By the same token, there would be benefits to raising C structs
where possible into Java objects.  (It probably requires user advice,
as I noted before.)  The int-array memory model would be used
only for "hard cases".  I think there is probably some analysis
that could be made, supported by user annotations, that for most
C programs, would allow a majority of the data structures to go
into real Java objects.  The nested VM could keep a type profile
at every indirection operation to direct its translation of base+offset
to fields.

> * The 64KB method size limit, which is perhaps the largest issue. If
>   the bytecode had not had this limitation, the translation would be
>   done to a single method, which would improve performance and  
> simplify
>   the implementation quite a bit. Cibyl also allows co-locating
>   multiple C functions in a single Java method, which can improve
>   performance quite a bit.

This is an interesting problem.  It would be a good MLVM project.
The messy part is finding all the structs with 16-bit offsets and making
32-bit versions available.  It's so messy, I think, that people have
wanted to wait for a major format revision.  (I think basing offsets
on the Pack200 UNSIGNED5 format would make for a better
revolutionary change, better than adding 32-bit twin structures.
Regarding Twins--suddenly I think of DeVito and Schwarzenegger.)

> * Untyped memory, which I also saw you took up. In Cibyl, I've used a
>   big int-array as the "memory" representation. This fits MIPS quite
>   well, since unaligned memory access is limited to special
>   instructions, and most accesses tend to be 32-bit accesses. However,
>   when 8- or 16-bit loads and stores are done there is a significant
>   performance hit because of this.
Yes, that is a nice fit.  It's an amazing application of a (very)  
RISC ISA,
to an execution platform realized in software not silicon.

Best,
-- John