This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: New targets to Binutils for H8 series
- From: "D.Venkatasubramanian, Noida" <dvenkat at noida dot hcltech dot com>
- To: Kazu Hirata <kazu at cs dot umass dot edu>, Andrew dot Volkov at transas dot com
- Cc: gcc at gcc dot gnu dot org, crossgcc at sources dot redhat dot com, gnuh8 at gnuh8 dot org dot uk, binutils at sources dot redhat dot com
- Date: Thu, 6 Feb 2003 11:08:11 +0530
- Subject: RE: New targets to Binutils for H8 series
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/