This year's project is about programming the "MCS". MCS stands for Machine Code
Simulator and is an environment for executing MCS programs. The
syntax of an MCS program is very simple, it is a fantasy assembly language for a
fantasy processor (see e.g., V2-24). Its instruction set is
a very reduced mixture of 6502 Assembler and
the so called RedCode.
The
project goal is to write one program ("parser") that translates MCS programs
into machine language, i.e., a sequence of numbers and another program
("processor") that interprets this machine language.
The projects starts on Wednesday, February 19 and ends on Friday, February 28, which is also the last opportunity to get your project result accepted.
The programming task has to be solved in
groups of four to six students. Each group will be
assigned a group tutor. We put registration lists into the pool room (see
below) where you can enroll for a group. The name of the respective tutor and
his/her contact information can be found on the list. Please contact your
tutor as soon as possible, especially if you do not know all your other team
members personally yet. Marcus Lippert will be at the pool room and answer
questions from 9:00 to approximately 10:00, afterwards you can contact him in
his office.
You may work from home but you can also use the pool rooms of the RBG. In particular room A004 in the Wilhelminenstrasse (S4|03) is available from 8:00 to 18:00 throughout the whole project period. At least two tutors will available in this pool for questions during 14:00 to 16:00 for all project days, except the weekend, of course. Additionally we are also hosting a FAQ (list of Frequently Asked Questions), which you may consult in case you encounter difficulties.
The task description defines the minimal requirements for your program to pass (with the grade 4.0) as well as extension levels, which you can earn better grades with. It is a good idea to distribute the work among the group and make a plan by what time you expect to have which functionality in place.
The hand in deadline is Friday, February 28. You have to show the program (both source code and compiled version) as well as the documentation to your tutor, who will be ready to accept your solution from 9:00 to 12:00 and again from 14:00 to 17:00. It is a good idea to fix an appointment so that collisions with other groups can be avoided (especially towards the end of the day). Your tutor will then check the program using predefined (but secret) test cases, check the quality of your program documentation and ask each group member questions regarding the implementation. It is important that all of you know all aspects of the implementation and are able to answer questions. The mark of the project will be combined with the mark of the exam with a weight of 30 to 70 percent.
If you experience any difficulties (organizational and others) do not hesitate to contact us:
The architecture of the simulator to be built
is
quite simple. There are only four main components:
Memory: (code provided by us, including visualisation) The memory component is a block of 1000 consecutive single memory cells. Each memory cell is assigned a unique number, its address (0..999) and each cell is capable of storing a 32-bit integer. We will refer to this very basic data element as a word. Our memory is special in that it "wraps", i.e., the address following 999 is address 0 again. In other words, any memory access (reading or writing) occurs modulo the memory size. The memory component plays a central role in that it is shared by the parser and the processor.
Parser: The parser is responsible for parsing an MCS source code file. It checks the program code for being syntactically correct and translates the assembler source to machine code which it then stores in the memory.
Processor: The processor is responsible for executing machine code instructions. In order to know which instruction to execute next, the cpu keeps track of its program counter, i.e., the address of the instruction to be executed next. For one execution step the processor fetches the next instruction (along with potential operands) performs the necessary action depending on the instruction found, and then increases its program counter accordingly. If a processors encounters a memory cell which does not contain a legal instruction code then the processor will halt. The number of concurrently running programs depends on the number of currently active processors. In the first evolution there is only one program and one processor. In further evolutions it is possible to have two processors or even a dynamic number of processors. All processors are asked to perform one execution step at a time by the simulator one by one.
Simulator: The simulator is the main component since it is responsible for