mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-27 04:52:05 +08:00
a687671327
The common sim-profile option controls whether to keep track of runtime execution (like cycle count), so switch the rx-specific cycle-stats option over to that.
122 lines
4.6 KiB
Plaintext
122 lines
4.6 KiB
Plaintext
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-sim-profile (default)
|
|
--disable-sim-profile
|
|
|
|
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.
|