Re: make sh-1 support in gcc obsolete?

[Ralf Corsepius <corsepiu at faw dot uni-ulm dot de>]

Am Mit, 2002-05-29 um 15.28 schrieb Joern Rennecke:
> >> 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.
> 
> Joel Sherrill wrote:
> > OK. I went for ASM_CPU_SPEC in sh.h but this was the closest thing I
> > could find.
> > 
> > #define ASM_SPEC  "%{ml:-little} %{mrelax:-relax}"
> > 
> > Is this the place that needs to be modified so -m1, etc get translated?
> 
> Yes - for the time being.
> 	
> > I don't see the option on my sh- assembler that matches.
> > 
> > SH options:
> > -little                 generate little endian code
> > -big                    generate big endian code
> > -relax                  alter jump instructions for long displacements
> > -small                  align sections to 4 byte boundaries, not 16
> > -dsp                    enable sh-dsp insns, and disable sh3e / sh4
> > insns.
> 
> There isn't any.  It would have to be added.
> How about cpu, e.g.: cpu=sh1 ?
I don't have a strong opinion on this. It seems to match with what seems
to be preferred for other CPUs ...

> > -dsp appears to be the closest option but it allows sh2 instructions.
> 
> Yes, but the machinery is all there.  If you set target_arch to arch_sh1
> in md_begin, gas will only accept SH1 instructions.  If you set it to
> arch_sh1_up,
> it will accept code for any processor, including sh4 and sh3-dsp (but not a mix
> of floating point and dsp instructions).
Just to clarify: Your plan is to use binutils' -m1/cpu=sh1 as "last
resort" SH-ASM-flavor checker?

Or is your plan to convert gcc to generate SH2 instructions only and to
let binutils transform them into SH1 instructions (Using SH2-ASM as
"meta-language"). I am not sure, but I doubt this can work (But, you
probably know better than me).

Ralf