Missed PUG monthly meeting, exploring Java byte code and BCEL

I missed yesterday's Python User Group Singapore monthly meeting. I had to finish certain document before leaving office yesterday, I couldn't make it.

Last night I was exploring this Byte Code Engineering Library (BCEL) from Apache. This library gives us a way to analyse, create and manipulate binary Java class file. This library has been used by a lot of Java frameworks and containers, as those frameworks need to add some instrumentation when deploying those components in those frameworks and/or containers.

Well, this is considered an advanced thing in Java. Java classes are stored as Java byte codes. When you compile a Java source code, you will have .class file which is a Java byte code file. Java byte code is a form of machine instruction (in this case Java Virtual Machine or JVM). So it's executable binaries for JVM. Java byte code also have opcode like assembly language.

There are 2 type of instruction sets:

1. stack machine
2. register machine

Stack machine operates on stack. Operands are the stack only. The first programmable scientific calculators released by Hewlett-Packard are stack machines (http://www.hpmuseum.org/). They operate in a Reverse Polish Notation. I remembered that my first one of my first Java programming assignment was to implement GUI application for a Reverse Polish Notation calculator. My Dad has his own story of owning one of these calculators and he used to be very proud of the magnetic stripe stored Moon Lander game. It's just a number only Moon Lander, but it's a game running on programmable HP calculator!

Other sample of stack machines that most of us still use is the Intel x86 math coprocessor instructions set. It uses registers that are organised as stack, which will rotate back when overflowing the boundary (of 8 registers).

Stack machines, because it's only operate on stack and usually only the last few data in stack, may have shorter instruction bits. Unlike register machines which usually take some of the bits to specify from which and which register the data is from, and to which register the result goes, stack machines enjoy the benefit of default operands, that is top 1 or top 2 of the stack. The result is always in the stack.

I think one of the main considerations why JVM uses stack machine is to pack as few numbers of bits in the opcode. As most JVM runs as virtual machine, there will be no performance advantages of having a lot of register which anyway stored in RAM by the virtual machines.

Ok, enough for the stack machine, now back to the BCEL it's exciting to touch back the assembly language, byte code, opcode, operand, and stuffs if you are really into  it. I try to code a bit and will share the code later.