8sa1-binutils-gdb/sim
Mike Frysinger 54780889e9 sim: h8300: drop separate eightbit memory buffer
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.
2021-01-13 21:54:00 -05:00
..
aarch64 sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
arm sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
avr sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
bfin sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
bpf sim: call SIM_AC_OPTION_WARNINGS(no) in remaining ports 2021-01-11 09:13:11 -05:00
common sim: watch: add basic default handler that traps 2021-01-13 21:53:11 -05:00
cr16 sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
cris sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
d10v sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
erc32 sim: call SIM_AC_OPTION_WARNINGS(no) in remaining ports 2021-01-11 09:13:11 -05:00
frv sim: call SIM_AC_OPTION_WARNINGS(no) in remaining ports 2021-01-11 09:13:11 -05:00
ft32 sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
h8300 sim: h8300: drop separate eightbit memory buffer 2021-01-13 21:54:00 -05:00
igen sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
iq2000 sim: call SIM_AC_OPTION_WARNINGS(no) in remaining ports 2021-01-11 09:13:11 -05:00
lm32 sim: call SIM_AC_OPTION_WARNINGS(no) in remaining ports 2021-01-11 09:13:11 -05:00
m32c sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
m32r sim: call SIM_AC_OPTION_WARNINGS(no) in remaining ports 2021-01-11 09:13:11 -05:00
m68hc11 sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
mcore sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
microblaze sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
mips sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
mn10300 sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
moxie sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
msp430 sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
or1k sim: or1k: fix mixing of code & decl warning 2021-01-12 04:15:28 -05:00
ppc sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
pru sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
rl78 sim: call SIM_AC_OPTION_WARNINGS(no) in remaining ports 2021-01-11 09:13:11 -05:00
rx sim: call SIM_AC_OPTION_WARNINGS(no) in remaining ports 2021-01-11 09:13:11 -05:00
sh sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
testsuite sim: tests: get common tests working again 2021-01-11 18:30:06 -05:00
v850 sim: clean up C11 header includes 2021-01-11 08:05:54 -05:00
.gitignore sim: drop common/cconfig.h in favor of a single config.h 2016-01-09 03:52:30 -05:00
ChangeLog sim: README-HACKING: clean up stale run references 2021-01-12 04:13:11 -05:00
configure sim: sh64: delete port 2021-01-09 09:29:17 -05:00
configure.ac sim: better handle builds of primary targets lacking sims 2020-09-03 18:21:20 +02:00
configure.tgt sim: sh64: delete port 2021-01-09 09:29:17 -05:00
MAINTAINERS sim: sh64: delete port 2021-01-09 09:29:17 -05:00
Makefile.in Update copyright year range in all GDB files 2021-01-01 12:12:21 +04:00
README-HACKING sim: README-HACKING: clean up stale run references 2021-01-12 04:13:11 -05:00