Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due

CSCI 2122 Assignment 4

Objectives

In this assignment you will implement a CPU simulator for a simple instruction set (much simpler than x86). This assignment is divided into several parts to make it simpler. In the first part, you will implement the memory part of the simulator and loader, which loads the code from a file into the simulated memory.

In the second part, you will implement the fetch-decode-execute part of the CPU. 

Preparation:

Inside the repository there are two directories: xsim1 and xsim2, where code is to be written. You should set up a separate CLion project for each of these directories, like the labs. Inside each directory is a tests directory that contains tests that will be executed each time you submit your code. Please do not modify the tests directory or the .gitlab-ci.yml file that is found in the root directory. Mod ifying these files may break the tests. These files will be replaced with originals when the assignments are graded. You are provided with sample Makefile files that can be used to build your program. If you are using CLion, a Makefile will be generated from the CMakeLists.txt file generated by CLion.

Background:

The X Architecture comprises a 64KB (65536 bytes) memory space with addresses ranging from 0 to 65535, and a CPU with 16 general purpose 16-bit registers (r0 . . . r15 ). The CPU is a 16-bit CPU, meaning that the word size is 16-bits (2 bytes). Thus, nearly all operations operate on 16-bit chunks of data, i.e., in this case one word is 16 bits. Thus, all values and addresses are 16 bits in size. All 16-bit values are also encoded in big-endian format, meaning that the most-significant byte comes first.

Apart from the 16 general purpose registers, the CPU has two special 16-bit registers: a program counter (PC), which stores the address of the next instruction that will be executed, and the status (F), which stores bit-flags representing the state of the CPU. The status register contains two flags. The least significant bit is the condition flag, which represents the truth value of the last logical test operation. The bit is set to true if the condition was true, and to false otherwise. The second least significant bit indicates whether the debug mode is on or off. If the debug mode is on, then after each instruction is executed, the CPU simulator prints out the state of all its registers (using the provided function).

Additionally, the CPU uses the last general-purpose register, r15, to store the pointer to the program stack. This register is incremented by two when an item is popped off the stack and decremented by two when an item is pushed on the stack.

The size of the program stack is specified by the code being executed. The program stack is used to store temporary values, arguments to a function, and the return address of a function call.

The CPU takes one clock tick to execute a Fetch, Decode, Execute cycle for any instruction:

The X Instruction Set

All but the extended instructions are encoded as a single word (16 bits). The extended instructions are also one word but are followed by an additional one-word operand. Thus, if the instruction is an extended instruction, the PC needs an additional increment 2 during the instruction’s execution. As mentioned previously, most instructions are encoded as a single word. The most significant two bits of the word indicates whether the instruction is a 0-operand instruction (00), a 1-operand instruction (01), a 2-operand instruction (10), or an extended instruction (11). For a 0-operand instruction, the encoding is 

where the two most significant bits are 00 and the next six bits represent the instruction identifier. The second byte of the instruction is 0.

For a 1-operand instruction, the encoding is

For a 2-operand instruction, the encoding is

where the two most significant bits are 10, and the next six bits represent the instruction identifier. The second byte encodes the two register operands in two four-bit chunks. Each of the 4-bit chunks identifies one of the 16 registers (0 … 15).

where the two most significant bits are 11, the next bit indicates whether a second register operand is used, and the next five bits represent the instruction identifier. If the third most significant bit is 0, then the instruction only uses the one-word immediate operand that follows the instruction. Otherwise, if the third most significant bit is 1, then the four most significant bits of the second byte encode (1 … 15) the register that is the second operand of the instruction.

The instruction set is described in Tables 1, 2, 3, and 4. Each description includes the mnemonic (and syntax), the encoding of the instruction, the instruction’s description and function. For example, the add, loadi, and push instructions have the following descriptions:

Second, the loadi instruction is an extended instruction that takes a 16-bit immediate and stores it in a register. Hence, the the first two bits are 11, the register bit is set to 1, and the instruction identifier is 00001. Hence, the first byte is encoded as 0xE1.

Third, the push instruction is a 1-operand instruction, taking a single register operand. Hence, the first two bits are 01, the immediate bit is 0, and the instruction identifier is 00011. Hence, the first byte is encoded as 0x43.

Note that S and D are 4-bit vectors representing S and D.

Table 1: 0-Operand Instructions

Note that in the case of extended instructions, the label L or value V are encoded as a single word (16-bit value) following the word containing the instruction. The 0 in the encodings above represents a 4-bit 0 vector.

Table 2: 1-Operand Instructions

An Assembler for this Instruction Set

The X Memory Specification

The X Simulator Specification

An execution of the program takes place by repeatedly calling the CPU execution function, which fetches, decodes, and executes the next instruction pointed to by the PC. The execution proceeds for a specified number of ticks or until the program halts the CPU. A program halts the CPU when it executes an illegal instruction, such as the opcode 0. When this happens, the simulator exits.

Your task will be to implement the X Simulator and the X-CPU, which is used to execute programs as sembled with the provided assembler.

Task 1: Implement the main() for the Simulator

Your first task is to implement the main() function of the X Simulator in the xsim1 directory of your repo. The source file main.c should contain the main() function. The simulator should do the following:

1. Take two (2) arguments on the command line: The first parameter is a nonnegative integer denoting the maximum number of cycles that a program should run for, and the remaining argument is the object/executable file of the program to run. For example, the invocation ./xsim 1000 hello.xo instructs the simulator to load the program hello.xo and run the program for at most 1000 cycles. If 0 cycles is specified this is interpreted as an infinite number of cycles. I.e., the program should never run out of cycles.
2. Allocate or instantiate an xcpu structure (defined in xcpu.h).
3. Initialize the X Memory module by calling xmem_init(65536) (defined in xmem.c), thus al locating a 64KB memory space.
4. Load the program into memory from the file specified on the command-line. The program should be loaded starting at the start of the memory space (address 0) using the xmem_store() function, declared in xmem.h. The program will need to open, read, and close the file.
5. Initialize the xcpu structure.
6. Execute the loaded program for the specified number of cycles or until the program halts. Your code should use a loop and call the xcpu_execute() function (declared in xcpu.h) that you will implement in the next part of this assignment. For Task 1, an implementation in xcpu.o is provided.
7. Terminate the simulator once the program halts or runs out of cycles.

Note: the sample solution is less than 80 lines of code. (But there is no limit on the length.) J

Input

Processing

The last part of the simulation involves calling the xcpu_execute() function, in a loop. Each call exe cutes one instruction. This function returns 1 on success and 0 on failure. The loop should continue until the specified number of instructions have been executed, or until the function returns 0. This function is implemented in xcpu.o and will be the focus of the next part of the assignment.

Recommendation: While no error checking is required, it may be helpful to still do error checking, e.g., make sure files are properly opened because it will help with debugging as well.

Output

There is no required output for this part of the assignment. The provided code will do the output.

Task 2: Implement xcpu_execute()

Your second task is to implement the X-CPU in the file xcpu.c. in the xsim2 directory of your repo.

First, copy the main.c from xsim1 to xsim2. You are now to implement the function: extern int xcpu_execute( xcpu *c );

typedef struct xcpu_context {

which stores the context of a program. The structure is defined in xcpu.h and contains CPU registers.

The function should

Note: the sample solution is less than 200 lines of code. The opcodes for all the instructions can be found in xis.h, so you should not need to do a lot of work to get this working.

Input

Processing

For the out instruction (see Table 4), output the lower byte of the operand using the standard library function putchar().

Output

Hints and Suggestions

Assignment Submission

Submission and testing are done using Git, Gitlab, and Gitlab CI/CD. You can submit as many times as you wish, up to the deadline. Every time a submission occurs, functional tests are executed, and you can view the results of the tests. To submit use the same procedure as Assignment 0.

Grading

The assignment will be graded based on three criteria:

Functionality: “Does it work according to specifications?”. This is determined in an automated fashion by running your program on several inputs and ensuring that the outputs match the expected outputs. The score is determined based on the number of tests that your program passes. So, if your program passes t/T tests, you will receive that proportion of the marks.

Quality of Solution: “Is it a good solution?” This considers whether the approach and algorithm in your solution is correct. This is determined by visual inspection of the code. It is possible to get a good grade on this part even if you have bugs that cause your code to fail some of the tests.

Code Clarity: “Is it well written?” This considers whether the solution is properly formatted, well docu mented, and follows coding style guidelines. A single overall mark will be assigned for clarity. Please see the Style Guide in the Assignment section of the course in Brightspace.

The following grading scheme will be used:

Assignment Testing without Submission

Get your program ready to run

1. SSH into the remote server and be sure you are in the marsdec1 or marsdecx directory.

2. Be sure the program is compiled by running make.

1. Run your program on the remote server as described in the CLion tutorials.

2. Open a remote host terminal via Tools → Open Remote Host Terminal

1. Run your program on the remote server as described in VSCode tutorials.

2. Click on the Terminal pane in the bottom half of the window or via Terminal → New Terminal

Run the script

You will see the test run in the terminal window.

The X Assembler (xas)

1. Anything to the right of a # mark, including the #, is considered a comment and ignored.
2. Blank lines are ignored.
3. Each line in the assembly file that is not blank must contains a directive, a label and/or an instruction. If the line contains both a label and an instruction, the label must come first.
4. A label is of the form identifier: where identifier consists of any sequence of letters (A-Za-z), digits (0-9), or underscores ( ) as long the first character is not a digit. A colon (:) must terminate the label. A label represents the corre sponding location in the program and may be used to jump to that particular location in the code.
5. An instruction consists of a mnemonic, such as add, loadi, push, etc, followed by zero or more operands. The operand must be separated from the mnemonic by one or more white spaces. Multiple operands are separated by a comma.
6. If an operand is a register, then it must be in the form r# where # ranges between 0 and 15 inclu sively. E.g., r13. 
7. If the instruction is an immediate, then the argument may either be a label, or an integer. Note: labels are case-sensitive. If a label is specified, no colon should follow the label.
8. Directives instruct the assembler to perform a specific function or behave in a specific manner. All directives begin with a period and are followed by a keyword. There are three directives: .lit eral, .words and .glob, each of which takes an operand.

(a) The .literal directive encodes a null terminated string or an integer at the present location in the program. E.g., 

mystring:

.literal "Hello World!"

myvalue:

.literal 42

encodes a nil-terminated string followed by a 16-bit (1 word) value representing the dec imal value 42. In this example, there are labels preceding each of the encodings so that it is easy to access these literals. That is, the label mystring represents the address (relative to the start of the program) where the string is encoded, and the label myvalue repre sents the address (relative to the start of the program) of the value. This is used in the hello.xas example.

(b) The .words directive sets aside a specified number of words of memory at the present location in the program. E.g.,

myspace:

.words 6

allocates 6 words of memory at the present point in the program. This space is not initialized to any specific value. Just as before, the label preceding the directive repre-sents the address of the first word, relative to the start of the program. This is used in xrt0.xas to set aside space for the program stack.

(c) The .glob directive exports the specified symbol (label) if it is defined in the file, and imports the specified symbol (label) if it is used but not defined in the file. E.g.,

.glob foo

.glob bar

...

loadi bar, r0

...

foo:

.literal "Hello World!"

declares two symbols (labels) foo and bar. Symbol foo is declared in this file, so it will be exported (can be accessed) in other files. The latter symbol, bar, is used but not defined. When this file is linked, the linker looks for the symbol (label) definition in other files makes all references to the symbol refer to where it is defined.

There are several example assembly files provided (ending in .xas).s You can assemble them by invoking the assembler, for example:

./xas example.xas example.xo