h8300 sim: what is "eightbit" memory ?

h8300 sim: what is "eightbit" memory ?

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]

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 doesn't have a lot to say:
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.

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 :(.  does anyone familiar with the H8/300 have a clue as
to what's going on with this code ?
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: h8300 sim: what is "eightbit" memory ?

[ISHIKAWA,chiaki]

Hi,

Sorry for top-posting, but doesn't this "eightbit mem" refer to area
that is accessible with 8-bit offset?
I think I worked with H8/240H or some such CPU and not sure if H8/300H
has similar architecture.

(And my expperience is 10-year old one, ...)

On 2016/08/17 11:26, Mike Frysinger wrote:
> 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 doesn't have a lot to say:
> 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.
>
> 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 :(.  does anyone familiar with the H8/300 have a clue as
> to what's going on with this code ?
> -mike
>

Re: h8300 sim: what is "eightbit" memory ?

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]

On 17 Aug 2016 14:18, ISHIKAWA,chiaki wrote:
> Sorry for top-posting, but doesn't this "eightbit mem" refer to area
> that is accessible with 8-bit offset?
> I think I worked with H8/240H or some such CPU and not sure if H8/300H
> has similar architecture.

that is what it sounds like from gcc's pov.  but that description makes
it sound like the first 256 bytes of memory are accessible regardless of
addressing mode (e.g. you could use an 8-bit address, or 16-bit with the
H8/300, or 24-bit with the H8/300H).  the sim implements it not as the
same piece of memory, but an actual different address space.

so this is the memory map the sim presents:
0x0000 0000...0x00FF FFFF   16MiB of external memory
0x0010 0000...0x0100 00FF   the eightbit memory

and actually, all addresses beyond 0x100000 are masked into the eightbit
mem by doing (addr & 0xff), but that's more of a design choice rather
than the sim trying to represent the hardware accurately.

i'm trying to figure out how the hardware is supposed to behave so i
can accurately adjust the sim to match.  if eightbit is just an address
mode, that's dirt simple to handle -- a (void *)0 will go to the same
memory location regardless of the addr mode used by an insn.  but it
isn't what the sim is doing today :(.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: h8300 sim: what is "eightbit" memory ?

[duane]

mike>> if eightbit is just an address mode, that's dirt simple to handle
mike>> a (void *)0 will go to the same memory location regardless of the

mike>> addr mode used by an insn. but it isn't what the sim is doing
today :(.

If I remember correctly, the arm simulator does various calculations and
pipeline tracking.
It's been a while, but it was doing this in the giant instruction switch
statement.

I've not read or looked at the H8 simulator does the H8 simulator sort
of "count instruction/clock time" - based on memory accesses?

The old 6502 had a very similar zero page feature (first 256 bytes) -
aka: a zero page instructions.

Accessing zero page using a zero page instruction required 3 clocks
(aka: the first 256 bytes)
Accessing absolute required 4 clocks, but you *CAN* access zero page in
absolute mode if you choose
This was useful when I wrote bit-bang uart simulation code (ie: Tight SW
loop - to emulate a uart via GPIO pin)

Thus - from a logical view the "memory is just memory" end of story.

if this is not evident in the simulation code, this might have been a
planned feature that never materialized or was never finished.

this wiki page talks about it:

https://en.wikipedia.org/wiki/Zero_page

Re: h8300 sim: what is "eightbit" memory ?

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

On 17 Aug 2016 11:35, duane@duaneellis.com wrote:
> mike>> if eightbit is just an address mode, that's dirt simple to handle
> mike>> a (void *)0 will go to the same memory location regardless of the
> 
> mike>> addr mode used by an insn. but it isn't what the sim is doing
> today :(.
> 
> If I remember correctly, the arm simulator does various calculations and
> pipeline tracking.
> It's been a while, but it was doing this in the giant instruction switch
> statement.
> 
> I've not read or looked at the H8 simulator does the H8 simulator sort
> of "count instruction/clock time" - based on memory accesses?

nope, the h8300 sim doesn't have any stats/tracking like that

> The old 6502 had a very similar zero page feature (first 256 bytes) -
> aka: a zero page instructions.
> 
> Accessing zero page using a zero page instruction required 3 clocks
> (aka: the first 256 bytes)
> Accessing absolute required 4 clocks, but you *CAN* access zero page in
> absolute mode if you choose
> This was useful when I wrote bit-bang uart simulation code (ie: Tight SW
> loop - to emulate a uart via GPIO pin)
> 
> Thus - from a logical view the "memory is just memory" end of story.
> 
> if this is not evident in the simulation code, this might have been a
> planned feature that never materialized or was never finished.

from what i can tell from the H8/300 manuals, there is no zero page,
and the first few bytes are reset/exception vectors.
https://www.renesas.com/en-us/doc/products/mpumcu/001/e602025_h8300.pdf

so it's similar to the 6502 in that you have more efficient addressing
for a small bit of memory, but i think that's about it.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]