The Machine Language of the JVM
Questions and Activities
Sections:
How to look at assembly code
Simple machine
architecture
(at first glance).
Arithmetic
expressions
Putting
integer constants onto the stack
Calculations
How to look at assembly code
-
Set
up the Java environment.
-
Copy and compile it by % javac Demo1.java.Then run the
program
by naming the class file (you don't type the .class suffix: %
java
Demo1.
-
Run the disassembler by % javap -c -v Demo1.java
-
Write a simple for loop to add up the numbers from 1 to 100
and
print out the result. Dissassemble the program and see what
you get. (Note: reading data into a Java program is not a
simple
readln(my_data).
This is due to the i/o objects Java provides.)
Simple Machine
Architecture
-
Most instructions use one byte to refer to a local variable. How
many local varibles can be addressed?
-
But there can be two bytes to refer to a local variable! How many
local variables can there be?
-
Likewise, the index to a constant in the pool is one or two
bytes.
How many constants can there be in a class?
-
Are these reasonable numbers?
-
Visit the Jasmin
site
to see the detailed description of the machine
instructions.
What is the opcode for iadd?
Arithmetic
Expressions
Putting
Integer Constants onto the stack
-
Name some one byte instructions.
-
What is the machine instruction for pushing -1 onto the stack?
-
What is largest integer you can use in bipush? In sipush?
-
Show all the ways (most of them inefficient) you can push the consant 4
onto the stack?
-
Why have many different assembler instructions that can do the same
thing?
-
Besides integers we have floating point numbers which are
also
represented by 32 bits. What do the instructions fconst_2 and
fload_0
and fstore_0 accomplish?
-
Why are there are separate instructions for working with floating point
numbers? Think "safe code".
-
A taste of things to come: Java and the JVM treat floating point
numbers
much differently than integers. For example, if you try x
=
(float)1.0; where x is an integer, will get the message: Incompatible
type
for =. Explicit cast needed to convert float to int.
x = (float) 1.0;
^ (I
typecasted since 1.0 is of type double which is represented
in
64 bits; it adds another level of complexity that I don't yet want to
discuss.)
You can't mix and match unless you tell the compiler that you want
to (by x = (int) 1.0;).
Suppose you wanted to get around this at the JVM level and do the
following
nasty thing:
fconst_1
istore_0 which tries to save 1.0 as an
integer. If you try to execute this (using JDK 1.2) you will get
Exception in thread "main" java.lang.VerifyError: (class: Jas1,
method: main signature: ([Ljava/lang/String;)V) Expecting to find
integer
on stack
What happened? When your code is loaded, the JVM verifier
will
first
check to see if it will behave properly before it executes
it.
And saving a float as an integer is not a good idea.
For those who don't care, you can run the program in Java 1.1 with
the -noverify
option. Then you'll get what you deserve;
I hope you don't have to reboot the computer. This "feature" has
been removed from 1.2 and later versions.
Calculations
-
Suppose the JVM did not have the instruction ineg? How
could
JVM still acomplish this? Then why does this instruction exist?
-
Suppose the JVM did not have the instruction irem? How
could
JVM still acomplish this?
Assume as in Demo1.java,
local
variables x, y, z, u, v, w correspond with 0 - 5. Write
expressions
for the following. You should not yet try to do any "tricks", so
read the expression from left to right.
-
x = y - 100;
-
u -= 10;
-
v = (x + 4)*(y/9 + 11);
-
w = (x << 5) * ( u >> 4);
-
In Java we can define char ch = 'A';. How does the JVM
handle
character data? How does the handle statements like int
x
= ch + 'B' + 1;. To answer this question write a simple Java
program with char declarations. Compile it and then look at
the
assembler code with javap. Note: charcter data is really
Unicode
which is represented as two bytes, but for this example you'll just one
byte.
- Logical instructions. Manipulating the stack
Other sections to follow
© 2000 Carl. E. Bredlau
bredlauc@mail.montclair.edu