Carmel Interpreter

Welcome to the home page for the Carmel Interpreter. Carmel is a textual representation of Java Card Virtual Machine class files. Java Card is a subset of Java designed for use on smart cards.

Running the interpreter

The interpreter is a Java Web Start application. You must download and install Web Start if you have not already done so. Java Web Start is included with the runtime and development versions of Java starting with version 1.4. Once it is installed, you can run the intepreter.

A sample file is available to test the interpreter. It should appear as the initial value of the "Load File..." dialog box. Alternatively, you can save it to disk and browse for it. You can run the program by browsing to the method "p.C2.run" and clicking "Run Method...". This is the example program given in Renaud Marlet's syntax document.

Troubleshooting

If you are having problems, make sure that your browser is correctly configured to work with Java Web Start. The browser must recognise files ending with .jnlp as being of the MIME type application/x-java-jnlp-file, and launch them with the javaws executable, located in the directory where Web Start was installed. For further information, see the Web Start installation guide.

If you are still having problems, or are running on a platform not supported by Java Web Start, you can download and run the interpreter as a normal Java application. Use the command "java -jar interpreter.jar" or "javaw -jar interpreter.jar" under Windows.

If you are still having problems (!) please let me know.

Feedback

Please report any bugs you may find. All comments are very much welcome, just send me a mail.

Documents

Project report (English): view as HTML or PDF, or download the Word & Visio originals.

Project presentation (French): view as HTML or download Powerpoint & Visio originals.

Source code: download the JAR archive. You will need the Java SDK 1.3 or greater, and JavaCC 2.1 to build the application.

Introduction

About me

My name is Luke Jackson and I am studying in the Department of Computing at Imperial College, London. My degree is MEng Computing (European Programme) and I am currently studying abroad at ENSIMAG, in Grenoble, France. I can be contacted by e-mail.

The interpreter

The interpreter is the subject of my final year project which is entitled "A Web-based Carmel Interpreter", and is supervised by Steffen van Bakel. It is being developed alongside the SecSafe project. The aim of the project is to write a program that can be launched from the web that models a Java Card virtual machine, which takes Carmel programs as its input, based on a modified version of the syntax defined by Renaud Marlet, and interprets them according to the operational semantics defined by Igor Siveroni and Chris Hankin. It is possible to run the program over the web.

Description

Technologies used

The program is implemented in Java, and requires Java 1.3 or later. There is no platform specific code in the program, and hence it can be run on any platform that supports Java. However, it has only been tested under Windows.

The GUI is implemented in Swing, a rich set of graphical components designed around the model-view-controller design pattern, which makes them well suited to displaying the internal state of the virtual machine.

The parser is generated from a grammar definition file using the JavaCC tool, jointly developed by Sun and WebGain.

The ability to launch the program from the web is provided by Java Web Start technology. This allows Java programs to be installed with one click from a web page, and ensures that the user is always running the latest version, checking for updates before each time it is run.

Input files

Each package of a Carmel program is defined in a separate file whose name is the last component of the package name followed by the .cml extension. This file is placed in a subdirectory called "carmel" of the directory specified by replacing each "." in the package name with a path separator (e.g. "/"). For example, the java.lang package is defined by the file java/lang/carmel/lang.cml. The unnamed package can be found in the file carmel/null.cml.

The interpreter uses the Java system class loader to load Carmel packages, and hence uses the CLASSPATH environment variable as a search path. An added advantage of using the Java class loader is that Carmel package files can be stored within JAR and ZIP files.

As a convenience to developers, it is possible to bypass this search process and load Carmel files directly. Such files can contain multiple package definitions.

Parsing, Linking and Verification

The program parses a Carmel program and verifies that it conforms to the Carmel syntax. An abstract syntax tree is built, which is then linked, resolving references to classes, methods, fields and instructions. References to classes not defined within the same file are loaded by the class loader.

During this process, the program verifies the program. The majority of the verifications specified in the Java Virtual Machine Specification (§4.9) and the Java Language Specification are carried out. Examples of such tests are verifying class and class member accessibility, ensuring that methods are overridden with the same return type and equivalent or stronger access modifiers, that there are no cycles in the abstract syntax tree, for example a class or interface which is a superclass or superinterface of itself. A notable exception is that type checking is not performed at link time, but dynamically.

Execution

If the program and all of its referenced packages are parsed, linked and verified successfully, execution can begin. The entry point of a program is a either a static method that takes no parameters, a default constructor, or an instance method takes no parameters. Executing an instance method requires selecting a class instance on the heap on which to invoke the method. There in no constraint on method return type.

The interpreter models the following elements of the virtual machine state:

Execution takes place in a separate thread which can be paused before the execution of any instruction. It is possible to step through a program, stepping into, over and out of method invocations. It is also possible to define custom classes which pause execution when the virtual machine state satisfies a user defined condition.

Graphical User Interface

This section is slightly out of date, and will be updated shortly.

Loading packages

To load a package, either click "Load Package..." and specify the package name, or click "Load File..." and browse for the Carmel file. Please note that there is a bug, in that in order for the program to find Carmel files in the classpath, the program must be run as an application, and the CLASSPATH environment variable configured before execution. Alternatively, you can put all the packages required by a program into one file, and load this using "Load File...".

Correcting errors

If there is an error in parsing or linking a file, the user is shown the following window, which shows the location and reason for the error and, providing the source file is not read-only, allows the user to correct the error.

Interpreting

The main window shows the state of the virtual machine:

The window shows the contents of the heap, the loaded classes and their static fields value, and the call stack. Selecting an entry on the heap displays either the field values of the class instance or the element values of an array. Selecting a method call from the call stack displays the corresponding operand stack and local variable array, along with the next instruction highlighted in the source file in which the method was declared.

To launch a static method, constructor or instance method, select it from the "Loaded Classes" tree. If you are executing an instance method, select the class instance on which to invoke the method from the heap. Methods with parameters are not supported. Once the method and class instance, if applicable, is selected, click the "Run Method" button.

There are three step operations: step into will execute the highlighted instruction, pausing before the first instruction of a method invocation, step over will execute the highlighted instruction, not stepping through the instructions of a method invocation, and step out will execute the remainder of the instructions in the current method and will pause at the instruction following the instruction which invoked it. Halt stops execution immediately.

Method return

There are three ways in which a program can finish executing:

  1. The method can return normally. In this case the user is told the resulting value, if any, and can then inspect the contents of the heap and the values of the static fields.
  2. The method can throw an exception. In this case the user is told the class of the exception, and the window shows the state of the machine just before the execution of the instruction which caused the exception to be thrown.
  3. An instruction can perform an operation that would have caused it to fail verification. As not all verification tests have been implemented at compile-time, they are checked instead at run-time. The tests which are deferred are those which require a flow analysis of each method and generally involve type safety (such as passing a value of the wrong type as a parameter), or maintaining the integrity of the operand stack and local variable array (such as breaking apart a double-word integer on the operand stack). The user is told the reason for the error, and the window shows the state of the machine just before the execution of the instruction which caused the error.

Conclusion

The interpreter is a web-based graphical tool for executing programs written in Carmel, which models the call stack, heap and static field values. Due to time constraints, it does not execute Java Card applets, but would provide a solid basis for the implementation of such a program. The program is written in Java and has been designed so that it can be easily extended as necessary.

back to top