1The RX simulator offers two rx-specific configure options: 2 3--enable-cycle-accurate (default) 4--disable-cycle-accurate 5 6If enabled, the simulator will keep track of how many cycles each 7instruction takes. While not 100% accurate, it is very close, 8including modelling fetch stalls and register latency. 9 10--enable-cycle-stats (default) 11--disable-cycle-stats 12 13If enabled, specifying "-v" twice on the simulator command line causes 14the simulator to print statistics on how much time was used by each 15type of opcode, and what pairs of opcodes tend to happen most 16frequently, as well as how many times various pipeline stalls 17happened. 18 19 20 21The RX simulator offers many command line options: 22 23-v - verbose output. This prints some information about where the 24program is being loaded and its starting address, as well as 25information about how much memory was used and how many instructions 26were executed during the run. If specified twice, pipeline and cycle 27information are added to the report. 28 29-d - disassemble output. Each instruction executed is printed. 30 31-t - trace output. Causes a *lot* of printed information about what 32 every instruction is doing, from math results down to register 33 changes. 34 35--ignore-* 36--warn-* 37--error-* 38 39 The RX simulator can detect certain types of memory corruption, and 40 either ignore them, warn the user about them, or error and exit. 41 Note that valid GCC code may trigger some of these, for example, 42 writing a bitfield involves reading the existing value, which may 43 not have been set yet. The options for * are: 44 45 null-deref - memory access to address zero. You must modify your 46 linker script to avoid putting anything at location zero, of 47 course. 48 49 unwritten-pages - attempts to read a page of memory (see below) 50 before it is written. This is much faster than the next option. 51 52 unwritten-bytes - attempts to read individual bytes before they're 53 written. 54 55 corrupt-stack - On return from a subroutine, the memory location 56 where $pc was stored is checked to see if anything other than 57 $pc had been written to it most recently. 58 59-i -w -e - these three options change the settings for all of the 60 above. For example, "-i" tells the simulator to ignore all memory 61 corruption. 62 63-E - end of options. Any remaining options (after the program name) 64 are considered to be options for the simulated program, although 65 such functionality is not supported. 66 67 68 69The RX simulator simulates a small number of peripherals, mostly in 70order to provide I/O capabilities for testing and such. The supported 71peripherals, and their limitations, are documented here. 72 73Memory 74 75Memory for the simulator is stored in a hierarchical tree, much like 76the i386's page directory and page tables. The simulator can allocate 77memory to individual pages as needed, allowing the simulated program 78to act as if it had a full 4 Gb of RAM at its disposal, without 79actually allocating more memory from the host operating system than 80the simulated program actually uses. Note that for each page of 81memory, there's a corresponding page of memory *types* (for tracking 82memory corruption). Memory is initially filled with all zeros. 83 84GPIO Port A 85 86PA.DR is configured as an output-only port (regardless of PA.DDR). 87When written to, a row of colored @ and * symbols are printed, 88reflecting a row of eight LEDs being either on or off. 89 90GPIO Port B 91 92PB.DR controls the pipeline statistics. Writing a 0 to PB.DR disables 93statistics gathering. Writing a non-0 to PB.DR resets all counters 94and enables (even if already enabled) statistics gathering. The 95simulator starts with statistics enabled, so writing to PB.DR is not 96needed if you want statistics on the entire program's run. 97 98SCI4 99 100SCI4.TDR is connected to the simulator's stdout. Any byte written to 101SCI4.TDR is written to stdout. If the simulated program writes the 102bytes 3, 3, and N in sequence, the simulator exits with an exit value 103of N. 104 105SCI4.SSR always returns "transmitter empty". 106 107 108TPU1.TCNT 109TPU2.TCNT 110 111TPU1 and TPU2 are configured as a chained 32-bit counter which counts 112machine cycles. It always runs at "ICLK speed", regardless of the 113clock control settings. Writing to either of these 16-bit registers 114zeros the counter, regardless of the value written. Reading from 115these registers returns the elapsed cycle count, with TPU1 holding the 116most significant word and TPU2 holding the least significant word. 117 118Note that, much like the hardware, these values may (TPU2.CNT *will*) 119change between reads, so you must read TPU1.CNT, then TPU2.CNT, and 120then TPU1.CNT again, and only trust the values if both reads of 121TPU1.CNT were the same. 122