That's 9 bytes in total.
Wouldn't that leave 10 & 30720 on the operand stack, rather than 640 & 480 ?
You're still right though, regarding sipush being much more efficient in that case.
However, it does get a little more complex - as it depends what you are doing with the constants,
as to what datatype & associated push instruction javac will use in the generated bytecode.
Take this common call for example:
javac will store 640 as a 8 byte value (because the parameter type is long) in the constants pool, and use ldc or ldc_w to retrieve it.
jasmin can help significiantly in this case:
Personally I don't think the semantics of java bytecode realy allow for much optimisation beyond what is expressable in the java syntax.
Therefore I don't think jasmin will be able to help very much - except for allowing you to hand-craft peep-hole optimisations.
But then, if you are only going to use it for making peep-hole optimisations, I think it'd be much more productive to automate them as part of the proguard optimisation/obfuscation step.
That way we can all benefit from them too
Thinking back, there was one other instance being able to mangle the bytecode helped me...
During the initialisation stage, I recall I was accessing the same object several times in succession - calling different methods on it. (Frame & GraphicsDevice instances I believe)
Anyhow, as the methods being invoked were void, I determined that it was safe to pull the Frame/GraphicsDevice reference onto the stack just once, and dup it for each future invocation that was going to be made.
This replaced a load of 2 byte 'aload x' instructions with 1 byte dup's.
However, this again is a peep-hole optimisation that I believe could be added to proguard without too much trouble.