This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: make sh-1 support in gcc obsolete?




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]