This is the mail archive of the 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?

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

> 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                 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]