This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: make sh-1 support in gcc obsolete?
- From: Joel Sherrill <joel dot sherrill at OARcorp dot com>
- To: Joern Rennecke <joern dot rennecke at superh dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 29 May 2002 06:05:59 -0500
- Subject: Re: make sh-1 support in gcc obsolete?
- Organization: OAR Corporation
- References: <3CF40F53.54D445D3@superh.com>
- Reply-to: joel dot sherrill at OARcorp dot com
Joern Rennecke wrote:
>
> 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
> timespan...).
>
> 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.
>
> 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. 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).
As Ralf points out separately, RTEMS uses sh-coff because sh-elf isn't
there
yet and hasn't switched to 3.x because until 3.1 it simply wasn't stable
enough. So please don't abandon the SH-1. This is a regression.
FWIW I have reported test results for sh-coff multiple times since
the date in question but I guess no one has investigated the huge number
of failures. From
http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00610.html
for sh-coff:
=== gcc Summary ===
# of expected passes 13879
# of unexpected failures 4255
# of expected failures 66
# of unresolved testcases 31
# of unsupported tests 129
But this is essentially the same as 3.1 for sh-elf so I don't see the
distinction
(http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00614.html):
=== gcc Summary ===
# of expected passes 13900
# of unexpected failures 4273
# of expected failures 66
# of unresolved testcases 42
# of unsupported tests 125
As best I can tell, both sh-coff and sh-elf are badly broken. :( There
appears to be no advantage to sh-elf from the test results.
> --
> --------------------------
> SuperH
> 2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
> T:+44 1454 462330
--
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985