Michael J. Mahon wrote:
Oliver Schmidt wrote:Hi Michael,Writing a Java interpreter in 6502 assembly would most probably bring Java close to the p-machine.IIRC, the p-machine has single-byte operations that push common constants and designate parameters, for example, without an additional operand byte. These coding cases were chosen to minimize code size in a way that few bytecodes attempt.You're surely right that this is something not done with Java byte code. But my statement above was targeted towards performance and not code density.And code density is the point I was addressing, contrasted with the relatively "looser" Java bytecode.
Java bytecodes: iconst_m1 02 → -1 loads the int value -1 onto the stack iconst_0 03 → 0 loads the int value 0 onto the stack iconst_1 04 → 1 loads the int value 1 onto the stack iconst_2 05 → 2 loads the int value 2 onto the stack iconst_3 06 → 3 loads the int value 3 onto the stack iconst_4 07 → 4 loads the int value 4 onto the stack iconst_5 08 → 5 loads the int value 5 onto the stack from http://en.wikipedia.org/wiki/Java_bytecode and http://java.sun.com/docs/books/jvms/second_edition/html/Mnemonics.doc.html Here is the best p-code description I could find. http://homepages.cwi.nl/~steven/pascal/book/10pcode.htmlThe JVM looks to have been created with a pretty reasonable attempt to keep code density small. There are both 16 bit and 32 bit address/offset version of the opcodes. Honestly, I never looked too much into the JVM, but it looks like a viable platform for a 6502. The bigger question remains as to the quality of the Java compilers, but I think Oliver is on to something here.
I presume that it doesn't really "decompile", but simply throws away the compiled code and reverts to the still available bytecode representation.You're presumption is correct for sure.This is actually a quite venerable technique, known as "throwaway compiling", and was originally part of a strategy in which compiled code was kept in a size-limited buffer, and the least-recently-used parts were simply thrown away when newer code needed to be generated. So the compiled code was managed just like a page working set, or a code cache.This seems to decribe the same approach I described - or do I miss the point here ?I agree--and I was pointing out that the practice is over 30 years old, dating back to the very beginnings of time-sharing and interactive computing. Novelty is hard to come by in this field. ;-) Many recent "discoveries" in computing are simply re-discoveries by folks who either forgot about the past or never bothered to learn it.
One interesting application of compiling a opcode comes from the original Windows EGA/VGA driver. A ROP3 code describes a bitwise combination of source, pattern, and destination. All 256 combinations would have overwhelmed the computers of the time, so a routine was compiled on the fly to implement the ROP3. Nobody was sure why you needed a ROP3, but in typical MS fashion, it was 1 better than the ROP2 used in other windowing systems of time. I think they're up to ROP11 now (with apologies to Spinal Tap).
Dave...