ERRIC Machine Code Simulator

Abstract

The architecture and implementation of the ERRIC instruction code software simulator is presented. The main property of the simulator is providing a tool for developing real ERRIC -based software even before a real ERRIC processor appears, or to develop software without a processor at hand. The overall structure of the software tool is described, and the key data structures and algorithms of the simulator are explained and discussed.

Appendices

Appendix 1: Internal Structure of ERRIC Interpreter and API Description

20.1.1 A.1 The Main Structure

The structure is the primary component of the library , Fig. 20.3: it represents a single CPU running the ERRIC architecture and contains the memory chunk and the registers for the processor:

Fig. 20.3

ERRIC_t structure

Using the structure, the memory of the ERRIC machine can be accessed through word array, and registers via

20.1.2 A.2 Functions, Operators and Instruction Execution

Main functions and simulated operators are not directly bound to a particular instance of ; rather, they operate on the single copy of the structure that is passed to them via parameter. There are also some helper functions, like those that unify similar instructions in one code block to remove redundant code.

All execution functions first call routine, that fetches and decodes instruction pointed to by the PC register. Then, the instruction represented by the structure, Fig. 20.4, format is passed to the function, which executes it using attached operator function.

Fig. 20.4

Instruction routine

Apparently, this structure closely resembles one of the ERRIC instruction, described in specifications.

enumeration type represents instruction format, as described in the ERRIC specification. They are named after their function in mathematical operations. Note that due to 10 format being reserved, only 3 formats are listed (Fig. 20.5).

Fig. 20.5

Format types

20.1.3 A.3 Source Files and Their Contents

describes data types used throughout the ERRIC interpreter.

structure, defined in , represents the ERRIC machine (as explained above). Its main parts are memory, registers, and machine status code.

files describe operators that ERRIC CPU can perform, and their helper functions.

contains mapping from operation instructions to the function that executes given instruction, and also functions to fetch instruction in structure and parse the instruction.

contains helper functions, for example functions that can make memory access easier.

20.1.4 A.4 Executable File Formats

Both formats that are supported for the moment, start with the unsigned 8-bit integer version number and are big-endian (bytes are read from left to right).

Version 0: small and simple, but inflexible. File consists of:

• Version (8-bit unsigned integer), followed by 8-bit padding

• Global/static data length in words (32-bit unsigned integer)

• Global/static data fixed-size section

• Code and code data fixed-size section

In this case, we simply read as many words as specified in Data Length section, and then read the rest as a Code. This method has few possibilities to break, but doesn’t allow the user to place the sections in an arbitrary order while also being poorly adaptable and not allowing additional metadata to be inserted into the file.

File structure example (version 0, Table 20.2).

Table 20.2 File structure example

Please notice that data and code are nonsensical, and are here just for example.

Version 1: more comprehensive and much more flexible version, even allowing for compiler/debug metadata:

• Version number (8-bit unsigned integer), followed by 8-bit padding

• Global/static data start position relative to the beginning of the file in bytes (32-bit unsigned integer)

• Global/static data length in words (32-bit unsigned integer)

• Code start position relative to the beginning of the file in bytes (32-bit unsigned integer)

• Code length in words (32-bit unsigned integer)

• Global/static data fixed-size section, code and code data fixed-size section in any order

This version is very flexible. Sections can be put anywhere and in any order. Additional elements, such as additional headers and meta-information, can be put in empty spaces within the file, allowing for greater flexibility. This version is also a bit more fragile and difficult to understand.

File structure example (version 1, Table 20.3).

Table 20.3 File structure Version 1

Notice that data and code are nonsensical, and are here just for example.

Appendix 2: Practical Introduction and Developer’s Guide

The following part will describe how to use the interpreter library for those who wish to use it in their projects.

The interpreter library consists of a structure representing a single CPU running the ERRIC architecture, as well as a number of functions that statelessly operate on an instance of the function.

This allows the library to be flexible and to support different execution methods, such as multiprocessor hardware setups. The structure of the library is implemented in a way that makes easily understanding and use by all kinds of users: for those who want to simply use the interpreter and for those who want to call individual functions for specific purposes.

In order to use all of the main features of the emulator, the header file needs to be included. Files allow the user to call particular functions manually.

Initialization

In order to work with the library , an structure is required. The creation of the structure instance can be done in two ways:

• 1. By the call The function creates the structure with the default memory size of 65536 words, or

• 2. By the call . The function allows the user to specify the size of the memory needed.

The memory size is defined only during the creation and is not changeable while using the library . This was done to make sure that the hardware can be properly simulated, since the software might behave differently under different memory sizes, Fig. 20.6.

Fig. 20.6

The memory size structure

Freeing

After completing working with the particular instance of the structure, the memory taken by it should be freed by using the (Fig. 20.7).

Fig. 20.7

The memory release

Memory setup

After the structure for the processor has been created, its memory should be filled with needed data and code, which can be done either by loading a file with

or by setting it up manually, Fig. 20.8.

Fig. 20.8

The memory setup

Function will automatically detect and load file version specified within the file.

The only way to set the memory up by hand is to directly modify the memory and register arrays—refer to the reference for the ERRIC hardware documentation to determine the needed registers and instruction codes.

Execution

The library offers 2 functions to execute the code— and Fig. 20.9. The function executes the instruction pointed to by the Program Counter register and directly returns the status code returned by the instruction. The function executes instructions one-by-one, starting from PC until it encounters any erroneous status code. The final status code can be accessed by field.

Fig. 20.9

Execution struct