[Sablevm-bugs] [ sablevm-Bugs-704526 ] bytecode numbering

[SourceForge.net <no...@so...>]

Bugs item #704526, was opened at 2003-03-16 10:29
Message generated for change (Comment added) made by davidbelanger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704526&group_id=5523

Category: Wishlist
Group: SableVM
>Status: Closed
Resolution: None
Priority: 2
Submitted By: Chris Pickett (ihatemcgill)
Assigned to: Etienne M. Gagnon (egagnon)
Summary: bytecode numbering

Initial Comment:
Hi,

The instructions in constants.h correspond to the JVM
spec bytecode numbering up until 201, after which point
all instructions are SableVM-specific instructions.  Is
this ordering used to parse class files?  If so, then
the SableVM-specific instructions should start at 256.
 There are two reasons:

1) Sun may expand the bytecode set in the future, at
which point it will be necessary to renumber things anyway.

2) I would like to use the "impdep1" and possibly
"impdep2" opcodes, which have numbers 254 and 255.  I
want to transform a class file to have impdep1 /
impdep2 opcodes using Soot, and so if this same
ordering is really the ordering used to parse class
files (I think it is), then I need those spots to be free.

Currently, I am redefining PUTFIELD_INT and
PUTFIELD_LONG from 254 and 255 to 333 and 334
respectively, but it is cleaner if everything is
shifted down to start at 256.  If this change is okay,
I can make a patch with the renumbered instructions.

Cheers,
Chris

----------------------------------------------------------------------

>Comment By: David Bélanger (davidbelanger)
Date: 2004-03-27 04:02

Message:
Logged In: YES 
user_id=694080


I will close it then...

David

----------------------------------------------------------------------

Comment By: Chris Pickett (cpickett)
Date: 2004-03-26 19:45

Message:
Logged In: YES 
user_id=715646

Feel free to close this Etienne.

We can't have gap in the instruction constants without
changing the code to initialize the instructions array.  It
doesn't matter:  if Sun introduces new bytecodes, we can
just bump everything up then.

As for what I wanted to do, I took something similar to the
JikesRVM approach and use dummy methods in Spmt.class,
inserted ahead-of-time by a Soot transformer, and turn these
into as many SableVM instructions as I need at runtime (and
the code runs on normal VM's).

----------------------------------------------------------------------

Comment By: Chris Pickett (ihatemcgill)
Date: 2003-03-16 11:54

Message:
Logged In: YES 
user_id=630752


Okay, I can do that.  However, I still think the constants
should be renumbered.

I was going to use impdep1 to fork a speculative thread,
with an address of the bytecode at which to start the execution.

So, if I used attributes, I would pass the locations in the
code array at which to insert SableVM-only bytecodes to the
VM, and then they would get inserted during code
preparation.  This way, there are an unlimited number of
bytecodes I can play with (although I think I only need
two).  I just thought it would be easier to get things
working with the impdep1/impdep2 bytecodes.

----------------------------------------------------------------------

Comment By: Etienne M. Gagnon (egagnon)
Date: 2003-03-16 11:21

Message:
Logged In: YES 
user_id=15365

Be warned that the official SableVM source base will not
deviate from the JVM specification by accepting bytecodes
other than those specified by the JVM specification.

You should consider using attributes, instead, as custom
attributes are supported by the JVM specification, and
probably allow you to achieve your goal of communicating
extra information to the VM.  One big advantage of the
attribute approach is that your class files remain
executable under other JVMs, which is a good thing to detect
any invalid bytecode sequence Soot might generate (by
running the class under a JVM with a bytecode verifier).

Etienne

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704526&group_id=5523