WinARM – Simulating Advanced RISC Machine Architecture

Shuqiang Zhang

Department of Computer Science Columbia University

New York, NY sz184@columbia.edu

Abstract

This paper discusses the design and imple- mentation of the WinARM, a simulator imple- mented in C for the Advanced RISC Machine (ARM) processor. The intended users of this tool are those individuals interested in learning com- puter architecture, particularly those with an inter- est in the Advanced RISC Machine processor fam- ily.

WinARM facilitates the learning of computer architecture by offering a hands-on approach to those who have no access to the actual hardware. The core of the simulator is implemented in C with and models a fetch-decode-execute paradigm; a Visual Basic GUI is included to give users an in- teractive environment to observe different stages of the simulation process.

1. Introduction:

This paper describes how to simulate an ARM processor using the C programming lan- guage. In the course of this discussion, the reader is introduced to the details of the ARM processor architecture and discovers how the hardware specifications are simulated in software using execution-driven simulation. Execution driven simulation is also know as instruction-level simu- lation, register-cycle simulation or cycle-by-cycle simulation [3]. Instruction level simulation con- sists of fetch, decode and execution phases [4].

ARM processors were first designed and manufactured by Acorn Computer Group in the mid 1980’s [1]. Due to its high performance and power efficiency, ARM processors can be found on wide range of electronic devices, such as Sony Playstation, Nintendo Game Boy Advance and Compaq iPAQs. The 32-bit microprocessor was designed using RISC architecture with data proc- essing operations occurring in registers instead of memory. The processor has 16 visible 32 bit regis- ters and a reduced instruction set that is 32-bits

wide. The details on the registers and instructions can be obtained from the ARM Architectural Ref- erence Manual [2].

2. Related Works:

This section discusses different types of simulators available today and their different ap- proaches in design and implementation. Most simulation tools can be classified as user level simulators: these simulate the execution of a proc- ess and emulate any system calls made on the tar- get computer using the operating system of the host computer [5]. WinARM is an example of this type of simulator; it executes ARM instructions on a host Pentium x86 processor using a fetch-decode-execute paradigm. KScalar Simulator [Moure 6], PPS suite [7], CPU Sim3.1 [8] and OA- Mulator [9] are simulators best suited for educa- tional purposes. They show the basic ideas of com- puter organization with relatively few details and complexity. They are specifically designed for stu- dents who have little or no background in com- puter architecture and who need a simple introduc- tion [6]. WinARM also belongs in this category because it provides a concise and straightforward introduction to the ARM architecture. On the other extreme of the spectrum is the SPARC V9 Com- plete Machine Simulator, one of the many well-know complete machine simulators devel- oped to date. These simulate the target computer from the boot stage, including all codes executed by the PROM, the OS that is loaded by the PROM, and any processes subsequently created [5]. An- other approach to processor simulation can be seen in the Simx86 simulator. The Simx86 abandons the traditional simulator implementation approach of pre-decoding instructions and cross compilation. Instead, Simx86 favors an object oriented ap- proach to improve extensibility of the simulator at the cost of increased execution time. The Simx86 provides a straightforward way to build a simulator for a processor by allowing each component

Figure 1. ARM Architecture

of the processor to be represented directly in the simulator by an object. The simulator can easily be extended by adding new classes of instructions without the daunting task of constructing a new simulator [10]. WinARM, on the other hand, re- tains the traditional approach for building simula- tors, and is composed of fetch, decoding and exe- cution phases [4]. This approach tends to favor execution speed of the simulators [10]. 3. Designing and Building WinARM

The basic approach in designing WinARM is to simulate all the necessary components of the ARM architecture in C code. This includes the register bank, instruction decoder, the 32-bit ALU and all other components. Figure 1 shows a de- tailed view of the major components in the ARM architecture and how they interact with each other.

The sixteen 32-bit user level registers, stack space, and memory of the ARM architecture are all modeled using arrays of unsigned long types. The fetch-decode-execute paradigm of the ARM instruction set is simulated via several C functions

that get passed the 32-bit instructions. The de- code function determines the type of the instruc- tion based on its bit pattern and calls the appropri- ate instruction execution function. See Figure 2 for details on the instruction set of the ARM proc- essor.

The traditional approach of building simula- tors which focuses on pre-decoding instructions to an intermediate representation and cross compila- tion [10] is also used for building the WinARM simulator,. Therefore, a cross compiler is re- quired to generate ARM machine code to run on the host Pentium x86 machine.

Finally, a visual basic GUI is included in the simulator to provide users of WinARM an interac- tive environment to work in. 3.1 Cross Compilation

The idea behind simulation is to be able to ‘execute’ non-native code on a host machine. In order to obtain non-native machine code, a cross compiler is required. Many free versions of the ARM cross compiler are readily available on the

Figure 2. ARM instruction Set

world wide web. The one used for this simulator was created by Jason Wilkins (fenix@ io.com). 3.2 Instruction Fetching

Once ARM machine code has been obtained using a cross compiler, the instruction fetching process begins. The object file generated by the assembler is read 32 bits at a time since all ARM instructions are 32-bits wide. The header and footer sections of the object file, which contains ARM system information, are discarded because they are not used by the simulator. All the fetched instructions are then stored in the Program Memory space, which is modeled by a fixed size array of unsigned long type. After all the instruc- tions are fetched and stored, the Decoding stage

begins. 3.3 Instruction Decoding

All of the ARM instructions are 32-bits wide, with a predefined and distinct bit pattern. Wi- nARM uses these bit patterns to determine the type of the instruction being decoded, and calls ap- propriate execution functions to execute each spe- cific instruction. See figure 2 for the bit patterns of each type of ARM instruction. The decoding process isolates the bit pattern of each incoming instruction and compares it to the set of predefined bit pattern, if there is a match, the instruction is sent to the target Execution function to be exe- cuted.

Figure 3. CPSR Register

Figure 4. Instruction Condition Field

Figure 5. Data Processing Instruction

3.4 Instruction Execution The main working unit of the simulator con-

sists of the execution functions for each different type of ARM instruction. These functions do the actual arithmetic computations, move data be- tween simulated registers and memory, update the CPSR register, and keep track of the program counter and stack pointer.

In addition to the predefined bit pattern of each instruction type, there are many variable bits in each instruction. Depending on the state of these variable bits, each instruction could be exe- cuted in many different ways. For example, a Data Processing Instruction has the ‘I’ bit which determines if the second operand is a register or an immediate value. If the second operand is a reg- ister, the instruction also contains a shift field, which can specify different types of shifts. The shift amount can either be a register or an immedi- ate value. The OpCode field may specify sixteen different kinds of operations the Data Processing instruction may perform. See Figure 5 for details on Data Processing Instructions. Another important aspect of WinARM is the simulation of CPSR (Program Status Register) and the condition flag of each ARM instruction. These two, in combination, determine whether the current decoded instruction should be executed or ignored, which is of utmost importance when run- ning branch instructions. The CPSR register has

a four bit Condition Code that consists of N, Z, C and V flags (see Figure 3). These flags are up- dated and latched each time any instruction is exe- cuted with the S bit field set to 1 [2]. Every ARM instruction contains a Condition field of four bits, but each individual bit of the instruction condition field has no direct correlation with each of the condition flags in the CPSR register. Instead, there are sixteen possible instruction conditions; each condition requires the system to check the state of one or more CPSR condition flags. See Figure 4 for details on each of the condition field requirements. If the requirements were met, the current instruction gets executed, otherwise, it is ignored and the PC (program counter) gets incre- mented by one and points to the next instruction to be executed.

The PC (Program Counter), which is register r15, points to the next ARM instruction to be exe- cuted. The value of the PC can be updated or moved just like any other ARM register, for in- stance, a branch instruction would update the PC with its offset so the execution path can jump to somewhere else in the Program Space. In con- junction with register r14, the link register, the PC can simulate a return from a called function: the old PC value is copied into r14 before branching occurs, upon returning from the called function, the value in r14 is copied back into the PC, so the

Figure 6. WinARM GUI

PC would point to the instruction before the branch occurred. The WinARM stack, similar to the Program Space and memory space, is simu- lated with an array of type unsigned long. There are no pop and push methods implemented explic- itly for the stack. Instead, block data transfer in- structions stm and ldm are used to simulate stack pop and push, which updates register r13, the stack pointer. 3.5 Simulator GUI A WinARM GUI was built using Microsoft Visual Basic, which gives WinARM users a more interac- tive environment to learn about simulators. Users can type in C code in the Enter C Code text area.Upon clicking the execute button, the simula- tor would compile the C code and display the re- sulting ARM assembly code in the ARM Assem- bly Code text area. The machine code generated and the decoded version of the machine code would be displayed in the Machine Code text area and the Decoded Instructions text area respectively. The sixteen user registers would also be updated with their final state. See Figure 6. 4. Future Work

The current version of WinARM has only

simulated the mostly commonly used instruction types, such as Data Processing, Multiply, Single and Block Data Transfer and Branch. More work

will be done to simulate the remaining instruction types. Instruction pipelining also need to be im- plemented along with clock cycles to make the simulator more complete. Currently, WinARM can only handle integer arithmetic, future versions would also to incorporate floating point arithmetic. 5. Conclusion

The WinARM simulator was developed to target audiences interested in learning the inner workings of a processor simulator and to gain some insight into the ARM architecture. Wi- nARM uses a traditional fetch-decode-execute paradigm to execute non-native machine code on a host processor in favor of execution speed [4]. The fetch-decode-execute phases of the simulator were built using C for efficiency reasons, and a GUI built in Microsoft Visual Basic was supplied so users can see the different steps taken in the simulation process and the final state of each regis- ter. References: [1]funkysh, “Into my ARMs”

www.phrack.org/show.php?p=58&a=10 [2] ARM Architectural Reference Manual – Issue

D, 2000 Advanced RISC Machines LTD [3] D. A. Sykes, B.A. Malloy, The Design of an

Efficient Simulator for the Pentium Pro Proc- essor, In Proceedings of the 1996 Winter

Simulation Conference, pp. 840-847, 1996. [4] I. Barbieri, M. Bariani, M. Raggio, A VLIW

Architecture Simulator Innovative Approach for HW-SW Co-Design, 2000 IEEE interna- tional Conference on Multimedia and Expo, Vol. 3. pp1375-1378, 2000.

[5] B. Clarke, A. Czezowski, P. Strazdins, Imple- mentation Aspects of a SPARC V9 Complete Machine Simulator, In Conferences in Re- search in Information Technology, Vol. 4. Australian Computer Society, pp. 23-32, 2001.

[6] J. C. Moure, D. I. Rexachs, E. Luque, The KScalar Simulator, ACM Journal of Educa- tional Resources in Computing, Vol. 2, No. 1, pp. 73-116 March, 2002.

[7] B. K. Gunther, Facilitating Learning in Ad- vanced Computer Architecture through Ap-

propriate Simulation, ACSC 23rd Australasian Computer Science Conference, 2000. pp. 104-112, 1999.

[8] D. Skrien, CPU Sim3.1: A Tool for Simulating Computer Architectures for Computer Or- ganization Classes, ACM Journal of Educa- tional Resources in Computing, Vol. 1, No. 4 , pp. 46-59, December, 2001.

[9] F. Menczer, A. M. Segre, OAMulator: A Teaching Resource to Introduce Computer Ar- chitecture Concepts, Journal of Educational Resources in Computing, Vol. 1, No. 4, pp18-30, December, 2001.

[10] A. R. Shealy, B. A. Malloy, Simx86: An Ex- tensible Simulator for the Intel 80×86 Proces- sor Family, In Proceedings of the 30th Annual Simulation Symposium, pp. 157-166, 1997.