The h8300 sim has its own implementation for memory handling that I'd
like to replace with the common sim memory code. However, it's got a
weird bit of code it calls "eightbit mem" that makes this not as easy
as it would otherwise be. The code has this comment:
/* These define the size of main memory for the simulator.
Note the size of main memory for the H8/300H is only 256k. Keeping it
small makes the simulator run much faster and consume less memory.
The linker knows about the limited size of the simulator's main memory
on the H8/300H (via the h8300h.sc linker script). So if you change
H8300H_MSIZE, be sure to fix the linker script too.
Also note that there's a separate "eightbit" area aside from main
memory. For simplicity, the simulator assumes any data memory reference
outside of main memory refers to the eightbit area (in theory, this
can only happen when simulating H8/300H programs). We make no attempt
to catch overlapping addresses, wrapped addresses, etc etc. */
I've read the H8/300 Programming Manual and the H8/300H Software Manual
and can't find documentation on it. The closest I can find is the bits
about the exception vectors, but that sounds like a convention where the
first 256 bytes of memory are used for a special purpose. The sim will
actually allocate a sep memory buffer of 256 bytes and you address it by
accessing anywhere outside of main memory. e.g. I would expect code to
access it like:
uint32_t *data = (void *)0;
data[0] = reset_exception_vector;
not like the sim expects like:
uint8_t *data = (void *)0x1000000;
data[0] = ...;
The gcc manual has an "eightbit_data" attribute:
Use this attribute on the H8/300, H8/300H, and H8S to indicate that
the specified variable should be placed into the eight-bit data
section. The compiler generates more efficient code for certain
operations on data in the eight-bit data area. Note the eight-bit
data area is limited to 256 bytes of data.
And the gcc code implies that it's accessed via special addressing:
eightbit_data: This variable lives in the 8-bit data area and can
be referenced with 8-bit absolute memory addresses.
I'm fairly certain these are referring to the 8-bit addressing modes
that allow access to 0xff00 - 0xffff with only an 8-bit immediate.
They aren't completely separate address spaces which this eightbit
memory buffer occupies.
But the sim doesn't access its eightbit memory based on specific insns,
it does it purely on the addresses requested.
Unfortunately, much of this code was authored by Michael Snyder, so I
can't ask him :(. I asked Renesas support and they didn't know:
https://renesasrulz.com/the_vault/f/archive-forum/6952/question-about-eightbit-memory
So I've come to the conclusion that this was a little sim-specific hack
done for <some convenience> and has no relation to real hardware. And
as such, let's drop it until someone notices and can provide a reason
for why we need to support it.
This is in preparation for converting h8300 over to the common memory
framework. It's not clear how much of a speed gain this was providing
in the first place -- a naive test of ~400k insns (using shlr.s) shows
that this code actually slowed things down a bit.
If anyone really cares about h8300 anymore, they can migrate to the
common insn caching logic.
Since every target typedefs this the same way, move it to the common code.
We have to leave Blackfin behind here for now because of inter-dependencies
on types and headers: sim-base.h includes sim-model.h which needs types in
machs.h which needs types in bfim-sim.h which needs SIM_CPU.
Almost every target defines sim_cia the same way -- either using the
address_word type directly, or a type of equivalent size. The only
odd one out is sh64 (who has 32bit address_word and 64bit cia), and
even that case doesn't seem to make sense. We'll put off clean up
though of sh64 and at least set up a sensible default for everyone.
The CIA_{GET,SET} macros serve the same function as CPU_PC_{GET,SET}
except the latter adds a layer of indirection via the sim state. This
lets models set up different functions at runtime and doesn't reach so
directly into the arch-specific cpu state.
It also doesn't make sense to have two sets of macros that do exactly
the same thing, so lets standardize on the one that gets us more.
Now that all the targets are utilizing CPU_PC_{FETCH,STORE}, and the
cpu state is multicore, and the STATE_CPU defines match, we can move
it all to the common code.
This sets up the sim_state structure and the cpu member to match what we
do in most other sims, and what the common code suggests. This is a step
to unifying on the sim-cpu.o object.
* wrapper.c: Include config.h before system header files.
* callback.c: Include config.h before system header files.
* cgen-trace.c: Likewise.
* cgen-utils.c: Likewise.
* gentmap.c: Likewise.
* sim-if.c: Include config.h before system header files.
* compile.c: Include config.h before system header files.
* sim-main.h: Likewise.
* gdb-if.c: Include config.h before system header files.
* load.c: Likewise.
* syscalls.c: Likewise.
* trace.c: Likewise.
* interp.c: Include config.h before system header files.
