mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-27 04:52:05 +08:00
The RX simulator offers two rx-specific configure options: --enable-cycle-accurate (default) --disable-cycle-accurate If enabled, the simulator will keep track of how many cycles each instruction takes. While not 100% accurate, it is very close, including modelling fetch stalls and register latency. --enable-cycle-stats (default) --disable-cycle-stats If enabled, specifying "-v" twice on the simulator command line causes the simulator to print statistics on how much time was used by each type of opcode, and what pairs of opcodes tend to happen most frequently, as well as how many times various pipeline stalls happened. The RX simulator offers many command line options: -v - verbose output. This prints some information about where the program is being loaded and its starting address, as well as information about how much memory was used and how many instructions were executed during the run. If specified twice, pipeline and cycle information are added to the report. -d - disassemble output. Each instruction executed is printed. -t - trace output. Causes a *lot* of printed information about what every instruction is doing, from math results down to register changes. --ignore-* --warn-* --error-* The RX simulator can detect certain types of memory corruption, and either ignore them, warn the user about them, or error and exit. Note that valid GCC code may trigger some of these, for example, writing a bitfield involves reading the existing value, which may not have been set yet. The options for * are: null-deref - memory access to address zero. You must modify your linker script to avoid putting anything at location zero, of course. unwritten-pages - attempts to read a page of memory (see below) before it is written. This is much faster than the next option. unwritten-bytes - attempts to read individual bytes before they're written. corrupt-stack - On return from a subroutine, the memory location where $pc was stored is checked to see if anything other than $pc had been written to it most recently. -i -w -e - these three options change the settings for all of the above. For example, "-i" tells the simulator to ignore all memory corruption. -E - end of options. Any remaining options (after the program name) are considered to be options for the simulated program, although such functionality is not supported. The RX simulator simulates a small number of peripherals, mostly in order to provide I/O capabilities for testing and such. The supported peripherals, and their limitations, are documented here. Memory Memory for the simulator is stored in a hierarchical tree, much like the i386's page directory and page tables. The simulator can allocate memory to individual pages as needed, allowing the simulated program to act as if it had a full 4 Gb of RAM at its disposal, without actually allocating more memory from the host operating system than the simulated program actually uses. Note that for each page of memory, there's a corresponding page of memory *types* (for tracking memory corruption). Memory is initially filled with all zeros. GPIO Port A PA.DR is configured as an output-only port (regardless of PA.DDR). When written to, a row of colored @ and * symbols are printed, reflecting a row of eight LEDs being either on or off. GPIO Port B PB.DR controls the pipeline statistics. Writing a 0 to PB.DR disables statistics gathering. Writing a non-0 to PB.DR resets all counters and enables (even if already enabled) statistics gathering. The simulator starts with statistics enabled, so writing to PB.DR is not needed if you want statistics on the entire program's run. SCI4 SCI4.TDR is connected to the simulator's stdout. Any byte written to SCI4.TDR is written to stdout. If the simulated program writes the bytes 3, 3, and N in sequence, the simulator exits with an exit value of N. SCI4.SSR always returns "transmitter empty". TPU1.TCNT TPU2.TCNT TPU1 and TPU2 are configured as a chained 32-bit counter which counts machine cycles. It always runs at "ICLK speed", regardless of the clock control settings. Writing to either of these 16-bit registers zeros the counter, regardless of the value written. Reading from these registers returns the elapsed cycle count, with TPU1 holding the most significant word and TPU2 holding the least significant word. Note that, much like the hardware, these values may (TPU2.CNT *will*) change between reads, so you must read TPU1.CNT, then TPU2.CNT, and then TPU1.CNT again, and only trust the values if both reads of TPU1.CNT were the same.