Operating System Design :: Projects :: Virtual Machine Part 2
Problem
You will need to build on your virtual machine from Virtual Machine Part 1. Do not start this project until you have completed that part.
Write a full-scale VM-to-Hack translator, extending the translator developed in Project 7, and conforming to the VM Specification, Part II (Section 8.2) and to the Standard VM-on-Hack Mapping, Part II (Section 8.3.1). Use your VM translator to translate the VM programs supplied below, yielding corresponding programs written in the Hack assembly language. When executed on the supplied CPU Emulator, the translated code generated by your VM translator should deliver the results mandated by the test scripts and compare files supplied below.
The relevant reading for this project is Chapter 8. You will need two tools: the programming language with which you implement your VM translator, and the supplied CPU Emulator. This emulator will allow you to execute, and test, the machine code generated by your VM translator. Another tool that comes handy in this project is the supplied visual VM Emulator. The emulator allows experimenting with a working VM implementation and with the given VM programs before you set out to translate them. For more information about this tool, refer to the supplied VM Emulator Tutorial.
Instructions
Chapters 7 and 8 include a proposed, language-independent VM Translator API, which can serve as your implementation's blueprint.
For each one of the six supplied test programs, follow these steps:
- To get acquainted with the intended behavior of the supplied test program Xxx.vm, run it on the supplied VM Emulator using the supplied XxxVME.tst test script (if the program consists of one ore more files residing in a directory, load the entire directory into the VM Emulator and proceed to execute the code.)
- Use your VM translator to translate the supplied Xxx.vm file, or directory, as needed. The result should be a new text file containing Hack assembly code. The name of this file should be Xxx.asm.
- Inspect the translated Xxx.asm program. If there are visible syntax (or any other) errors, debug and fix your VM translator.
- To check if the translated code performs properly, use the supplied Xxx.tst and Xxx.cmp files to run your translated Xxx.asm program on the supplied CPU Emulator. If there are run-time errors, keep working on yourVM translator.
API: Chapter 8 includes a proposed, language-independent VM Translator API. This API can be the blueprint of your VM Translator implementation.
Implementation order: The supplied test programs were carefully planned to test the specific features of each stage in your VM implementation. Therefore, it's important to implement your VM translator in the proposed order, and to test it using the supplied test programs at each stage. Implementing a later stage before an early one may cause the test programs to fail.
Initialization: In order for any translated VM program to start running, it must include a preamble startup code that forces the VM implementation to start executing it on the host platform. In addition, in order for any VM code to operate properly, the VM implementation must store the base addresses of the virtual memory segments in the correct locations in the host RAM. The first three test programs in this project assume that the startup code was not yet implemented, and include test scripts that effect the necessary initializations "manually". The last two programs assume that the startup code is already part of the VM implementation.
Testing
We recommend completing the implementation of the VM translator in two stages. First, implement and test the translation of the VM language's branching commands, then implement and test the translation of the function call and return commands. This will allow you to unit-test your implementation incrementally, using the test programs supplied below.
Handling programs consisting of more than one file: VM programs are rarely written by humans; they are normally generated by compilers. For example, Java compilers translate Java class files into intermediate VM code known asBytecode. As we will see in the next projects, our Jack compilation model is very similar. A Jack program consists of one or more compilation units, known as classes. Each class is stored in a separate *.jack file, all residing in the same directory - let's call it MyProg. Following compilation, the Jack compiler generates a set of corresponding *.vmfiles, and stores them in the same MyProg directory. At this point the VM Translator enters the picture. If we wish to execute the MyProg code on the Hack platform, we apply the VM Translator to the entire MyProg directory (rather than to the individual *.vm files). The result will be a single, monolithic MyProg.asm file containing the logic of the entire program. Therefore, your VM Translator should be capable of translating both an individual *.vm file as well as a directory containing one or more *.vm files.
