Johannes Stezenbach wrote:
> I use a toolchain based on binutils 126.96.36.199.1 and
> gcc 2.95.4-debian.
> To use that instructions I have to pass -march=vr4100
> to the assembler. Unfortunately, -march and -mcpu cannot
> be used together, so first I changed arch/mips/Makefile
> GCCFLAGS += -mcpu=r4600 -mips2 -Wa,--trap
If this gcc already supports vr4100 you could use
GCCFLAGS += -mcpu=vr4100 -mips2 -Wa,--trap
> GCCFLAGS += -Wa,-march=vr4100 -mips2 -Wa,--trap
> This works, but I am unshure what the effects of the
> missing -mcpu switch are wrt the code generated by gcc.
> AFAICS the kernel still works, but is the generated
> code slower or subtly incorrect?
I don't know what the compiler does then. I assume it defaults to
The assembler will emit vr4100 code scheduled for vr4100. If you still
want r4600 scheduling (I doubt so), you could add
to the GCCFLAGS line.
> So I think I need either:
> - make gas accept -march=vr4100 along with -mcpu=r4600 (or -mcpu=r4100?)
-mcpu is deprecated and remains for backward compatibility to gcc < 3.0.
it should be replaced by -march/-mtune.
> - or have a ".set vr4100" directive to enable the vr41xx specific
> instructions where needed, without changing the flags in the
> ELF header
I would suggest the syntax
This is in my TODO list for gas, but don't hold your breath.
> - or make the linker link modules with different (but compatible) e_flags
> - or is "GCCFLAGS += -Wa,-march=vr4100 -mips2 -Wa,--trap" perfect?
> Please, does anybody have suggestions how to solve this issue?
The real fix is to use a newer compiler (gcc >= 3). :-)