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?
Ralf Corsepius wrote:
>
> Am Mit, 2002-05-29 um 14.13 schrieb Joern Rennecke:
> > Ralf Corsepius wrote:
> > [sh-1 is broken and sh-coff was broken]
> > > 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
> >
> > Yes.
> >
> > > No, this perspective doesn't match. The SH1/sh-coff is among the targets
> > > RTEMS supports.
> >
> > Are there still people using it, apart from testing that it still works?
> I don't know. Through past years, there have been several request and
> apparent attempts to use it, but I don't know if they were successful
> and if they are still actively used.
>
> However, I assume the SH2-port in RTEMS (Which shares some code with the
> sh1-port) to be used.
>
> Your own (SH1) applications are frozen and have not been changed for
> years, but our current policy is "if demands for changing them shall pop
> up, these applications be revitalized" (They currently are in sort of a
> stand-by-position. SH1 as controller on custom HW in $$$$$ mechanics)
>
> > > 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.
> >
> > Note that the assembler silently assembles the file as SH-2 code, and
> > thus it is linked and run by the simulator as SH-2. But tests on SH1 hardware
> > can be expected to fail.
> <sigh>
Would adding the binutils option get it marked as sh1 and let the sim
honor
that?
> No surprize, the SH-Gnu-toolchain has repeatedly been in bad shape over
> the years (And currently seems to be again. AFAIS, the SH code in
> gcc-3.1 contains hard-coded references to ELF-specific code)
RTEMS would happily move to sh-elf if it proved stable enough. But so
far it hasn't.
> > If we want to continue to support SH-1, we should have the compiler pass an
> > option to the assembler to limit the acceptable instruction set to the one
> > being used, so that regressions are caught. Otherwise, SH-2 instruction are
> > just too likely to sneak back in.
> Sounds reasonable to me.
>
> BTW: I have no problem if you'd like to abandon the sh1 multilib variant
> from the SH default multilibs. We'd add an RTEMS-specific t-rtems to
> implement RTEMS-specific multilib variants for the SH then (We already
> do for some other targets).
I have a nagging feeling that this will only encourage the bitrot.
Either the SH1 is supported or it isn't. Hiding a broken CPU
in a t-rtems is just sweeping it under the rug.
Ralf, do you remember how long it took to get all the x86
multilibs building because no target except i386-rtems built
soft-float and all the p5, k6, athlon, etc variants? I would hate
to see the RTEMS community the only group reporting sh1 problems.
> Ralf
--
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