Simulating a subset of ARM in C
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.

ARM Simulator in C

Resources: 18-447 CMU Introduction to Computer Architecture Labs

Shell Instructions

The purpose of the shell is to provide the user with commands to control the execution of the simulator. The shell accepts one or more program files as command line arguments and loads them into the memory image. In order to extract information from the simulator, a file named dumpsim will be created to hold information requested from the simulator. The shell supports the following commands:

  1. r or run: simulate the program until it indicates that the simulator should halt. (As we define below, this is when a SWI instruction is executed with a value of 0x0A.)
  2. file <hexfile>: load this file in program memory.
  3. step [i]: execute one instruction (or optionally i)
  4. mdump 0x<low> 0x<high> [dumpfile]: dump the contents of memory, from location low to location high to the screen or to the dump file [dumpfile].
  5. rdump [dumpfile]: dump the current instruction count, the contents of R0 – R14, R15 (PC), and the CPSR to the screen or to the file [dumpfile].
  6. set r<n> 0x<reg_val>: set general purpose register reg r_n to value reg_val.
  7. ? or help: print out a list of all shell commands.
  8. q or quit: quit the shell.


The project is organized into two major components: Shell and Simulator


  • armsh.c - Executable entry point, parses stdin and calls shell command handlers
  • shellcmds.c - Executes shell commands, calling appropriate routines in Simulator (sim.c)


  • sim.c - CPU/Memory datapath and organization; routines to execute shell commands
  • isa.c - Executes each instruction; routines to decode and handle instructions
  • isa_helper.c - Helper routines for instruction-handlers


  1. Small feature gets assigned to a person after group meeting
  2. The person implements it in a separate branch and then sends PR to master
  3. The PR needs review by maintainer of module within 12hrs, and if okayed by them, can be merged into master
  4. If no reply on PR till 12hrs hours by maintainer, anyone can review it, and if no reply till 24hrs more, it can be merged into master
  5. PR should have no merge conflicts, it's responsibility of the PR-sender to keep their branch updated to master


shell/sim: darkapex verilog: kharghoshal