{"id":9912,"date":"2025-11-03T16:06:05","date_gmt":"2025-11-03T13:06:05","guid":{"rendered":"https:\/\/staging.intechcore.com\/?p=9912"},"modified":"2025-12-01T13:44:31","modified_gmt":"2025-12-01T10:44:31","slug":"development-of-an-own-programming-language-in-javaantlr-compiler","status":"publish","type":"post","link":"https:\/\/intechcore.com\/en\/development-of-an-own-programming-language-in-javaantlr-compiler\/","title":{"rendered":"Developing your own programming language in Java+ANTLR: Compiler"},"content":{"rendered":"

This is the third article in the series “Developing your own programming language in Java”. For better understanding, you should read the first<\/a> and second<\/a> articles.<\/p>\n

In this article, we will learn how to compile our programming language (Jimple) to Java bytecode. We will also compare the execution time of Jimple code interpretation (from the first article) and compiled Jimple to Java bytecode.<\/p>\n

Java Bytecode<\/h2>\n

Java bytecode is a set of instructions for the Java Virtual Machine (JVM). Source code written in Java and other JVM-compatible languages is compiled into bytecode. The JVM executes bytecode by converting it to machine code<\/a> that is understandable by a specific platform. However, bytecode is not immediately converted to machine code; it is first interpreted by the JVM. If the JVM detects that code is executed frequently (or for other reasons<\/a>), it can compile it to machine code. This approach is called JIT compilation (Just-In-Time<\/a>). There are also AOT compilers (Ahead-Of-Time<\/a>) that allow application developers to compile programs to machine code before execution. This can improve application startup time and reduce memory usage, which is especially useful for microservices and serverless applications<\/a>.<\/p>\n

Let’s compile the famous “Hello, world!”<\/strong> program in Java and see what its bytecode looks like. For this, we’ll create a file HelloWorld.java<\/em> with the following content:<\/p>\n

public<\/span> class<\/span> HelloWorld<\/span> {
public<\/span> static<\/span> void<\/span> main<\/span>(String<\/span>[]<\/span> args<\/span>) {
System<\/span>.<\/span>out.<\/span>println<\/span>(“<\/span>Hello, <\/span>World!<\/span>“<\/span>);<\/span>
}
}<\/div>\n

Then execute the following command:<\/p>\n

javac<\/span> HelloWorld.java<\/span><\/div>\n

After compilation, a file HelloWorld.class<\/em> containing the bytecode will appear in the current directory. This file is usually smaller than the source code because bytecode is optimized for execution by the Java virtual machine. This file is binary and can be viewed with any hex editor<\/a>.<\/p>\n

\n\"Hex-view\n<\/div>\n

As you can see from the figure, bytecode in this form is difficult for humans to read. For convenient bytecode reading, we can use the special utility javap<\/em>, which is part of the JDK<\/a>. This utility allows you to view the contents of .class<\/em> files in a readable format. Execute the following command:<\/p>\n

javap<\/span> –<\/span>v<\/span> HelloWorld<\/span><\/div>\n

The output will be approximately like this:<\/p>\n

public<\/span> class<\/span> HelloWorld<\/p>\n

minor version: 0
major version: 52
flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
#1 = Methodref #6.#15 \/\/ <\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>Object.”<init>”:()V<\/span>
#2 = Fieldref #16.#17 \/\/ <\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>System.out:Ljava<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream;<\/span>
#3 = String #18 \/\/ <\/span>Hello, <\/span>World!<\/span>
#4 = Methodref #19.#20 \/\/ <\/span>java<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream.println:(Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String;)V<\/span>
#5 = Class #21 \/\/ <\/span>HelloWorld<\/span>
#6 = Class #22 \/\/ <\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>Object<\/span>
#7 = Utf8 <init>
#8 = Utf8 ()V
#9 = Utf8 Code
#10 = Utf8 LineNumberTable
#11 = Utf8 main
#12 = Utf8 ([Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>;)V
#13 = Utf8 SourceFile
#14 = Utf8 HelloWorld.java
#15 = NameAndType #7:<\/span>#8 \/\/ <\/span>“<init>”:()V<\/span>
#16 = Class #23 \/\/ <\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>System<\/span>
#17 = NameAndType #24:<\/span>#25 \/\/ <\/span>out:Ljava<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream;<\/span>
#18 = Utf8 Hello, World!
#19 = Class #26 \/\/ <\/span>java<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream<\/span>
#20 = NameAndType #27:<\/span>#28 \/\/ <\/span>println:(Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String;)V<\/span>
#21 = Utf8 HelloWorld
#22 = Utf8 java<\/span>\/<\/span>lang<\/span>\/<\/span>Object<\/span>
#23 = Utf8 java<\/span>\/<\/span>lang<\/span>\/<\/span>System<\/span>
#24 = Utf8 out
#25 = Utf8 Ljava<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream<\/span>;
#26 = Utf8 java<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream<\/span>
#27 = Utf8 println
#28 = Utf8 (Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>;)V
{
public<\/span> HelloWorld();
descriptor: ()V
flags: ACC_PUBLIC
Code:<\/span>
stack=1, locals=1, args_size=1
0:<\/span> aload_0<\/span>
1:<\/span> invokespecial<\/span> #1 \/\/ <\/span>Method <\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>Object.”<init>”:()V<\/span>
4:<\/span> return<\/span>
LineNumberTable:
line 2:<\/span> 0<\/p>\n

public<\/span> static<\/span> void<\/span> main(java.lang.String[]);
descriptor: ([Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:<\/span>
stack=2, locals=1, args_size=1
0:<\/span> getstatic<\/span> #2 \/\/ <\/span>Field <\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>System.out:Ljava<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream;<\/span>
3:<\/span> ldc<\/span> #3 \/\/ <\/span>String <\/span>Hello, <\/span>World!<\/span>
5:<\/span> invokevirtual<\/span> #4 \/\/ <\/span>Method <\/span>java<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream.println:(Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String;)V<\/span>
8:<\/span> return<\/span>
LineNumberTable:
line 4:<\/span> 0
line 5:<\/span> 8
}<\/div>\n

Even in this form, the bytecode doesn’t look very readable, but you can already see the program structure. For example, we see the symbol table, information about methods and used classes. You can also see that the main<\/em> method gets a reference to the standard output stream System.out<\/em>, then calls the println<\/em> method to output the string “Hello, World!”. Mnemonics (e.g., getstatic, ldc, invokevirtual<\/em>) are symbolic representations of bytecode instructions<\/a> executed by the JVM. We won’t delve deeply into mnemonics, but this is precisely the level of abstraction we’ll work with when compiling Jimple to bytecode.<\/p>\n

JVM Stack Architecture<\/h3>\n

The Java Virtual Machine has a stack-oriented architecture. This means operations are performed on values stored in a stack<\/a>. The virtual machine uses the stack to store operands, local variables, and intermediate computation results. For example, when performing addition of two numbers, both numbers are placed on the stack, then the addition operation is executed, which extracts these two numbers from the stack, adds them, and places the result back on the stack.<\/p>\n

For example, let’s compile a method that adds two integers:<\/p>\n

int<\/span> sum<\/span>(int<\/span> a<\/span>,<\/span> int<\/span> b<\/span>) {
return<\/span> a +<\/span> b;<\/span>
}<\/div>\n

The bytecode for this method will look as follows:<\/p>\n

iload_1<\/span> \/\/<\/span> Load<\/span> the<\/span> first<\/span> int<\/span> argument<\/span> onto<\/span> the<\/span> stack<\/span>
iload_2<\/span> \/\/<\/span> Load<\/span> the<\/span> second<\/span> int<\/span> argument<\/span> onto<\/span> the<\/span> stack<\/span>
iadd<\/span> \/\/<\/span> Extract<\/span> the<\/span> top<\/span> two<\/span> values<\/span> from<\/span> the<\/span> stack,<\/span> add<\/span> them,<\/span> and<\/span> put<\/span> the<\/span> result<\/span> back<\/span> on<\/span> the<\/span> stack<\/span>
ireturn<\/span> \/\/<\/span> The<\/span> top<\/span> stack<\/span> value<\/span> is<\/span> extracted<\/span> and<\/span> returned<\/span> to<\/span> the<\/span> calling<\/span> method<\/span><\/div>\n

However, a single stack is not sufficient for efficient method execution, so the virtual machine uses the concept of frames. A frame is a data structure that contains all the data necessary for executing a specific method, including local variables, operands, and stack state information. Every time a method or constructor is called, a new frame is created and placed on the call stack. When a method completes, its frame is removed from the call stack. The method’s return value is placed on the operand stack of the calling method.<\/p>\n

What to Use for Bytecode Generation?<\/h3>\n

To compile Jimple to Java bytecode, we’ll use the time-tested ASM<\/a> library. It allows working with Java bytecode at a low level and also provides useful tools for validation and analysis of generated code.<\/p>\n

An example of generation for the “Hello, world!” program using ASM might look like this:<\/p>\n

ClassWriter<\/span> cw =<\/span> new<\/span> ClassWriter<\/span>(ClassWriter<\/span>.<\/span>COMPUTE_FRAMES<\/span> |<\/span> ClassWriter<\/span>.<\/span>COMPUTE_MAXS<\/span>);<\/span><\/p>\n

cw.<\/span>visit<\/span>(V17<\/span>,<\/span> ACC_PUBLIC<\/span>,<\/span> “<\/span>HelloWorld<\/span>“<\/span>,<\/span> null<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>Object<\/span>“<\/span>,<\/span> null<\/span>);<\/span><\/p>\n

\/\/<\/span> <\/span>Generate <\/span>default <\/span>constructor<\/span>
MethodVisitor<\/span> mv =<\/span> cw.<\/span>visitMethod<\/span>(ACC_PUBLIC<\/span>,<\/span> “<\/span><<\/span>init><\/span>“<\/span>,<\/span> “<\/span>()V<\/span>“<\/span>,<\/span> null<\/span>,<\/span> null<\/span>);<\/span>
mv.<\/span>visitCode<\/span>();<\/span>
mv.<\/span>visitVarInsn<\/span>(ALOAD<\/span>,<\/span> 0<\/span>);<\/span>
mv.<\/span>visitMethodInsn<\/span>(INVOKESPECIAL<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>Object<\/span>“<\/span>,<\/span> “<\/span><<\/span>init><\/span>“<\/span>,<\/span> “<\/span>()V<\/span>“<\/span>,<\/span> false<\/span>);<\/span>
mv.<\/span>visitInsn<\/span>(RETURN<\/span>);<\/span>
mv.<\/span>visitMaxs<\/span>(0<\/span>,<\/span> 0<\/span>);<\/span>
mv.<\/span>visitEnd<\/span>();<\/span><\/p>\n

\/\/<\/span> <\/span>Generate <\/span>public <\/span>static <\/span>void <\/span>main<\/span>(<\/span>String[] <\/span>args)<\/span>
mv =<\/span> cw.<\/span>visitMethod<\/span>(ACC_PUBLIC<\/span> +<\/span> ACC_STATIC<\/span>,<\/span> “<\/span>main<\/span>“<\/span>,<\/span> “<\/span>([Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String;)V<\/span>“<\/span>,<\/span> null<\/span>,<\/span> null<\/span>);<\/span>
mv.<\/span>visitCode<\/span>();<\/span><\/p>\n

\/\/<\/span> <\/span>System.out<\/span>
mv.<\/span>visitFieldInsn<\/span>(GETSTATIC<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>System<\/span>“<\/span>,<\/span> “<\/span>out<\/span>“<\/span>,<\/span> “<\/span>Ljava<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream;<\/span>“<\/span>);<\/span><\/p>\n

\/\/<\/span> <\/span>“Hello, <\/span>World!” <\/span>string<\/span>
mv.<\/span>visitLdcInsn<\/span>(“<\/span>Hello, <\/span>World!<\/span>“<\/span>);<\/span><\/p>\n

\/\/<\/span> <\/span>println <\/span>call<\/span>
mv.<\/span>visitMethodInsn<\/span>(INVOKEVIRTUAL<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream<\/span>“<\/span>,<\/span> “<\/span>println<\/span>“<\/span>,<\/span> “<\/span>(<\/span>Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String;)V<\/span>“<\/span>,<\/span> false<\/span>);<\/span><\/p>\n

mv.<\/span>visitInsn<\/span>(RETURN<\/span>);<\/span>
mv.<\/span>visitEnd<\/span>();<\/span><\/p>\n

cw.<\/span>visitEnd<\/span>();<\/span><\/p>\n

\/\/<\/span> <\/span>Write <\/span>the <\/span>generated <\/span>class <\/span>to <\/span>a <\/span>file<\/span>
try<\/span> (FileOutputStream<\/span> fos =<\/span> new<\/span> FileOutputStream<\/span>(“<\/span>HelloWorld.class<\/span>“<\/span>)) {
fos.<\/span>write<\/span>(cw.<\/span>toByteArray<\/span>());<\/span>
}<\/div>\n

Starting with JDK 24, you can parse, generate, and transform class files without third-party libraries, as a built-in API has been added that simplifies these operations (JEP 484: Class-File API<\/a>).<\/p>\n

There’s another way to generate bytecode from a new language – first convert Jimple to another language (e.g., Java or Kotlin), then compile it using a standard compiler (e.g., javac<\/em> for Java). This type of compilation is called transpilation<\/a>.<\/p>\n

JimpleBaseVisitor Again<\/h3>\n

To compile Jimple to Java bytecode, we’ll use the already familiar (from the previous two articles) abstract class JimpleBaseVisitor<\/em> (generated by ANTLR). It allows traversing the AST tree (Abstract Syntax Tree<\/a>) and performing actions on each tree node. We’ll override methods for each node type to generate corresponding bytecode.<\/p>\n

We’ll create a new class JimpleCompilerVisitor<\/em> that inherits from JimpleBaseVisitor<\/em> and implements methods for bytecode generation. It’s known that each method of this class must return a value of a specific type. In our case, we’ll return information about the node type in the tree – CompilationInfo<\/em>.<\/p>\n

Why do we need type information? Many bytecode instructions depend on operand types, so we need to know what data type we’re processing at the moment. For example, if we’re processing an integer, we should use instructions for working with integers. Many instructions have prefixes and\/or suffixes indicating the operand types they work with. These include the following:<\/p>\n\n\n\n\n\n\n\n\n
\n

Suffix\/Prefix\u00a0<\/span><\/b><\/p>\n<\/td>\n

\n

Operand Type\u00a0<\/span><\/b><\/p>\n<\/td>\n<\/tr>\n

\n

i\u00a0<\/span><\/p>\n<\/td>\n

\n

integer\u00a0<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

l\u00a0<\/span><\/p>\n<\/td>\n

\n

long\u00a0<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

s\u00a0<\/span><\/p>\n<\/td>\n

\n

short\u00a0<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

b\u00a0<\/span><\/p>\n<\/td>\n

\n

byte\u00a0<\/span><\/p>\n<\/td>\n<\/tr>\n

\n

c\u00a0<\/span><\/p>\n<\/td>\n

\n

character\u00a0<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

Another type-related problem is that in Jimple we don’t use explicit types for function parameters and return values. When I wrote the Jimple interpreter (first article), I identified types during runtime. This was quite easy to implement and the language itself looks simpler. But in a compiler, we must know types in advance to generate correct bytecode (or always return Object). Therefore, we’ll have to compute the function’s return value type based on its body. To identify the type of any expression, a getExpressionType<\/em> method was written with one parameter of type ExpressionContext<\/em> (base class of all expressions).<\/p>\n

Compiler Implementation<\/h3>\n

Since the root rule of our grammar is the program<\/em> rule (see Jimple.g4<\/em> file), code compilation starts with it. For this, we call the visitProgram<\/em> method on the JimpleCompilerVisitor<\/em> object, passing it an object of class ProgramContext<\/em>. After calling this method, all AST nodes will be processed, and we can get the generated bytecode using the getBytecode<\/em> method. The bytecode, which is an array of bytes, can be written to a file and run using the JVM.<\/p>\n

JimpleCompilerVisitor<\/span> visitor =<\/span> new<\/span> JimpleCompilerVisitor<\/span>();<\/span>
visitor.<\/span>visitProgram<\/span>(parser.<\/span>program<\/span>());<\/span>
byte<\/span>[]<\/span> bytecode =<\/span> visitor.<\/span>getBytecode<\/span>();<\/span><\/div>\n

In the visitProgram<\/em> method, the main ClassWriter<\/em> class is created, which will be used for bytecode generation. In this method, we also create a constructor and main<\/em> method. Methods in ASM are created by calling visitMethod<\/em>, which returns an object of type MethodVisitor<\/em>. Using this class, we can generate bytecode for each method. The visitMethod<\/em> method takes parameters: access attributes (e.g., ACC_PUBLIC<\/em>), method name, its descriptor, and others.<\/p>\n

The method descriptor deserves special attention: it defines the parameter types that the method accepts and what type the method returns. Descriptors in the JVM are encoded in a special way. For example, for the main method it looks like “([Ljava\/lang\/String;)V”<\/em>, which can be deciphered as the method takes one argument of type string array – [Ljava\/lang\/String<\/em>; and returns void – V<\/em>. A description of descriptors can be found in the JVM specification<\/a>.<\/p>\n

Since there can be multiple methods calling each other (and even themselves), we use a stack to store all methods, where the “head” of the stack stores the current method. Therefore, to start traversing the entire tree, we need to put the MethodVisitor<\/em> (of the main<\/em> method) on the stack and call the parent implementation visitProgram<\/em> (super.visitProgram(ctx)<\/em>). At the end of the visitProgram<\/em> method, we can get the generated bytecode using the toByteArray<\/em> method on the ClassWriter<\/em> object.<\/p>\n

public<\/span> CompilationInfo<\/span> visitProgram<\/span>(JimpleParser<\/span>.<\/span>ProgramContext<\/span> ctx<\/span>) {
ClassWriter<\/span> cw =<\/span> new<\/span> ClassWriter<\/span>(ClassWriter<\/span>.<\/span>COMPUTE_MAXS<\/span> |<\/span> ClassWriter<\/span>.<\/span>COMPUTE_FRAMES<\/span>);<\/span><\/p>\n

\/\/<\/span> <\/span>create <\/span>the <\/span>class <\/span>with <\/span>name <\/span>“JimpleAutoGenApp”<\/span>
cw.<\/span>visit<\/span>(Opcodes<\/span>.<\/span>V1_8<\/span>,<\/span> Opcodes<\/span>.<\/span>ACC_PUBLIC<\/span>,<\/span> “<\/span>JimpleAutoGenApp<\/span>“<\/span>,<\/span> null<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>Object<\/span>“<\/span>,<\/span> null<\/span>);<\/span><\/p>\n

\/\/<\/span> <\/span>Define <\/span>a <\/span>constructor<\/span>
MethodVisitor<\/span> constructor =<\/span> cw.<\/span>visitMethod<\/span>(Opcodes<\/span>.<\/span>ACC_PUBLIC<\/span>,<\/span> “<\/span><<\/span>init><\/span>“<\/span>,<\/span> “<\/span>()V<\/span>“<\/span>,<\/span> null<\/span>,<\/span> null<\/span>);<\/span>
constructor.<\/span>visitCode<\/span>();<\/span>
constructor.<\/span>visitVarInsn<\/span>(Opcodes<\/span>.<\/span>ALOAD<\/span>,<\/span> 0<\/span>);<\/span>
constructor.<\/span>visitMethodInsn<\/span>(Opcodes<\/span>.<\/span>INVOKESPECIAL<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>Object<\/span>“<\/span>,<\/span> “<\/span><<\/span>init><\/span>“<\/span>,<\/span> “<\/span>()V<\/span>“<\/span>,<\/span> false<\/span>);<\/span>
constructor.<\/span>visitInsn<\/span>(Opcodes<\/span>.<\/span>RETURN<\/span>);<\/span>
constructor.<\/span>visitEnd<\/span>();<\/span><\/p>\n

\/\/<\/span> <\/span>Create <\/span>the <\/span>main <\/span>method<\/span>
MethodVisitor<\/span> mainMethod =<\/span> cw.<\/span>visitMethod<\/span>(Opcodes<\/span>.<\/span>ACC_PUBLIC<\/span> +<\/span> Opcodes<\/span>.<\/span>ACC_STATIC<\/span>,<\/span> “<\/span>main<\/span>“<\/span>,<\/span> “<\/span>([Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String;)V<\/span>“<\/span>,<\/span> null<\/span>,<\/span> null<\/span>);<\/span>
mainMethod.<\/span>visitCode<\/span>();<\/span><\/p>\n

\/\/<\/span> <\/span>set <\/span>mainMethod <\/span>as <\/span>current <\/span>(<\/span>put <\/span>on <\/span>the <\/span>top)<\/span>
methods.<\/span>push<\/span>(mainMethod);<\/span>
super<\/span>.<\/span>visitProgram<\/span>(ctx);<\/span>
methods.<\/span>pop<\/span>();<\/span><\/p>\n

mainMethod.<\/span>visitInsn<\/span>(Opcodes<\/span>.<\/span>RETURN<\/span>);<\/span>
mainMethod.<\/span>visitEnd<\/span>();<\/span><\/p>\n

cw.<\/span>visitEnd<\/span>();<\/span>
this<\/span>.<\/span>bytecode =<\/span> cw.<\/span>toByteArray<\/span>();<\/span><\/p>\n

return<\/span> VOID<\/span>;<\/span>
}<\/div>\n

To ultimately get bytecode, we need to implement all necessary visitXxx<\/em> methods. They will generate corresponding bytecode for each language construct. Let’s consider a simple case when a string is encountered in the program text. In this case, we need to generate an ldc <index><\/em> instruction, where index is the index from the constant pool of the current class. Where do we get it? In ASM library, this is done automatically using the visitLdcInsn<\/em> method. You can pass a string, number, type, etc. as a parameter to this method. In our case, we pass a string. After calling this method, the string will be placed in the class constant pool, and an ldc<\/em> instruction with the corresponding index will be added to the bytecode. At the end of the method, we return information about the node type – CompilationInfo.STRING<\/em>. For other types, similar methods need to be implemented.<\/p>\n

@<\/span>Override<\/span>
public<\/span> CompilationInfo<\/span> visitStringExpr<\/span>(JimpleParser<\/span>.<\/span>StringExprContext<\/span> ctx<\/span>) {
String<\/span> value =<\/span> StringUtil<\/span>.<\/span>cleanStringLiteral<\/span>(ctx.<\/span>STRING_LITERAL<\/span>().<\/span>getText<\/span>());<\/span>
getCurrentMethod<\/span>().<\/span>visitLdcInsn<\/span>(value);<\/span>
return<\/span> CompilationInfo<\/span>.<\/span>STRING<\/span>;<\/span>
}<\/div>\n

A more complex case is arithmetic operations. For example, consider the addition operation. In Jimple, it might look like: a + b<\/em>, where a<\/em> and b<\/em> can be variables or constants. In this case, we need to generate instructions for loading values a<\/em> and b<\/em> onto the stack, then an instruction for adding these values. For this, we call the getExpressionType<\/em> method for each operand to get their types. Then, depending on the operand types, we generate the corresponding addition instruction. For example, if both operands are of type long<\/em>, we generate the ladd<\/em> instruction. If one of the operands is of type double<\/em>, we generate the dadd<\/em> instruction.<\/p>\n

We also need to consider the case when one of the operands is a string. In this case, the + operation should be interpreted as string concatenation. For this, we use the StringBuilder<\/em> class to assemble the resulting string.<\/p>\n

Another important point is type casting. Java has implicit and explicit type casting. In our compiler, we implement implicit type casting to simplify language usage. For example, if one operand is of type long<\/em> and the other is of type double<\/em>, we automatically cast long<\/em> to double<\/em>. For this, we use the convertAfterFirstArg<\/em> and convertAfterSecondArg<\/em> methods, which generate corresponding type casting instructions. The method itself returns information about the resulting type of this expression.<\/p>\n

public<\/span> CompilationInfo<\/span> visitPlusMinusExpr<\/span>(JimpleParser<\/span>.<\/span>PlusMinusExprContext<\/span> ctx<\/span>) {
MethodVisitor<\/span> method =<\/span> getCurrentMethod<\/span>();<\/span>
int<\/span> typeLeft =<\/span> getExpressionType<\/span>(ctx.<\/span>left);<\/span>
int<\/span> typeRight =<\/span> getExpressionType<\/span>(ctx.<\/span>right);<\/span><\/p>\n

\/\/<\/span> <\/span>check <\/span>if <\/span>plus <\/span>is <\/span>string <\/span>concat <\/span>operator<\/span>
if<\/span> (ctx.<\/span>op.<\/span>getType<\/span>() ==<\/span> JimpleParser<\/span>.<\/span>PLUS<\/span> &&<\/span> (isStaticString<\/span>(typeLeft) ||<\/span> isStaticString<\/span>(typeRight))) {
method.<\/span>visitTypeInsn<\/span>(NEW<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder<\/span>“<\/span>);<\/span>
method.<\/span>visitInsn<\/span>(DUP<\/span>);<\/span>
method.<\/span>visitMethodInsn<\/span>(INVOKESPECIAL<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder<\/span>“<\/span>,<\/span> “<\/span><<\/span>init><\/span>“<\/span>,<\/span> “<\/span>()V<\/span>“<\/span>,<\/span> false<\/span>);<\/span>
CompilationInfo<\/span> left =<\/span> visit<\/span>(ctx.<\/span>left);<\/span>
String<\/span> typeDescrLeft =<\/span> makeFuncDescriptor<\/span>(left,<\/span> “<\/span>Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder;<\/span>“<\/span>);<\/span>
method.<\/span>visitMethodInsn<\/span>(INVOKEVIRTUAL<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder<\/span>“<\/span>,<\/span> “<\/span>append<\/span>“<\/span>,<\/span> typeDescrLeft,<\/span> false<\/span>);<\/span>
CompilationInfo<\/span> right =<\/span> visit<\/span>(ctx.<\/span>right);<\/span>
String<\/span> typeDescrRight =<\/span> makeFuncDescriptor<\/span>(right,<\/span> “<\/span>Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder;<\/span>“<\/span>);<\/span>
method.<\/span>visitMethodInsn<\/span>(INVOKEVIRTUAL<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder<\/span>“<\/span>,<\/span> “<\/span>append<\/span>“<\/span>,<\/span> typeDescrRight,<\/span> false<\/span>);<\/span>
method.<\/span>visitMethodInsn<\/span>(INVOKEVIRTUAL<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder<\/span>“<\/span>,<\/span> “<\/span>toString<\/span>“<\/span>,<\/span> “<\/span>()Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String;<\/span>“<\/span>,<\/span> false<\/span>);<\/span>
return<\/span> CompilationInfo<\/span>.<\/span>STRING<\/span>;<\/span>
}<\/p>\n

int<\/span> commonType =<\/span> commonType<\/span>(typeLeft,<\/span> typeRight);<\/span>
switch<\/span> (ctx.<\/span>op.<\/span>getType<\/span>()) {
case<\/span> JimpleParser<\/span>.<\/span>PLUS<\/span>:<\/span>
visit<\/span>(ctx.<\/span>left);<\/span>
convertAfterFirstArg<\/span>(typeLeft,<\/span> typeRight);<\/span>
visit<\/span>(ctx.<\/span>right);<\/span>
convertAfterSecondArg<\/span>(typeLeft,<\/span> typeRight);<\/span>
method.<\/span>visitInsn<\/span>(getAddOpcode<\/span>(commonType));<\/span>
return<\/span> new<\/span> CompilationInfo<\/span>(commonType);<\/span>
case<\/span> JimpleParser<\/span>.<\/span>MINUS<\/span>:<\/span>
visit<\/span>(ctx.<\/span>left);<\/span>
convertAfterFirstArg<\/span>(typeLeft,<\/span> typeRight);<\/span>
visit<\/span>(ctx.<\/span>right);<\/span>
convertAfterSecondArg<\/span>(typeLeft,<\/span> typeRight);<\/span>
method.<\/span>visitInsn<\/span>(getSubOpcode<\/span>(commonType));<\/span>
return<\/span> new<\/span> CompilationInfo<\/span>(commonType);<\/span>
default<\/span>:<\/span>
throw<\/span> new<\/span> UnsupportedOperationException<\/span>(“<\/span>Unsupported <\/span>operator: <\/span>“<\/span> +<\/span> ctx.<\/span>op.<\/span>getText<\/span>());<\/span>
}
}<\/div>\n

Another important but not complex construct to implement is the conditional if<\/em> statement. This statement consists of three parts: condition, if<\/em> body, and optional else<\/em> body. In bytecode, we can implement the if<\/em> statement using conditional and unconditional jump instructions. First, we generate code for evaluating the condition. Then we create two labels: one for jumping to the else<\/em> body and another for exiting the entire if<\/em> statement. If the condition is false, we jump to the labelFalse<\/em> label, otherwise we execute the if<\/em> body. If an else<\/em> body is present, we add an unconditional jump instruction (goto<\/em>) to the exit label after executing the if<\/em> body.<\/p>\n

public<\/span> CompilationInfo<\/span> visitIfStatement<\/span>(JimpleParser<\/span>.<\/span>IfStatementContext<\/span> ctx<\/span>) {
visit<\/span>(ctx.<\/span>expression<\/span>());<\/span><\/p>\n

Label<\/span> labelFalse =<\/span> new<\/span> Label<\/span>();<\/span>
Label<\/span> labelExit =<\/span> new<\/span> Label<\/span>();<\/span>
boolean<\/span> hasElse =<\/span> ctx.<\/span>elseStatement<\/span>() !=<\/span> null<\/span>;<\/span>
\/\/<\/span> <\/span>if <\/span>the <\/span>value <\/span>is <\/span>false, <\/span>then <\/span>go <\/span>to <\/span>the <\/span>else <\/span>statement <\/span>or <\/span>exit <\/span>if <\/span>there <\/span>is <\/span>no <\/span>else<\/span>
MethodVisitor<\/span> method =<\/span> getCurrentMethod<\/span>();<\/span>
method.<\/span>visitJumpInsn<\/span>(IFEQ<\/span>,<\/span> hasElse ?<\/span> labelFalse :<\/span> labelExit);<\/span><\/p>\n

\/\/<\/span> <\/span>true<\/span>
visit<\/span>(ctx.<\/span>statement<\/span>());<\/span><\/p>\n

if<\/span> (hasElse) {
method.<\/span>visitJumpInsn<\/span>(GOTO<\/span>,<\/span> labelExit);<\/span>
\/\/<\/span> <\/span>false<\/span>
method.<\/span>visitLabel<\/span>(labelFalse);<\/span>
visit<\/span>(ctx.<\/span>elseStatement<\/span>());<\/span>
}
method.<\/span>visitLabel<\/span>(labelExit);<\/span><\/p>\n

return<\/span> CompilationInfo<\/span>.<\/span>VOID<\/span>;<\/span>
}<\/div>\n

Monomorphization<\/h3>\n

As mentioned above, Jimple has no explicit types for function parameters and return values. Types are computed during compilation. This in turn allows implementing an interesting capability in the language. Consider the following example:<\/p>\n

fun<\/span> sum<\/span>(a<\/span>,<\/span> b<\/span>) {
return<\/span> a +<\/span> b
}<\/p>\n

println<\/span> sum<\/span>(4,<\/span> 2)
println<\/span> sum<\/span>(“4”,<\/span> “2”)<\/div>\n

In this example, the sum<\/em> function is declared once but called twice: first with two integers, and second with two strings. In Jimple, during the compilation, two versions of the sum<\/em> function will be generated: one for integers and another for strings. This allows using the same code for different data types. This process is called monomorphization<\/a>, and the function is polymorphic<\/a>. In Java, this would have to be implemented by defining multiple methods (see method overloading<\/a>).<\/p>\n

In bytecode, this would look as follows:<\/p>\n

public<\/span> static<\/span> main([Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>;)V
GETSTATIC java<\/span>\/<\/span>lang<\/span>\/<\/span>System<\/span>.out <\/span>: <\/span>Ljava<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream<\/span>;
LDC 4
LDC 2
INVOKESTATIC JimpleAutoGenApp.sum (JJ)J
INVOKEVIRTUAL java<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream<\/span>.println <\/span>(<\/span>J<\/span>)<\/span>V<\/span>
GETSTATIC java<\/span>\/<\/span>lang<\/span>\/<\/span>System<\/span>.out <\/span>: <\/span>Ljava<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream<\/span>;
LDC “<\/span>4<\/span>“<\/span>
LDC “<\/span>2<\/span>“<\/span>
INVOKESTATIC JimpleAutoGenApp.sum (Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>;Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>\ud83d\ude09Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>;
INVOKEVIRTUAL java<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream<\/span>.println <\/span>(<\/span>Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>;)V
RETURN<\/p>\n

private<\/span> static<\/span> sum(JJ)J
LLOAD 0
LLOAD 2
LADD
LRETURN<\/p>\n

private<\/span> static<\/span> sum(Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>;Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>\ud83d\ude09Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>;
NEW java<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder<\/span>
DUP
INVOKESPECIAL java<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder<\/span>.<init> <\/span>()V<\/span>
ALOAD 0
INVOKEVIRTUAL java<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder<\/span>.append <\/span>(<\/span>Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>\ud83d\ude09Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder<\/span>;
ALOAD 1
INVOKEVIRTUAL java<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder<\/span>.append <\/span>(<\/span>Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>\ud83d\ude09Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder<\/span>;
INVOKEVIRTUAL java<\/span>\/<\/span>lang<\/span>\/<\/span>StringBuilder<\/span>.toString <\/span>()Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>;
ARETURN<\/div>\n

Textifier and ASMifier<\/h3>\n

ASM provides two useful classes for textual visualization of bytecode: Textifier<\/em> and ASMifier<\/em>. The first class allows outputting bytecode in text format, similar to javap -v output. The second class allows outputting bytecode as Java code that can be used to generate bytecode using ASM. This is useful for debugging and understanding how to use ASM. Usage example:<\/p>\n

Textifier<\/span>.<\/span>main<\/span>(new<\/span> String<\/span>[]{FooBar<\/span>.<\/span>class<\/span>.<\/span>getName<\/span>()});<\/span>
ASMifier<\/span>.<\/span>main<\/span>(new<\/span> String<\/span>[]{FooBar<\/span>.<\/span>class<\/span>.<\/span>getName<\/span>()});<\/span><\/div>\n

Bytecode Validation<\/h3>\n

Generating bytecode manually, even with a library, is not the most trivial task. It’s easy to make a mistake that leads to incorrect bytecode. The ASM library provides the CheckClassAdapter<\/em> class for validating generated bytecode. This class allows checking bytecode for compliance with some JVM specification rules. If the bytecode is incorrect, an exception with an error description will be thrown. CheckClassAdapter<\/em> can be used both after and during bytecode generation. In the second case, we simply need to wrap ClassWriter<\/em> in CheckClassAdapter<\/em> since the latter also implements the ClassVisitor<\/em> interface.<\/p>\n

Let’s consider the following correct example of bytecode generation using CheckClassAdapter<\/em>:<\/p>\n

ClassWriter<\/span> cw =<\/span> new<\/span> ClassWriter<\/span>(ClassWriter<\/span>.<\/span>COMPUTE_FRAMES<\/span>);<\/span>
CheckClassAdapter<\/span> cv =<\/span> new<\/span> CheckClassAdapter<\/span>(cw);<\/span>
cv.<\/span>visit<\/span>(Opcodes<\/span>.<\/span>V1_8<\/span>,<\/span> ACC_PUBLIC<\/span>,<\/span> CLASS_NAME<\/span>,<\/span> null<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>Object<\/span>“<\/span>,<\/span> null<\/span>);<\/span><\/p>\n

MethodVisitor<\/span> method =<\/span> cv.<\/span>visitMethod<\/span>(ACC_PUBLIC<\/span> +<\/span> ACC_STATIC<\/span>,<\/span> “<\/span>main<\/span>“<\/span>,<\/span> “<\/span>([Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String;)V<\/span>“<\/span>,<\/span> null<\/span>,<\/span> null<\/span>);<\/span>
method.<\/span>visitCode<\/span>();<\/span>
method.<\/span>visitFieldInsn<\/span>(GETSTATIC<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>System<\/span>“<\/span>,<\/span> “<\/span>out<\/span>“<\/span>,<\/span> “<\/span>Ljava<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream;<\/span>“<\/span>);<\/span>
method.<\/span>visitLdcInsn<\/span>(12<\/span>L<\/span>);<\/span>
method.<\/span>visitLdcInsn<\/span>(33<\/span>L<\/span>);<\/span>
method.<\/span>visitMethodInsn<\/span>(INVOKESTATIC<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>lang<\/span>\/<\/span>Math<\/span>“<\/span>,<\/span> “<\/span>max<\/span>“<\/span>,<\/span> “<\/span>(<\/span>JJ<\/span>)<\/span>J<\/span>“<\/span>,<\/span> false<\/span>);<\/span>
method.<\/span>visitMethodInsn<\/span>(INVOKEVIRTUAL<\/span>,<\/span> “<\/span>java<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream<\/span>“<\/span>,<\/span> “<\/span>println<\/span>“<\/span>,<\/span> “<\/span>(<\/span>J<\/span>)<\/span>V<\/span>“<\/span>,<\/span> false<\/span>);<\/span>
method.<\/span>visitInsn<\/span>(RETURN<\/span>);<\/span>
method.<\/span>visitEnd<\/span>();<\/span><\/div>\n

The code is successfully generated and executed. This is equivalent to the following Java code:<\/p>\n

public<\/span> static<\/span> void<\/span> main<\/span>(String<\/span>[]<\/span> args<\/span>) {
System<\/span>.<\/span>out.<\/span>println<\/span>(Math<\/span>.<\/span>max<\/span>(12<\/span>L<\/span>,<\/span> 33<\/span>L<\/span>));<\/span>
}<\/div>\n

However, if we accidentally make a mistake and, for example, write method.visitLdcInsn(“33”)<\/em>; instead of method.visitLdcInsn(33L)<\/em>;, then during bytecode generation an IllegalArgumentException<\/em> will be thrown with an error message:<\/p>\n

java.lang.IllegalArgumentException: Error at instruction 3:<\/span> Argument 2:<\/span> expected J, but found R main([Ljava<\/span>\/<\/span>lang<\/span>\/<\/span>String<\/span>;)V
00000 R : : GETSTATIC java<\/span>\/<\/span>lang<\/span>\/<\/span>System<\/span>.out <\/span>: <\/span>Ljava<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream<\/span>;
00001 R : R : LDC 12
00002 R : R J : LDC “<\/span>33<\/span>“<\/span>
00003 R : R J R : INVOKESTATIC java<\/span>\/<\/span>lang<\/span>\/<\/span>Math<\/span>.max <\/span>(<\/span>JJ<\/span>)<\/span>J<\/span>
00004 ? : INVOKEVIRTUAL java<\/span>\/<\/span>io<\/span>\/<\/span>PrintStream<\/span>.println <\/span>(<\/span>J<\/span>)<\/span>V<\/span>
00005 ? : RETURN<\/div>\n

Just for the sake of curiosity, you could comment out CheckClassAdapter<\/em>. In this case, the bytecode will be successfully generated, but when attempting to execute it, a VerifyError<\/em> exception will occur, as the JVM will detect type mismatch.<\/p>\n

Compilation and Execution<\/h3>\n

For convenient compilation and execution of compiled code, a utility JimpleCompilerCli<\/em> was written that takes a file with Jimple code as input, compiles it to Java bytecode, and saves it as an executable jar file. This utility can be used via jimplec.sh\/jimplec.bat scripts. First, we need to compile the project using Maven:<\/p>\n

mvn<\/span> clean<\/span> package<\/span><\/div>\n

Then, to compile example.jimple<\/em>, execute the following command:<\/p>\n

.<\/span>\/<\/span>jimplec.sh<\/span> example.jimple<\/span>
#<\/span> <\/span>or <\/span>jimplec.bat <\/span>example.jimple <\/span>for <\/span>Windows<\/span><\/div>\n

This command will create a target\/example.jar<\/em> file that can be run using the JVM:<\/p>\n

java<\/span> –<\/span>jar<\/span> target<\/span>\/<\/span>example.jar<\/span><\/div>\n

Performance Comparison<\/h3>\n

To compare the performance of the Jimple interpreter and compiled Jimple to bytecode, we can use the following test example:<\/p>\n

var<\/span> counter =<\/span> 0<\/span>
var<\/span> lastFactorial =<\/span> 0<\/span>
var<\/span> startTime =<\/span> now<\/span>()<\/p>\n

while<\/span>(counter <<\/span> 1000000<\/span>) {
lastFactorial =<\/span> factorial<\/span>(counter %<\/span> 20<\/span> +<\/span> lastFactorial %<\/span> 5<\/span>)
counter =<\/span> counter +<\/span> 1<\/span>
}<\/p>\n

var<\/span> time =<\/span> now<\/span>() –<\/span> startTime
println “<\/span>lastFactorial: <\/span>“<\/span> +<\/span> lastFactorial
println “<\/span>counter: <\/span>“<\/span> +<\/span> counter
println “<\/span>time: <\/span>“<\/span> +<\/span> time<\/p>\n

fun factorial<\/span>(n) {
if<\/span> (n ==<\/span> 0<\/span>) {
return 1<\/span>
}
return n *<\/span> factorial<\/span>(n–<\/span>1<\/span>)
}<\/div>\n

This code calculates the factorial of a number in a loop one million times using a recursive factorial<\/em> function, where the argument of the factorial<\/em> function depends on the previous result. This is done to avoid JIT compiler optimization in the JVM, which might notice that the function is always called with the same arguments and cache the result. In the interpreter, we don’t have such optimization, so the comparison will be fair. This code was run 100 times each in the interpreter and in compiled form. The average execution time looks as follows:<\/p>\n\n\n\n\n
\n

Jimple Interpreter\u00a0<\/span><\/b><\/p>\n<\/td>\n

\n

Compiled Jimple\u00a0<\/span><\/b><\/p>\n<\/td>\n

\n

Difference\u00a0<\/span><\/b><\/p>\n<\/td>\n<\/tr>\n

\n

3466 ms\u00a0<\/span><\/p>\n<\/td>\n

\n

9 ms\u00a0<\/span><\/p>\n<\/td>\n

\n

~385x\u00a0<\/span><\/b><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

As you can see from the table, compiled code executes 385 times faster than interpreted code.<\/strong> Testing was conducted on a machine with Intel Core i9-13900K 3.00 GHz processor and with JVM flag -Xmx500M.<\/p>\n

Bonus: AOT Compilation to Native Code<\/h3>\n

Starting with JDK 9, Oracle provides GraalVM JDK<\/a>, which includes the Native Image<\/a> tool. This tool allows compiling JVM bytecode to machine (native) code. Using this tool can significantly improve application startup time and reduce its size, as native code doesn’t require a JVM to execute. To compile Jimple to native code, we first need to compile it to bytecode (jar file), then use Native Image to create a native executable file. Example compilation command:<\/p>\n

native-image<\/span> –<\/span>jar<\/span> example.jar<\/span><\/div>\n

This command will create an executable file named example<\/em> in Linux (or example.exe<\/em> on Windows) that can be run directly from the command line (without java). By the way, the factorial from the previous example on native code executes on average slightly faster than compiled bytecode – about 7 ms.<\/p>\n

Summary<\/h3>\n

In this article, we examined what Java bytecode is, its stack architecture, and how to generate bytecode from code in our language using the ASM library. At the end of the article, we compared the performance of interpreted code and compiled bytecode, and also looked at the possibility of compiling to native code using GraalVM.<\/p>\n

All the compiler source code can be viewed at this link<\/a>.<\/p>\n

References<\/h3>\n

Testing<\/h3>\n

Back in the first article, a special mini-framework<\/a> was written for testing the Jimple interpreter that allows running chunks of Jimple code and checking the actual program output against the expected output. To test the compiler, we can use the same approach. Instead of running the interpreter, we’ll compile Jimple code to JVM bytecode and run the compiled class directly from the test. The nicest part is that the compiler can be tested on the same test programs as the interpreter.<\/p>\n