New targets to Binutils for H8 series

New targets to Binutils for H8 series

[Shrinivas Atre]

Hi,

Could any one please comment on following or suggest any ideas ?

Background:
-----------

The H8 port of GNU identifies three targets.
1. H8/300	- ".h8300" in assembly file and linker script
2. H8/300H 	- ".h8300h" in assembly file and linker script
3. H8S	- ".h8300s" in assembly file and linker script

For H8S and H8/300H there is no provision to identify the mode of operation 
i.e. if the executable is for normal mode or advanced mode. 

Due to this we cannot run executables of Normal mode using the GDB/simulator. 
Same problem occurs when the normal mode executable is being debugged.

What I have tried ?
-------------------
1. Providing the command line switch ( -n -S or -n -h ) while  running 
   the simulator.
2. Addition of one "set mode" command to select the operating mode in the GDB 
   while debugging the normal mode executable.

Issues:
-------

1. Using these switches for advanced mode executable and not using these 
   switches for normal mode executable *may* crash the GDB/Simulator. 
   This is because the GDB/Simulator will misinterpret the data based upon 
   these switches. And there is no way to ensure this from within executable.

2. When any program is compiled for normal mode with the default linker script 
   ( Default linker script uses 24 bit memory area) there will be code/code 
   references beyond 64K memory in the executable. Now the normal mode assumes 
   that the target has 64K memory and will crash if the memory access beyond 64K 
   is done. To solve this, the executable for normal mode must be created with 
   the linker script which uses 64K memory.

Permanent Solution:
-------------------
1. I feel, we should add two new targets in the GCC and Binutils for H8S 
   and H8/300H normal mode. e.g. "h8300hn" and "h8300sn". 
   Existing ".h8300h" and ".h8300s" will denote advanced mode. 
   These targets will be automatically used when -mn switch is 
   used while compiling the file.

2. For these additional modes the default linker script will be with 
   64K memory region.

3. This will ensure that every executable will contain full target 
   information including the operating mode. 

This will need few changes in GCC and major changes in Binutils. 
Also corresponding changes in the GDB/Simulator will have to be made.

Impact:
-------
1. All existing executables (and libraries) compiled with -mn switch will 
   have to be rebuilt. The volume of such executables (or libraries ), 
   I feel, is less. This is because normal mode support just been added 
   to the H8 port of GNU.


Could any one tell me if there are any others issues involved in this ? 
What could be other possible alternative to achieve this ?
Has any one tried such things before ?

Regards,
Shrinivas

-----------------------------------------------------------------------------
Free download of GNUSH and GNUH8 tool chains for Hitachi's SH and H8 Series.
The following site also offers free support to European customers.
Read more at http://www.kpit.com/products/support.htm
Latest versions of GNUSH and GNUH8 are released on October 1, 2002.
-----------------------------------------------------------------------------

Re: New targets to Binutils for H8 series

[Kazu Hirata]

Hi Shrinivas,

> 1. I feel, we should add two new targets in the GCC and Binutils for H8S 
>    and H8/300H normal mode. e.g. "h8300hn" and "h8300sn". 
>    Existing ".h8300h" and ".h8300s" will denote advanced mode. 
>    These targets will be automatically used when -mn switch is 
>    used while compiling the file.

I think this is a good idea.

> This will need few changes in GCC and major changes in Binutils. 
> Also corresponding changes in the GDB/Simulator will have to be made.

I don't know much about binutils, but isn't it relatively
straightforward to add a new magic number depending on command line
options (at least for COFF)?

Kazu Hirata

RE: New targets to Binutils for H8 series

[D.Venkatasubramanian, Noida]

Hi All,

Regarding, this thread, were some new targets added to Binutils?

The MAC registers are only present in the H8S/2600 Line.

h8300-elf-gcc also works correctly by generating MAC 
instructions only when -ms2600 is specified. I found 
these instructions when I ran the testsuite with 
-O2 -ms -ms2600

Testcase gcc.c-torture/execute/va-arg-22.c 

using this command :

h8300-elf-gcc -O3 -fomit-frame-pointer -funroll-loops  -finline-functions
-ms -ms2600 -mint32 -g va-arg-22.c

As the simulator is unable to simulate these instructions now,
I am thinking of adding that support. If we had special 
targets especially for H8S/2600, then it would be easier to 
map these registers only when the binary is for 2600.

As of now, I don't think, GDB or simulator can identify 
specific series. The simulator seems to be capable of only 
identifying a binary as h8300 or h8300h or h8300s.

Regards,

Venky

-----Original Message-----
From: Kazu Hirata [mailto:kazu@cs.umass.edu]
Sent: Monday, January 20, 2003 6:01 AM
To: Andrew.Volkov@transas.com
Cc: gcc@gcc.gnu.org; crossgcc@sources.redhat.com; gnuh8@gnuh8.org.uk;
binutils@sources.redhat.com
Subject: Re: New targets to Binutils for H8 series


Hi Andrew,

> > This way, we don't have to have separate libgcc.a and 
lib[mc].a, etc, for
> > H8S/2600 because the difference of instruction sets between H8S and
> > H8S/200 is only mac-related instructions.
> 
> At present you are right, but:
> 1) what about using MAC in lib[mc], in future releases of newlib?
> 2) what about interrupt frames in library routines?

Actually I have to admit that the interrupt frame does not save mac
yet.  I think one reasonable implementation is to save the mac
register in a function that uses it because not every function uses
it.  In other words, we probably do not want to make it a
call-clobbered register.

By the way, Hitachi just released H8SX, an update to H8S series, so we
want to have something like .h8sx.

Kazu Hirata

-- 
GNUH8 Mailing List | If you encounter difficulties using this service
                   | email: listmaster@gnuh8.org.uk
                   | http://www.gnuh8.org.uk/

RE: New targets to Binutils for H8 series

[D.Venkatasubramanian, Noida]

Hi All,

I was interested in implementing some extensions to 
the H8300 simulator and was thinking of adding some 
code to crt0.S. I would like this code to be 
available when the code would be run under a 
simulator. I think it would be a good idea to add a 
target, say -msim, so that the code is generated for 
simulated target only.

In the context, I was actually trying to include 
commandline support to the simulator and so would 
have to setup the stack with the commandline 
arguments in crt0.S. I didn't think it would be a 
good idea to add the code to the default 
implementation, by adding the target, we could 
write any simulator specific code inside a 
#ifdef __SIMULATOR__ kind of structure, similar to 
the ARM implementation.

Any comments or suggestions would be useful.

Thanks and Best Regards,

Venky

Re: New targets to Binutils for H8 series

[Kazu Hirata]

Hi Andrew,

> > This way, we don't have to have separate libgcc.a and lib[mc].a, etc, for
> > H8S/2600 because the difference of instruction sets between H8S and
> > H8S/200 is only mac-related instructions.
> 
> At present you are right, but:
> 1) what about using MAC in lib[mc], in future releases of newlib?
> 2) what about interrupt frames in library routines?

Actually I have to admit that the interrupt frame does not save mac
yet.  I think one reasonable implementation is to save the mac
register in a function that uses it because not every function uses
it.  In other words, we probably do not want to make it a
call-clobbered register.

By the way, Hitachi just released H8SX, an update to H8S series, so we
want to have something like .h8sx.

Kazu Hirata

RE: New targets to Binutils for H8 series

[Andrew Volkov]

Hi Kazu,

> 
> > Good idea, but I think also will be good, mark 26xx subtarget as 
> > new bfd-target too.
> 
> I am basically for having a subtarget for each combination of
> instruction set and mode.  However, if we have .h2600 or something,
> then we should probably have "upward compatibility" thing built into
> the linker so that we can mix H8S/2600 code with H8S or H8/300H.  

I don't think it will be a big problem, cause we told about 
change numeration of bfd-subtargets, so why not take such numbers,
wich will be "upward compatible" (simly set high bit, I think)? 

> This way, we don't have to have separate libgcc.a and lib[mc].a, etc, for
> H8S/2600 because the difference of instruction sets between H8S and
> H8S/200 is only mac-related instructions.

At present you are right, but:
1) what about using MAC in lib[mc], in future releases of newlib?
2) what about interrupt frames in library routines?

Regards,
Andrey

RE: New targets to Binutils for H8 series

[D.Venkatasubramanian, Noida]

Hi,

And probably new targets for h8300h and h8300s with -mint32 specified.
I have seen such combinations in some other targets. Could be useful 
in making changes for the simulator.

Regards,

Venky

> -----Original Message-----
> From: Kazu Hirata [mailto:kazu@cs.umass.edu]
> Sent: Friday, January 10, 2003 3:55 AM
> To: Andrew.Volkov@transas.com
> Cc: gcc@gcc.gnu.org; crossgcc@sources.redhat.com; gnuh8@gnuh8.org.uk
> Subject: Re: New targets to Binutils for H8 series
> 
> 
> Hi Andrew,
> 
> > Good idea, but I think also will be good, mark 26xx subtarget as 
> > new bfd-target too.
> 
> I am basically for having a subtarget for each combination of
> instruction set and mode.  However, if we have .h2600 or something,
> then we should probably have "upward compatibility" thing built into
> the linker so that we can mix H8S/2600 code with H8S or H8/300H.  This
> way, we don't have to have separate libgcc.a and lib[mc].a, etc, for
> H8S/2600 because the difference of instruction sets between H8S and
> H8S/200 is only mac-related instructions.
> 
> Kazu Hirata
> 

Re: New targets to Binutils for H8 series

[Kazu Hirata]

Hi Andrew,

> Good idea, but I think also will be good, mark 26xx subtarget as 
> new bfd-target too.

I am basically for having a subtarget for each combination of
instruction set and mode.  However, if we have .h2600 or something,
then we should probably have "upward compatibility" thing built into
the linker so that we can mix H8S/2600 code with H8S or H8/300H.  This
way, we don't have to have separate libgcc.a and lib[mc].a, etc, for
H8S/2600 because the difference of instruction sets between H8S and
H8S/200 is only mac-related instructions.

Kazu Hirata

RE: New targets to Binutils for H8 series

[Andrew Volkov]

Hi Kazu,

Good idea, but I think also will be good, mark 26xx subtarget as 
new bfd-target too.

Regards
Andrey

> Hi Shrinivas,
> 
> > 1. I feel, we should add two new targets in the GCC and 
> Binutils for H8S 
> >    and H8/300H normal mode. e.g. "h8300hn" and "h8300sn". 
> >    Existing ".h8300h" and ".h8300s" will denote advanced mode. 
> >    These targets will be automatically used when -mn switch is 
> >    used while compiling the file.
> 
> I think this is a good idea.
> 
> > This will need few changes in GCC and major changes in Binutils. 
> > Also corresponding changes in the GDB/Simulator will have 
> to be made.
> 
> I don't know much about binutils, but isn't it relatively
> straightforward to add a new magic number depending on command line
> options (at least for COFF)?
> 
> Kazu Hirata
>