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

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

Bugs item #704526, was opened at 2003-03-16 10:29
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105523&aid=704526&group_id=5523

>Category: Whishlist
>Group: SableVM
Status: Open
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: 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