Johannes Stezenbach wrote: [snip] > I use a toolchain based on binutils 2.12.90.0.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 > from > GCCFLAGS += -mcpu=r4600 -mips2 -Wa,--trap If this gcc already supports vr4100 you could use GCCFLAGS += -mcpu=vr4100 -mips2 -Wa,--trap > to > 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 r3000 scheduling/opcodes. The assembler will emit vr4100 code scheduled for vr4100. If you still want r4600 scheduling (I doubt so), you could add -Wa,-mtune=r4600 to the GCCFLAGS line. [snip] > 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 .set march=vr4100 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). :-) Thiemo
