This is the mail archive of the
mailing list for the GCC project.
Re: make sh-1 support in gcc obsolete?
- From: Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>
- To: Joern Rennecke <joern dot rennecke at superh dot com>
- Cc: GCC List <gcc at gcc dot gnu dot org>, Joel Sherrill <joel dot sherrill at OARcorp dot com>
- Date: 29 May 2002 11:44:32 +0200
- Subject: Re: make sh-1 support in gcc obsolete?
- References: <3CF40F53.54D445D3@superh.com>
Am Mit, 2002-05-29 um 01.14 schrieb Joern Rennecke:
> The SH-1 processor, unlike its sucessors, doesn't have delayed
> conditional branches, nor the branch far (braf) instruction.
> The lack of delayed conditional branches causes some ugliness
> in assembler files. The lack of braf means that you can't
> execute a program on SH-1 that has been compiled with a
> gcc from mainline sources after September 2001, because
> CRT_CALL_STATIC_FUNCTION uses braf (CRT_CALL_STATIC_FUNCTION
> is not used for coff, but then, coff was defunct during that
This is sad to hear. I am inclined this qualifies to be a bug in GCC and
as a regression to gcc-2.95.x
> I presume that we take the lack of interest for this breakage as an
> indication of a lack of interest for sh-1 support in new gcc releases
> in general.
No, this perspective doesn't match. The SH1/sh-coff is among the targets
However, we have not encountered the problems you mention, because RTEMS
has been using gcc-2.95.x until now in general, because gcc-3.x had
proven to be close to unusable for many embedded targets RTEMS supports.
RTEMS currently is in the process of switching to 3.1 (Still using
SH-coff, still supporting the SH1), so we probably will encounter the
problems you mention.
It's simply that we have not used it yet.
> Now, while sh-coff might be used in the future as a starting
> point for a coff-based OS port, I can't see any such redeeming
> features for SH-1.
This doesn't matter, RTEMS has an SH1-coff port and it is actively
maintained (by me).
[BTW: Switch to elf and to abandon coff is planed, but there are other
issues with sh-elf which currently prevent RTEMS from switch to it.
Primarily it's lack to time to address these issues.]
> Moreover, by removing sh-1 support, we'll also remove
> two multilibs from the standard sh-elf port, thus reducing build times,
> test times, and binary toolchain size.
> There are also a few more fringe simplification benefits because SH2 and
> later procesors all support 32 bit multiply, decrement and test, and
> branch to subroutine far (bsrf).