Re: implementation dependent bytecodes

[Johannes Henkel <jhenkel@jhenkel.de>]

On Sunday 16 March 2003 08:13 pm, Ondrej Lhotak wrote:
> Soot doesn't output bytecode. Soot outputs Jasmin, which is an
> assembly-like representation of bytecode. So, you would have to modify
> Jasmin, not Soot, to output any non-standard bytecodes. Depending on
> how complicated your insertion code is, if you wanted to insert things
> at the Jimple or Baf level instead of in Jasmin (which is essentially
> bytecode, only human-readable), you would have to add the corresponding
> instructions to those IRs, and any code manipulating those IRs (ie. for
> Jimple, that's most of Soot).
>
> I agree with Etienne: attributes are way easier, and they won't break
> your code on other VMs. But again, if your instructions do something
> that will break the code if it's not done, then attributes won't help
> make your code work on other VMs.

Actually, there is a more 'elegant' way to do this:

As part of your input, just define a class SpecialClass with a static method 
specialMethod. The body of specialMethod is empty, but your VM will do 
something special when it encounters a call to it (for example, flush the 
cache of your processor or do something else that you can't do in Java). This 
means your bytecode can be verified and maybe even executed by any VM and you 
don't have to modify any other part of your infrastructure than the parts 
that generate these calls and the part which interprets these special calls. 
(you may have to make sure that soot doesn't 'optimize' these calls away, 
though.) 

This is the way the jikesrvm folks 
(http://oss.software.ibm.com/developerworks/oss/jikesrvm/) do it in their 
VM_Magic class 
(http://www-124.ibm.com/developerworks/oss/jikesrvm/api/com/ibm/JikesRVM/VM_Magic.html).
-- 
Sincerely,

Johannes