Re: Patch H8300/S Bit Instruction Relaxing

[Paul Clarke <paulc at hydraelectronics dot com dot au>]

Regarding the concern that a :8 memory reference at 'FF02 could as a result
of the text segment relaxing move outside of the 'FF00-'FFFF (eight bit
area),
I offer these reasons why it is unlikely to occur.

The H8S21xx series have internal registers starting at 'FF50 and ending 
at 'FFEF. A 128 byte ram area exists from 'FF00 to 'FF7F followed by 128
internal registers from 'FF80 to 'FFFF. I think that this ram arrangement 
is similar in all H8 devices. (Can anyone find a counter example?) As the 
addresses below the ram are internal registers, which cannot be mapped out, 
the eight bit area must be specified for the variable (as an attribute in
C).

If a program exists that does not specify the section for the variable it 
is very likely that the variable or will be first assigned to the internal 
register addresses and the behaviour of the program will quite likely
suffer. 

In the case of tiny address mode, :16 address mode for address '0000-'7FFF
and 
'8000-'FFFF. It is quite likely that ram overlaps the transition from 32 bit

to 16 bit address. If the tiny area is not specified then a relaxing problem
where an address in the tiny area moves below '8000 by relaxes in the .text
section. As long as the linker prints an error (my patch now gives this
error)
this should be acceptable.

I would think that most software designers would avoid this problem and
optimise their code by specifying a tiny area for static variables. Embedded

programmers are likely to have separate ram and rom areas.

There is one other issue with the code at present and that is H8S
instructions
can be linked in H8H mode. I am working on this at present. Basically the 
opcode format specifies an inbase field which is true if the instruction is 
a plain H8300 instruction. I am changing this to minbase which specifies the
minimum processor core that supports the opcode. All the opcodes need
changing
and verifying that they work only in the applicable processor cores.  

Paul Clarke