Skip to content

static-code-generators/armsimc

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

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.

Hacking

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

Shell:

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

Simulator:

  • 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

Workflow

  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

Maintainers

shell/sim: darkapex verilog: kharghoshal

About

Simulating a subset of ARM in C

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 4

  •  
  •  
  •  
  •