Subject: Q: -mcpu= vs. -march= for VR41xx specific instructions

From: Johannes Stezenbach <[email-masked]>
Date: Thu, 14 Mar 2002 18:25:02 +0100

I am trying to implement power management for an embedded
device using a NEC VR4120 CPU core, which has the special
instructions "standby", "suspend" and "hibernate".

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

Then I the tried to compile the kernel with the standard
GCCFLAGS, setting -march=vr4100 only for the one
file which contains the standby/suspend/hibernate instructions.
This fails a link time with:

  mips-linux-ld: power.o: uses different e_flags (0x1100) fields than previous modules (0x1000)
  Bad value: failed to merge target specific data of file power.o

I looked at an old arch/mips/Makefile from
http://sourceforge.net/projects/linux-vr/, which has:
  CFLAGS += -mcpu=r4600 -mips2 -Wa,-m4100,--trap
This does not work with my toolchain.

So I think I need either:
- make gas accept -march=vr4100 along with -mcpu=r4600 (or -mcpu=r4100?)
- or have a ".set vr4100" directive to enable the vr41xx specific
  instructions where needed, without changing the flags in the
  ELF header
- 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?

Regards,
Johannes

---

From: Jim Paris <[email-masked]>
Date: Thu, 14 Mar 2002 12:47:30 -0500

> - or is "GCCFLAGS += -Wa,-march=vr4100 -mips2 -Wa,--trap" perfect?

For lots of discussion of this, see

   http://sources.redhat.com/ml/binutils/2001-10/threads.html#00504

then

   http://sources.redhat.com/ml/binutils/2001-11/threads.html#00001

I don't remember where things currently stand.

-jim

---

From: Thiemo Seufer <[email-masked]>
Date: Thu, 14 Mar 2002 19:10:31 +0100

Johannes Stezenbach wrote:
[snip]
>   GCCFLAGS += -mcpu=r4600 -mips2 -Wa,--trap

If this gcc already supports vr4100 you could use

	GCCFLAGS += -mcpu=vr4100 -mips2 -Wa,--trap

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

>   instructions where needed, without changing the flags in the

I would suggest the syntax

	.set march=vr4100

This is in my TODO list for gas, but don't hold your breath.

> Please, does anybody have suggestions how to solve this issue?

The real fix is to use a newer compiler (gcc >= 3). :-)

Thiemo

---

From: Johannes Stezenbach <[email-masked]>
Date: Thu, 14 Mar 2002 19:34:32 +0100

> r3000 scheduling/opcodes.

How bad is that compared to -mcpu=vr4100?

> This is in my TODO list for gas, but don't hold your breath.

OK.

> The real fix is to use a newer compiler (gcc >= 3). :-)

Not too long ago people here told me that gcc 3.x is still
not ready for production use. Or is gcc-3.1-pre from CVS
ready for prime time?

Thanks,
Johannes