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?


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
> timespan...).
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
RTEMS supports.

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.

IMO: No-go.

> 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).

Ralf



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