|
Perfect bytecode? In what sense? Speed? CodeSize? Usually jikes produces smaller code than javac. Anyway, it might get something of a nightmare to maintain code that you've hand-shrink using an assembler. And that assembly doesn't look anywhere as "user friendly" as assembly for other processors do. Also, something must be missing from it. I can't see how assembling it would produce a program equivalent to the program produced by compiling the java source file... -- PEZ |
|
Perfect bytecode? In what sense? Speed? CodeSize? Usually jikes produces smaller code than javac. Anyway, it might get something of a nightmare to maintain code that you've hand-shrink using an assembler. And that assembly doesn't look anywhere as "user friendly" as assembly for other processors do. Also, something must be missing from it. I can't see how assembling it would produce a program equivalent to the program produced by compiling the java source file... -- PEZ Speed, CodeSize, file size, everything you want the way you want, but only if it can be done better in assembly. For example multiply(double first, double second) {can't be done more efficient (besides that x*y is more efficient than multiply(x, y)). Java works with a stack which works a bit like Forth. You can 'push' things on the stack and 'pop' them off. If you want to substract an int from another, first push the 2 ints on the stack and then use isub (no need for parentheses to get the right order!). The two input values are then popped off, and the result pushed on the stack. You can duplicate the top item with dup, pop it off, swap the two top items, etc. If you call a method (which is done by first pushing the object on the stack, then calling the method), the top items are used as arguments (number of items depends on method). Complex function calls are really easy that way: first push the object, then do everything to get the first argument, leave it on the stack, get the second argument, etc, and finally call the method. Looks like this (I put the stack contents between parentheses): (stack is empty) push object you want to call (object) push 100 (object 100) duplicate (object 100 100) push 50 (object 100 100 50) subtract (object 100 50) divide (object 2) duplicate (object 2 2) push some object (object 2 2 otherobject) get some field of that object which currently contains 4 (object 2 2 4) multiply (object 2 8) call method which takes 2 ints, so the 3rd from top element is the object that is called (resultvalue) pop (empty) And then all you did is gone. ;-) Note that you can't use the first argument's value in the second in the Java language (or you need to get it again). Do you now see how it can be equivelant, and better? About this: 33: invokevirtual #6; //Method? java/lang/StringBuffer?.append:(Ljava/lang/String?;)Ljava/lang/StringBuffer?; I think the names are stored somewhere at the beginning of the file with an ID, and called by that ID to save space when used more than once (and it is of course faster). What you see above is first a label, then the instruction name, then that ID, and then a comment by the disassembler that the object StringBuffer? is called with method append (#6) which takes a String and returns a StringBuffer?. I'm sure many (if many?) Java assemblers take a name, not necessarily the ID. Btw, don't get me wrong. The language makes large projects much more maintainable. If you can easily follow assembler code (remember that you can indent it, and can use any labels you want), or you want to try it, or are very limited in size/speed (NanoBots!), it is useful. -- Jonathan |
![[Home]](/images/RoboWiki.png)