Does -march=r5000 imply HAVE_32BIT_GPRS?

Does -march=r5000 imply HAVE_32BIT_GPRS?

[H . J . Lu]

The current gas sets HAVE_64BIT_GPRS when -march=r5000 is used with

/*  Return true if ISA supports 64 bit gp register instructions.  */
#define ISA_HAS_64BIT_REGS(ISA) (    \
   (ISA) == ISA_MIPS3                \
   || (ISA) == ISA_MIPS4             \
   || (ISA) == ISA_MIPS5             \
   || (ISA) == ISA_MIPS64            \
   )

since -march=r5000 sets ISA to ISA_MIPS4. It is a departure from the
old behavior. That means you cannot use -march=r5000/-mcpu=r5000
only for 32bit applications. Is that intentional?


H.J.

Re: Does -march=r5000 imply HAVE_32BIT_GPRS?

[Richard Sandiford]

"H . J . Lu" <hjl@lucon.org> writes:

> The current gas sets HAVE_64BIT_GPRS when -march=r5000 is used with
> 
> /*  Return true if ISA supports 64 bit gp register instructions.  */
> #define ISA_HAS_64BIT_REGS(ISA) (    \
>    (ISA) == ISA_MIPS3                \
>    || (ISA) == ISA_MIPS4             \
>    || (ISA) == ISA_MIPS5             \
>    || (ISA) == ISA_MIPS64            \
>    )
> 
> since -march=r5000 sets ISA to ISA_MIPS4. It is a departure from the
> old behavior.

OK.  What was the old behaviour?  It sounds natural enough on the face of
it to set the ISA to ISA_MIPS4 if you select a MIPS IV part.  I thought
the idea was that if you wanted a different ISA (MIPS II, say), you'd
specify -mips2 as well as -march=r5000.

> That means you cannot use -march=r5000/-mcpu=r5000 only for 32bit
> applications. Is that intentional?

Have you tried -mfp32 and -mgp32?

Richard

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[H . J . Lu]

On Tue, Aug 14, 2001 at 09:50:20AM +0100, Richard Sandiford wrote:
> "H . J . Lu" <hjl@lucon.org> writes:
> 
> > The current gas sets HAVE_64BIT_GPRS when -march=r5000 is used with
> > 
> > /*  Return true if ISA supports 64 bit gp register instructions.  */
> > #define ISA_HAS_64BIT_REGS(ISA) (    \
> >    (ISA) == ISA_MIPS3                \
> >    || (ISA) == ISA_MIPS4             \
> >    || (ISA) == ISA_MIPS5             \
> >    || (ISA) == ISA_MIPS64            \
> >    )
> > 
> > since -march=r5000 sets ISA to ISA_MIPS4. It is a departure from the
> > old behavior.
> 
> OK.  What was the old behaviour?  It sounds natural enough on the face of
> it to set the ISA to ISA_MIPS4 if you select a MIPS IV part.  I thought
> the idea was that if you wanted a different ISA (MIPS II, say), you'd
> specify -mips2 as well as -march=r5000.

It doesn't work. Try  -march=r5000 -mips2 and run

# gcc -march=r5000 -mips2 -c foo.s
# readelf -h foo.o

I got
....
  Flags:                             0x30000102, pic, mips4 UNKNOWN
  						     ^^^^^^^
....

> 
> > That means you cannot use -march=r5000/-mcpu=r5000 only for 32bit
> > applications. Is that intentional?
> 
> Have you tried -mfp32 and -mgp32?
> 

Same.


H.J.

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Richard Sandiford]

"H . J . Lu" <hjl@lucon.org> writes:

> It doesn't work. Try  -march=r5000 -mips2 and run
> 
> # gcc -march=r5000 -mips2 -c foo.s
> # readelf -h foo.o
> 
> I got
> ....
>   Flags:                             0x30000102, pic, mips4 UNKNOWN
>   						     ^^^^^^^
> ....

Oh, I see what you mean.  FWIW, you do get 32-bit code, despite what the
header says...

> > > That means you cannot use -march=r5000/-mcpu=r5000 only for 32bit
> > > applications. Is that intentional?
> > 
> > Have you tried -mfp32 and -mgp32?
> > 
> 
> Same.

Yeah, but -mgp32 and -mfp32 aren't supposed to affect the ELF header flags.
Again, you get 32-bit code.

Richard

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[H . J . Lu]

On Tue, Aug 14, 2001 at 04:54:06PM +0100, Richard Sandiford wrote:
> "H . J . Lu" <hjl@lucon.org> writes:
> 
> > It doesn't work. Try  -march=r5000 -mips2 and run
> > 
> > # gcc -march=r5000 -mips2 -c foo.s
> > # readelf -h foo.o
> > 
> > I got
> > ....
> >   Flags:                             0x30000102, pic, mips4 UNKNOWN
> >   						     ^^^^^^^
> > ....
> 
> Oh, I see what you mean.  FWIW, you do get 32-bit code, despite what the
> header says...

It looks like the case. But I don't know for sure. Assuming I do get
32-bit code, why is mips4 set? When the binary loaded into memory,
bad things may happen when the mips4 flag is set.


H.J.

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Richard Sandiford]

"H . J . Lu" <hjl@lucon.org> writes:

> It looks like the case. But I don't know for sure. Assuming I do get
> 32-bit code, why is mips4 set? When the binary loaded into memory,
> bad things may happen when the mips4 flag is set.

Yes, it certainly looks like a bug.

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

Richard Sandiford wrote:
> "H . J . Lu" <hjl@lucon.org> writes:
> 
> > It looks like the case. But I don't know for sure. Assuming I do get
> > 32-bit code, why is mips4 set? When the binary loaded into memory,
> > bad things may happen when the mips4 flag is set.
> 
> Yes, it certainly looks like a bug.

I've looked into this and found that the elf header flags for
E_MIPS_ARCH_* and E_MIPS_MACH_* are never set in the assembler,
instead they are later guessed in bfd in dependency of bfd_mach_mips*
where earlier settings done by the asssembler are also killed, so
it is impossible to override the machines default ISA (of course
only WRT the ELF headers).

Since I haven't found a good reason why bfd should override the
assembler's settings with it's little information, I removed the
relevant code there and introduced something similiar in the
assembler.


2001-08-16  Thiemo Seufer <seufer@csv.ica.uni-stuttgart.de>

	/bfd/ChangeLog
	* elf32-mips.c (_bfd_mips_elf_final_write_processing): Remove setting
	of elf header flags for ARCH/MACH.

	/gas/ChangeLog
	* config/tc-mips.c (mips_elf_final_processing): Add setting of elf
	header flags for ARCH/MACH.

	/binutils/ChangeLog
	* readelf.c (get_machine_flags): Add recognition of EF_MIPS_32BITMODE.


diff -BurpNX /bigdisk/src/binutils-exclude src-orig/bfd/elf32-mips.c src/bfd/elf32-mips.c
--- src-orig/bfd/elf32-mips.c	Wed Jul  4 13:55:24 2001
+++ src/bfd/elf32-mips.c	Thu Aug 16 01:35:22 2001
@@ -2352,80 +2353,10 @@ _bfd_mips_elf_final_write_processing (ab
      bfd *abfd;
      boolean linker ATTRIBUTE_UNUSED;
 {
-  unsigned long val;
   unsigned int i;
   Elf_Internal_Shdr **hdrpp;
   const char *name;
   asection *sec;
-
-  switch (bfd_get_mach (abfd))
-    {
-    default:
-    case bfd_mach_mips3000:
-      val = E_MIPS_ARCH_1;
-      break;
-
-    case bfd_mach_mips3900:
-      val = E_MIPS_ARCH_1 | E_MIPS_MACH_3900;
-      break;
-
-    case bfd_mach_mips6000:
-      val = E_MIPS_ARCH_2;
-      break;
-
-    case bfd_mach_mips4000:
-    case bfd_mach_mips4300:
-    case bfd_mach_mips4400:
-    case bfd_mach_mips4600:
-      val = E_MIPS_ARCH_3;
-      break;
-
-    case bfd_mach_mips4010:
-      val = E_MIPS_ARCH_3 | E_MIPS_MACH_4010;
-      break;
-
-    case bfd_mach_mips4100:
-      val = E_MIPS_ARCH_3 | E_MIPS_MACH_4100;
-      break;
-
-    case bfd_mach_mips4111:
-      val = E_MIPS_ARCH_3 | E_MIPS_MACH_4111;
-      break;
-
-    case bfd_mach_mips4650:
-      val = E_MIPS_ARCH_3 | E_MIPS_MACH_4650;
-      break;
-
-    case bfd_mach_mips5000:
-    case bfd_mach_mips8000:
-    case bfd_mach_mips10000:
-    case bfd_mach_mips12000:
-      val = E_MIPS_ARCH_4;
-      break;
-
-    case bfd_mach_mips32:
-      val = E_MIPS_ARCH_32;
-      break;
-
-    case bfd_mach_mips32_4k:
-      val = E_MIPS_ARCH_32 | E_MIPS_MACH_MIPS32_4K;
-      break;
-
-    case bfd_mach_mips5:
-      val = E_MIPS_ARCH_5;
-      break;
-
-    case bfd_mach_mips64:
-      val = E_MIPS_ARCH_64;
-      break;
-
-    case bfd_mach_mips_sb1:
-      val = E_MIPS_ARCH_64 | E_MIPS_MACH_SB1;
-      break;
-    }
-
-  elf_elfheader (abfd)->e_flags &= ~(EF_MIPS_ARCH | EF_MIPS_MACH);
-  elf_elfheader (abfd)->e_flags |= val;
 
   /* Set the sh_info field for .gptab sections and other appropriate
      info for each special section.  */
diff -BurpNX /bigdisk/src/binutils-exclude src-orig/gas/config/tc-mips.c src/gas/config/tc-mips.c
--- src-orig/gas/config/tc-mips.c	Sun Aug 12 13:34:58 2001
+++ src/gas/config/tc-mips.c	Thu Aug 16 00:39:49 2001
@@ -11572,6 +11870,62 @@ mips_elf_final_processing ()
     elf_elfheader (stdoutput)->e_flags |= EF_MIPS_NOREORDER;
   if (mips_pic != NO_PIC)
     elf_elfheader (stdoutput)->e_flags |= EF_MIPS_PIC;
+  switch (file_mips_isa)
+    {
+      case ISA_MIPS1:
+	elf_elfheader (stdoutput)->e_flags |= E_MIPS_ARCH_1;
+	break;
+      case ISA_MIPS2:
+	elf_elfheader (stdoutput)->e_flags |= E_MIPS_ARCH_2;
+	break;
+      case ISA_MIPS3:
+	elf_elfheader (stdoutput)->e_flags |= E_MIPS_ARCH_3;
+	break;
+      case ISA_MIPS4:
+	elf_elfheader (stdoutput)->e_flags |= E_MIPS_ARCH_4;
+	break;
+      case ISA_MIPS5:
+	elf_elfheader (stdoutput)->e_flags |= E_MIPS_ARCH_5;
+	break;
+      case ISA_MIPS32:
+	elf_elfheader (stdoutput)->e_flags |= E_MIPS_ARCH_32;
+	break;
+      case ISA_MIPS64:
+	elf_elfheader (stdoutput)->e_flags |= E_MIPS_ARCH_64;
+	break;
+      case ISA_UNKNOWN:
+      default:
+	if (mips_64)
+	  elf_elfheader (stdoutput)->e_flags |= E_MIPS_ARCH_3;
+	else
+	  elf_elfheader (stdoutput)->e_flags |= E_MIPS_ARCH_1;
+	break;
+    }
+
+  switch (mips_arch)
+    {
+    case CPU_R3900:
+      elf_elfheader (stdoutput)->e_flags |= E_MIPS_MACH_3900;
+      break;
+    case CPU_R4010:
+      elf_elfheader (stdoutput)->e_flags |= E_MIPS_MACH_4010;
+      break;
+    case CPU_VR4100:
+      elf_elfheader (stdoutput)->e_flags |= E_MIPS_MACH_4100;
+      break;
+    case CPU_R4111:
+      elf_elfheader (stdoutput)->e_flags |= E_MIPS_MACH_4111;
+      break;
+    case CPU_R4650:
+      elf_elfheader (stdoutput)->e_flags |= E_MIPS_MACH_4650;
+      break;
+    case CPU_MIPS32_4K:
+      elf_elfheader (stdoutput)->e_flags |= E_MIPS_MACH_MIPS32_4K;
+      break;
+    case CPU_SB1:
+      elf_elfheader (stdoutput)->e_flags |= E_MIPS_MACH_SB1;
+      break;
+    }
 
   /* Set the MIPS ELF ABI flags.  */
   if (mips_abi_string == NULL)
diff -BurpNX /bigdisk/src/binutils-exclude src-orig/binutils/readelf.c src/binutils/readelf.c
--- src-orig/binutils/readelf.c	Sun Aug 12 13:34:57 2001
+++ src/binutils/readelf.c	Thu Aug 16 01:45:31 2001
@@ -1577,6 +1577,9 @@ get_machine_flags (e_flags, e_machine)
 	  if (e_flags & EF_MIPS_ABI2)
 	    strcat (buf, ", abi2");
 
+	  if (e_flags & EF_MIPS_32BITMODE)
+	    strcat (buf, ", 32bitmode");
+
 	  if ((e_flags & EF_MIPS_ARCH) == E_MIPS_ARCH_1)
 	    strcat (buf, ", mips1");
 

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Ian Lance Taylor]

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:

> 	/bfd/ChangeLog
> 	* elf32-mips.c (_bfd_mips_elf_final_write_processing): Remove setting
> 	of elf header flags for ARCH/MACH.

Won't this break the linker?

Ian

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

Ian Lance Taylor wrote:
> Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> 
> > 	/bfd/ChangeLog
> > 	* elf32-mips.c (_bfd_mips_elf_final_write_processing): Remove setting
> > 	of elf header flags for ARCH/MACH.
> 
> Won't this break the linker?

It doesn't for me.
AFAICS, the old behaviour is to ignore the user's ARCH settings
and to guess incorrect ones based on the cpu type. The new behaviour
respects the user's settings and requires the linker to actually
use the flags found in the object files.


Thiemo

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Eric Christopher]

On 16 Aug 2001 12:59:19 +0200, Thiemo Seufer wrote:
> Ian Lance Taylor wrote:
> > Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> > 
> > > 	/bfd/ChangeLog
> > > 	* elf32-mips.c (_bfd_mips_elf_final_write_processing): Remove setting
> > > 	of elf header flags for ARCH/MACH.
> > 
> > Won't this break the linker?
> 
> It doesn't for me.

How did you test it?

> AFAICS, the old behaviour is to ignore the user's ARCH settings
> and to guess incorrect ones based on the cpu type. The new behaviour
> respects the user's settings and requires the linker to actually
> use the flags found in the object files.
> 
> 

-eric

-- 
Look out behind you!

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

Eric Christopher wrote:
[snip]
> > > > 	/bfd/ChangeLog
> > > > 	* elf32-mips.c (_bfd_mips_elf_final_write_processing): Remove setting
> > > > 	of elf header flags for ARCH/MACH.
> > > 
> > > Won't this break the linker?
> > 
> > It doesn't for me.
> 
> How did you test it?

Well, it links my experimental mips64-linux kernel and also some
toy programs and passes "make check". So there are at least some
cases where it doesn't break the linker. :-)

H.J., you have started this thread, could you please test if
my patch works for you also?


Thiemo

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[H . J . Lu]

On Thu, Aug 16, 2001 at 11:26:27PM +0200, Thiemo Seufer wrote:

> Well, it links my experimental mips64-linux kernel and also some
> toy programs and passes "make check". So there are at least some
> cases where it doesn't break the linker. :-)
> 
> H.J., you have started this thread, could you please test if
> my patch works for you also?
> 
> 

I prefer this patch.


H.J.
-----
2001-08-16  H.J. Lu  <hjl@gnu.org>

	* gas/config/tc-mips.c (md_begin): Use -mipsN to set the BFD
	arch.

--- gas/config/tc-mips.c.isa	Thu Aug 16 14:40:35 2001
+++ gas/config/tc-mips.c	Thu Aug 16 14:48:51 2001
@@ -972,6 +972,7 @@ md_begin ()
   char *a = NULL;
   int broken = 0;
   int mips_isa_from_cpu;
+  int bfd_mips_arch;
   int target_cpu_had_mips16 = 0;
   const struct mips_cpu_info *ci;
 
@@ -1096,7 +1097,20 @@ md_begin ()
       && ISA_HAS_64BIT_REGS (mips_isa_from_cpu))
     mips_32bitmode = 1;
 
-  if (! bfd_set_arch_mach (stdoutput, bfd_arch_mips, mips_arch))
+  if (mips_opts.isa != mips_isa_from_cpu)
+    {
+      const struct mips_cpu_info *isa_ci;
+
+      /* -march=xxxx is not compatible with -mipsN. We use -mipsN to
+	 set the BFD arch.  */
+      isa_ci = mips_cpu_info_from_isa (mips_opts.isa);
+      assert (isa_ci != NULL);
+      bfd_mips_arch = isa_ci->cpu;
+    }
+  else
+    bfd_mips_arch = mips_arch;
+
+  if (! bfd_set_arch_mach (stdoutput, bfd_arch_mips, bfd_mips_arch))
     as_warn (_("Could not set architecture and machine"));
 
   file_mips_isa = mips_opts.isa;

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

H . J . Lu wrote:
> On Thu, Aug 16, 2001 at 11:26:27PM +0200, Thiemo Seufer wrote:
> 
> > Well, it links my experimental mips64-linux kernel and also some
> > toy programs and passes "make check". So there are at least some
> > cases where it doesn't break the linker. :-)
> > 
> > H.J., you have started this thread, could you please test if
> > my patch works for you also?
> > 
> > 
> 
> I prefer this patch.

[snip]
> +  if (mips_opts.isa != mips_isa_from_cpu)
> +    {
> +      const struct mips_cpu_info *isa_ci;
> +
> +      /* -march=xxxx is not compatible with -mipsN. We use -mipsN to
> +	 set the BFD arch.  */

Why should they be incompatible?


Thiemo

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[H . J . Lu]

On Fri, Aug 17, 2001 at 01:06:42AM +0200, Thiemo Seufer wrote:
> 
> [snip]
> > +  if (mips_opts.isa != mips_isa_from_cpu)
> > +    {
> > +      const struct mips_cpu_info *isa_ci;
> > +
> > +      /* -march=xxxx is not compatible with -mipsN. We use -mipsN to
> > +	 set the BFD arch.  */
> 
> Why should they be incompatible?
> 

mips_isa_from_cpu set by -march=r5000 is ISA_MIPS4. But mips_opts.isa
from -mips2 is ISA_MIPS2.


H.J.

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

H . J . Lu wrote:
> On Fri, Aug 17, 2001 at 01:06:42AM +0200, Thiemo Seufer wrote:
> > 
> > [snip]
> > > +  if (mips_opts.isa != mips_isa_from_cpu)
> > > +    {
> > > +      const struct mips_cpu_info *isa_ci;
> > > +
> > > +      /* -march=xxxx is not compatible with -mipsN. We use -mipsN to
> > > +	 set the BFD arch.  */
> > 
> > Why should they be incompatible?
> 
> mips_isa_from_cpu set by -march=r5000 is ISA_MIPS4. But mips_opts.isa
> from -mips2 is ISA_MIPS2.

Well, and why shouldn't an arch be allowed to use a ISA below it's
default _and_ it's arch specific insns in the same code?


Thiemo

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[H . J . Lu]

On Fri, Aug 17, 2001 at 11:47:35AM +0200, Thiemo Seufer wrote:
> H . J . Lu wrote:
> > On Fri, Aug 17, 2001 at 01:06:42AM +0200, Thiemo Seufer wrote:
> > > 
> > > [snip]
> > > > +  if (mips_opts.isa != mips_isa_from_cpu)
> > > > +    {
> > > > +      const struct mips_cpu_info *isa_ci;
> > > > +
> > > > +      /* -march=xxxx is not compatible with -mipsN. We use -mipsN to
> > > > +	 set the BFD arch.  */
> > > 
> > > Why should they be incompatible?
> > 
> > mips_isa_from_cpu set by -march=r5000 is ISA_MIPS4. But mips_opts.isa
> > from -mips2 is ISA_MIPS2.
> 
> Well, and why shouldn't an arch be allowed to use a ISA below it's
> default _and_ it's arch specific insns in the same code?

That is exactly what my patch does. With "-march=r5000 -mips2",
currently we set the ISA level to MIPS4 in BFD. That is my
original problem. My patch will change it to set the ISA level
to MIPS2 in BFD.

H.J.

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

H . J . Lu wrote:
[snip]
> > > > > +      /* -march=xxxx is not compatible with -mipsN. We use -mipsN to
> > > > > +	 set the BFD arch.  */
> > > > 
> > > > Why should they be incompatible?
> > > 
> > > mips_isa_from_cpu set by -march=r5000 is ISA_MIPS4. But mips_opts.isa
> > > from -mips2 is ISA_MIPS2.
> > 
> > Well, and why shouldn't an arch be allowed to use a ISA below it's
> > default _and_ it's arch specific insns in the same code?
> 
> That is exactly what my patch does.

No, your patch replaces the specified -march= by the default arch
for the also given -mips* option, while leaving -mtune= as is.

> With "-march=r5000 -mips2",
> currently we set the ISA level to MIPS4 in BFD. That is my
> original problem. My patch will change it to set the ISA level
> to MIPS2 in BFD.

With your patch,
    -march=r5000 -mips2
effectively results in
    -march=r6000 -mtune=r5000 -mips2


Thiemo

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[H . J . Lu]

On Fri, Aug 17, 2001 at 07:35:37PM +0200, Thiemo Seufer wrote:
> > > 
> > > Well, and why shouldn't an arch be allowed to use a ISA below it's
> > > default _and_ it's arch specific insns in the same code?
> > 
> > That is exactly what my patch does.
> 
> No, your patch replaces the specified -march= by the default arch
> for the also given -mips* option, while leaving -mtune= as is.

Only for BFD, not for assembler. Besides, when -mips2 is used with
-march=r5000, the assembler shouldn't use any instructions which are
in r5000, but not in MISP II.

> 
> > With "-march=r5000 -mips2",
> > currently we set the ISA level to MIPS4 in BFD. That is my
> > original problem. My patch will change it to set the ISA level
> > to MIPS2 in BFD.
> 
> With your patch,
>     -march=r5000 -mips2
> effectively results in
>     -march=r6000 -mtune=r5000 -mips2

Not exactly, my patches only applies -march=r6000 to the BFD flags. As
for the assembler, it is still -march=r5000 -mips2.


H.J.

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

H . J . Lu wrote:
> On Fri, Aug 17, 2001 at 07:35:37PM +0200, Thiemo Seufer wrote:
> > > > 
> > > > Well, and why shouldn't an arch be allowed to use a ISA below it's
> > > > default _and_ it's arch specific insns in the same code?
> > > 
> > > That is exactly what my patch does.
> > 
> > No, your patch replaces the specified -march= by the default arch
> > for the also given -mips* option, while leaving -mtune= as is.
> 
> Only for BFD, not for assembler. Besides, when -mips2 is used with
> -march=r5000, the assembler shouldn't use any instructions which are
> in r5000, but not in MISP II.

Well, now I can reiterate my question: Why shouldn't it do so?

Of course, in the case of r5000 this makes no difference since it
has no insns which aren't covered by an ISA (WRT binutils). An
example might be the VR4100: Restrict it to MIPS II but use it's
"standby" and "suspend" opcodes. With runtime CPU detection it is
easy to find a scenario where this makes sense.

> > > With "-march=r5000 -mips2",
> > > currently we set the ISA level to MIPS4 in BFD. That is my
> > > original problem. My patch will change it to set the ISA level
> > > to MIPS2 in BFD.
> > 
> > With your patch,
> >     -march=r5000 -mips2
> > effectively results in
> >     -march=r6000 -mtune=r5000 -mips2
> 
> Not exactly, my patches only applies -march=r6000 to the BFD flags. As
> for the assembler, it is still -march=r5000 -mips2.

Right. We are both talking about header flags, not code generation.


Thiemo

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[H . J . Lu]

On Fri, Aug 17, 2001 at 08:10:27PM +0200, Thiemo Seufer wrote:
> > 
> > Only for BFD, not for assembler. Besides, when -mips2 is used with
> > -march=r5000, the assembler shouldn't use any instructions which are
> > in r5000, but not in MISP II.
> 
> Well, now I can reiterate my question: Why shouldn't it do so?
> 
> Of course, in the case of r5000 this makes no difference since it
> has no insns which aren't covered by an ISA (WRT binutils). An
> example might be the VR4100: Restrict it to MIPS II but use it's
> "standby" and "suspend" opcodes. With runtime CPU detection it is
> easy to find a scenario where this makes sense.
> 

There are several problems:

1. When -mips2 is passed to as, should anything beyond MIPS II be
generated? My answer is no.
2. Assuming we do allow extra insns beyond MIPS II, what value should
be in EF_MIPS_ARCH? bfd_set_arch_mach is used to set EF_MIPS_ARCH.

In my opinion, if we do allow extra insns beyond MIPS II, we should
add a call to set EF_MIPS_MACH. That should be orthogonal to
EF_MIPS_ARCH. One way to do it to add

bfd_mach_mips1
bfd_mach_mips2
bfd_mach_mips3
bfd_mach_mips4

and we can do

bfd_set_arch_mach (stdoutput, bfd_arch_mips,
		   bfd_mach_mips2 | bfd_mach_mips4100);

We use bfd_mach_mips2 to set EF_MIPS_ARCH and bfd_mach_mips4100 to
set EF_MIPS_ARCH.


H.J.

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

H . J . Lu wrote:
> On Fri, Aug 17, 2001 at 08:10:27PM +0200, Thiemo Seufer wrote:
> > > 
> > > Only for BFD, not for assembler. Besides, when -mips2 is used with
> > > -march=r5000, the assembler shouldn't use any instructions which are
> > > in r5000, but not in MISP II.
> > 
> > Well, now I can reiterate my question: Why shouldn't it do so?
> > 
> > Of course, in the case of r5000 this makes no difference since it
> > has no insns which aren't covered by an ISA (WRT binutils). An
> > example might be the VR4100: Restrict it to MIPS II but use it's
> > "standby" and "suspend" opcodes. With runtime CPU detection it is
> > easy to find a scenario where this makes sense.
> > 
> 
> There are several problems:

0. Fiddling around with object file header flags in the assembler
is ugly, there should be an adequate bfd interface.

> 1. When -mips2 is passed to as, should anything beyond MIPS II be
> generated? My answer is no.
> 2. Assuming we do allow extra insns beyond MIPS II, what value should
> be in EF_MIPS_ARCH? bfd_set_arch_mach is used to set EF_MIPS_ARCH.

I don't see how bfd_default_set_arch_mach could do this. AFAICS it
sets the machine vector in the bfd, and EF_MIPS_ARCH is set by
_bfd_mips_elf_final_write_processing based on this vector only.

> In my opinion, if we do allow extra insns beyond MIPS II, we should
> add a call to set EF_MIPS_MACH. That should be orthogonal to
> EF_MIPS_ARCH. One way to do it to add
> 
> bfd_mach_mips1
> bfd_mach_mips2
> bfd_mach_mips3
> bfd_mach_mips4
> 
> and we can do
> 
> bfd_set_arch_mach (stdoutput, bfd_arch_mips,
> 		   bfd_mach_mips2 | bfd_mach_mips4100);
>
> We use bfd_mach_mips2 to set EF_MIPS_ARCH and bfd_mach_mips4100 to
> set EF_MIPS_ARCH.

bfd_default_set_arch_mach can't handle more than one mach, and
AFAICS everything assumes to get/store one distinct value via
this interface.

Strangely enough, the ChangeLog says that at 1999-04-15 Gavin Romig-Koch
introduced some code to set EF_MIPS_ARCH in the assembler and reverted
the patch the next day. I haven't found any trace of these in the
mailing list archives.


Thiemo

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[cgd]

ica2_ts@csv.ica.uni-stuttgart.de ("Thiemo Seufer") writes:
> Of course, in the case of r5000 this makes no difference since it
> has no insns which aren't covered by an ISA (WRT binutils). An
> example might be the VR4100: Restrict it to MIPS II but use it's
> "standby" and "suspend" opcodes. With runtime CPU detection it is
> easy to find a scenario where this makes sense.

right, so, my answer to "how do you do this" is:

-mipsN or -march=XXX sets the file-level flags and default options.

then, if you're doing runtime CPU detection and asm, or whatever, you
should do .set push ; .set whatever ; ... ; .set pop in your asm.

note that that implies the ability to set all of the random arch
values in .set directives like one could historically do .set mipsN.
I don't know if the binutils allow that with the most recent
arch-related patches, but if not, i'd recommend:

	.set arch=XXX

as the syntax.  8-)


cgd

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Andrew Cagney]

> 1. When -mips2 is passed to as, should anything beyond MIPS II be
> generated? My answer is no.
> 2. Assuming we do allow extra insns beyond MIPS II, what value should
> be in EF_MIPS_ARCH? bfd_set_arch_mach is used to set EF_MIPS_ARCH.

Just a heads up.  You want to be very careful when thinking about 
changing those EF flags.  GDB looks at them and interprets the result.

Rather than trying to ``fix'' the flags, you may be better off 
abandoning the current mechanism.

	Andrew

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

cgd@broadcom.com wrote:
> ica2_ts@csv.ica.uni-stuttgart.de ("Thiemo Seufer") writes:
> > Of course, in the case of r5000 this makes no difference since it
> > has no insns which aren't covered by an ISA (WRT binutils). An
> > example might be the VR4100: Restrict it to MIPS II but use it's
> > "standby" and "suspend" opcodes. With runtime CPU detection it is
> > easy to find a scenario where this makes sense.
> 
> right, so, my answer to "how do you do this" is:
> 
> -mipsN or -march=XXX sets the file-level flags and default options.
> 
> then, if you're doing runtime CPU detection and asm, or whatever, you
> should do .set push ; .set whatever ; ... ; .set pop in your asm.
> 
> note that that implies the ability to set all of the random arch
> values in .set directives like one could historically do .set mipsN.
> I don't know if the binutils allow that with the most recent
> arch-related patches, but if not, i'd recommend:
> 
> 	.set arch=XXX
> 
> as the syntax.  8-)

This looks nice, but it isn't implemented for now. And it doesn't
answer how the ELF header should look like in a case with both
-mipsN an -march=XXX, what can in the end be destilled in this
question:

   - Is EF_MIPS_MACH independent from EF_MIPS_ARCH or does it
     provide an override for EF_MIPS_ARCH for some cpu's?

Current behaviour is "override".

H.J.'s patch says also "override", but tells the assembler to fall
back to the most restrictive header flags while generating code
for the less restrictive settings.

My patch does a step towards "independent" and may break things.

Now, what's The Right Thing [TM] to do?

In my now changed opinion, the "independent" case violates the
K.I.S.S. principle without much gain. The "override" case OTOH
should maintain consistency between header flags and the actual
code, so -mipsN and -march=XXX should be _generally_ made
incompatible. If there is need for something like the scenario
above, Chris' scenario is AFAICS the best approach to solve it.


Thiemo

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[H . J . Lu]

On Sat, Aug 18, 2001 at 03:01:13PM +0200, Thiemo Seufer wrote:
> 
> This looks nice, but it isn't implemented for now. And it doesn't
> answer how the ELF header should look like in a case with both
> -mipsN an -march=XXX, what can in the end be destilled in this
> question:
> 
>    - Is EF_MIPS_MACH independent from EF_MIPS_ARCH or does it
>      provide an override for EF_MIPS_ARCH for some cpu's?
> 
> Current behaviour is "override".
> 
> H.J.'s patch says also "override", but tells the assembler to fall
> back to the most restrictive header flags while generating code
> for the less restrictive settings.
> 
> My patch does a step towards "independent" and may break things.
> 
> Now, what's The Right Thing [TM] to do?
> 
> In my now changed opinion, the "independent" case violates the
> K.I.S.S. principle without much gain. The "override" case OTOH
> should maintain consistency between header flags and the actual
> code, so -mipsN and -march=XXX should be _generally_ made
> incompatible. If there is need for something like the scenario

I think it is not a bad idea. We can do

  if (mips_opts.isa != mips_isa_from_cpu)
    {
      /* -march=xxxx is not compatible with -mipsN.  */
      Issue a warning and abort.
    }

In fact, I have changed my CFLAGS from "-march=r5000 -mips2" to
"-mtune=r5000 -mips2". The problem with this approach is only
gcc 3.1 and my current mips toolchain support -mtune=r5000. Maybe
we should just add a warning to my patch, saying please use
"-mtune=XXX -mipsN" instead of "-march=XXX -mipsN".


H.J.

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

H . J . Lu wrote:
[snip]
> I think it is not a bad idea. We can do
> 
>   if (mips_opts.isa != mips_isa_from_cpu)
>     {
>       /* -march=xxxx is not compatible with -mipsN.  */
>       Issue a warning and abort.
>     }
> 
> In fact, I have changed my CFLAGS from "-march=r5000 -mips2" to
> "-mtune=r5000 -mips2". The problem with this approach is only
> gcc 3.1 and my current mips toolchain support -mtune=r5000. Maybe
> we should just add a warning to my patch, saying please use
> "-mtune=XXX -mipsN" instead of "-march=XXX -mipsN".

I would suggest this patch.


Thiemo


2001-08-18  Thiemo Seufer <seufer@csv.ica.uni-stuttgart.de>

	/gas/ChangeLog
	* tc_mips.c (md_begin): Warn about incompatibility between -march=FOO
	and -mipsN option, continue with default ISA.


diff -BurpNX /bigdisk/src/binutils-exclude src-orig/gas/config/tc-mips.c src/gas/config/tc-mips.c
--- src-orig/gas/config/tc-mips.c	Sun Aug 12 13:34:58 2001
+++ src/gas/config/tc-mips.c	Sat Aug 18 17:54:58 2001
@@ -996,7 +1015,20 @@ md_begin ()
      the command line, or will be set otherwise if one was.  */
   if (mips_arch != CPU_UNKNOWN && mips_opts.isa != ISA_UNKNOWN)
     {
-      /* We have it all.  There's nothing to do.  */
+      /* We have to check if the isa is the default isa of arch.  Otherwise
+         we'll get invalid object file headers.  */
+      ci = mips_cpu_info_from_cpu (mips_arch);
+      assert (ci != NULL);
+      if (mips_opts.isa != ci->isa)
+	{
+	  /* This really should be an error instead of a warning, but old
+	     compilers only have -mcpu which sets both arch and tune.  */
+	  as_warn (_("The -march option is incompatible to -mipsN and "
+		     "therefore ignored."));
+	  ci = mips_cpu_info_from_isa (mips_opts.isa);
+	  assert (ci != NULL);
+	  mips_arch = ci->cpu;
+	}
     }
   else if (mips_arch != CPU_UNKNOWN && mips_opts.isa == ISA_UNKNOWN)
     {

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[H . J . Lu]

On Sat, Aug 18, 2001 at 06:33:40PM +0200, Thiemo Seufer wrote:
> H . J . Lu wrote:
> [snip]
> > I think it is not a bad idea. We can do
> > 
> >   if (mips_opts.isa != mips_isa_from_cpu)
> >     {
> >       /* -march=xxxx is not compatible with -mipsN.  */
> >       Issue a warning and abort.
> >     }
> > 
> > In fact, I have changed my CFLAGS from "-march=r5000 -mips2" to
> > "-mtune=r5000 -mips2". The problem with this approach is only
> > gcc 3.1 and my current mips toolchain support -mtune=r5000. Maybe
> > we should just add a warning to my patch, saying please use
> > "-mtune=XXX -mipsN" instead of "-march=XXX -mipsN".
> 
> I would suggest this patch.
> 
> 
> Thiemo
> 
> 
> 2001-08-18  Thiemo Seufer <seufer@csv.ica.uni-stuttgart.de>
> 
> 	/gas/ChangeLog
> 	* tc_mips.c (md_begin): Warn about incompatibility between -march=FOO
> 	and -mipsN option, continue with default ISA.
> 

I disagree. I think mips_tune should be set by -march=FOO in this case.

> 
> diff -BurpNX /bigdisk/src/binutils-exclude src-orig/gas/config/tc-mips.c src/gas/config/tc-mips.c
> --- src-orig/gas/config/tc-mips.c	Sun Aug 12 13:34:58 2001
> +++ src/gas/config/tc-mips.c	Sat Aug 18 17:54:58 2001
> @@ -996,7 +1015,20 @@ md_begin ()
>       the command line, or will be set otherwise if one was.  */
>    if (mips_arch != CPU_UNKNOWN && mips_opts.isa != ISA_UNKNOWN)
>      {
> -      /* We have it all.  There's nothing to do.  */
> +      /* We have to check if the isa is the default isa of arch.  Otherwise
> +         we'll get invalid object file headers.  */
> +      ci = mips_cpu_info_from_cpu (mips_arch);
> +      assert (ci != NULL);
> +      if (mips_opts.isa != ci->isa)
> +	{
> +	  /* This really should be an error instead of a warning, but old
> +	     compilers only have -mcpu which sets both arch and tune.  */
> +	  as_warn (_("The -march option is incompatible to -mipsN and "
> +		     "therefore ignored."));
> +	  ci = mips_cpu_info_from_isa (mips_opts.isa);
> +	  assert (ci != NULL);

Add

	  if (mips_tune == CPU_UNKNOWN)
	     mips_tune = mips_arch;


> +	  mips_arch = ci->cpu;
> +	}
>      }
>    else if (mips_arch != CPU_UNKNOWN && mips_opts.isa == ISA_UNKNOWN)
>      {


H.J.

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

H . J . Lu wrote:
[snip]
> > 2001-08-18  Thiemo Seufer <seufer@csv.ica.uni-stuttgart.de>
> > 
> > 	/gas/ChangeLog
> > 	* tc_mips.c (md_begin): Warn about incompatibility between -march=FOO
> > 	and -mipsN option, continue with default ISA.
> > 
> 
> I disagree. I think mips_tune should be set by -march=FOO in this case.

Oops, right. Next try below.


Thiemo


2001-08-18  Thiemo Seufer <seufer@csv.ica.uni-stuttgart.de>

	/gas/ChangeLog
	* tc_mips.c (md_begin): Warn about incompatibility between -march=FOO
	and -mipsN option, continue with default ISA.


diff -BurpNX /bigdisk/src/binutils-exclude src-orig/gas/config/tc-mips.c src/gas/config/tc-mips.c
--- src-orig/gas/config/tc-mips.c	Sun Aug 12 13:34:58 2001
+++ src/gas/config/tc-mips.c	Sat Aug 18 18:56:00 2001
@@ -996,7 +1015,23 @@ md_begin ()
      the command line, or will be set otherwise if one was.  */
   if (mips_arch != CPU_UNKNOWN && mips_opts.isa != ISA_UNKNOWN)
     {
-      /* We have it all.  There's nothing to do.  */
+      /* We have to check if the isa is the default isa of arch.  Otherwise
+         we'll get invalid object file headers.  */
+      ci = mips_cpu_info_from_cpu (mips_arch);
+      assert (ci != NULL);
+      if (mips_opts.isa != ci->isa)
+	{
+	  /* This really should be an error instead of a warning, but old
+	     compilers only have -mcpu which sets both arch and tune.  For
+	     now, we discard arch and preserve tune.  */
+	  as_warn (_("The -march option is incompatible to -mipsN and "
+		     "therefore ignored."));
+	  if (mips_tune == CPU_UNKNOWN)
+	    mips_tune = mips_arch;
+	  ci = mips_cpu_info_from_isa (mips_opts.isa);
+	  assert (ci != NULL);
+	  mips_arch = ci->cpu;
+	}
     }
   else if (mips_arch != CPU_UNKNOWN && mips_opts.isa == ISA_UNKNOWN)
     {

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[H . J . Lu]

On Sat, Aug 18, 2001 at 07:04:13PM +0200, Thiemo Seufer wrote:
> H . J . Lu wrote:
> [snip]
> > > 2001-08-18  Thiemo Seufer <seufer@csv.ica.uni-stuttgart.de>
> > > 
> > > 	/gas/ChangeLog
> > > 	* tc_mips.c (md_begin): Warn about incompatibility between -march=FOO
> > > 	and -mipsN option, continue with default ISA.
> > > 
> > 
> > I disagree. I think mips_tune should be set by -march=FOO in this case.
> 
> Oops, right. Next try below.
> 
> 
> Thiemo
> 
> 
> 2001-08-18  Thiemo Seufer <seufer@csv.ica.uni-stuttgart.de>
> 
> 	/gas/ChangeLog
> 	* tc_mips.c (md_begin): Warn about incompatibility between -march=FOO
> 	and -mipsN option, continue with default ISA.
> 
> 
> diff -BurpNX /bigdisk/src/binutils-exclude src-orig/gas/config/tc-mips.c src/gas/config/tc-mips.c
> --- src-orig/gas/config/tc-mips.c	Sun Aug 12 13:34:58 2001
> +++ src/gas/config/tc-mips.c	Sat Aug 18 18:56:00 2001
> @@ -996,7 +1015,23 @@ md_begin ()
>       the command line, or will be set otherwise if one was.  */
>    if (mips_arch != CPU_UNKNOWN && mips_opts.isa != ISA_UNKNOWN)
>      {
> -      /* We have it all.  There's nothing to do.  */
> +      /* We have to check if the isa is the default isa of arch.  Otherwise
> +         we'll get invalid object file headers.  */
> +      ci = mips_cpu_info_from_cpu (mips_arch);
> +      assert (ci != NULL);
> +      if (mips_opts.isa != ci->isa)
> +	{
> +	  /* This really should be an error instead of a warning, but old
> +	     compilers only have -mcpu which sets both arch and tune.  For
> +	     now, we discard arch and preserve tune.  */
> +	  as_warn (_("The -march option is incompatible to -mipsN and "
> +		     "therefore ignored."));
> +	  if (mips_tune == CPU_UNKNOWN)
> +	    mips_tune = mips_arch;
> +	  ci = mips_cpu_info_from_isa (mips_opts.isa);
> +	  assert (ci != NULL);
> +	  mips_arch = ci->cpu;
> +	}
>      }
>    else if (mips_arch != CPU_UNKNOWN && mips_opts.isa == ISA_UNKNOWN)
>      {

It works for me.


H.J.

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[cgd]

It would probably be good if Eric spoke up about his intentions
here...  8-)


so one thing that i don't get, from all of these discussions and
patches is, why _are_ we still maintaining the notion of 'isa' as
separate from 'architecture' in the code?

If the desire with these flags was to move in the direction of the way
arch/cpu selection is done for other architectures (in the compiler
and assembler), shouldn't -mips1 become a synonym for "-march=mips1"?

(of course, you can also say e.g. -march=cputype, which means "use the
base architecture + extensions.)

If you're going there, with switches like:

	-mips1 -march=FOO

-mips1 is irrelevant, completely overridden by -march=FOO.


I think if the desire is to eventually implement something like:

	.set arch=cpu

in the assembler (and similarly .set arch=mipsN as the new version of
.set mipsN), the arch selection and ISA selection need to be
unified in one place...



chris

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

cgd@broadcom.com wrote:
> It would probably be good if Eric spoke up about his intentions
> here...  8-)

I'm waiting for his intervention. :-)

> so one thing that i don't get, from all of these discussions and
> patches is, why _are_ we still maintaining the notion of 'isa' as
> separate from 'architecture' in the code?

Well, it's because of historic reasons I assume. Gas mimics the
native MIPS (SGI) assembler which uses -mipsN and -{32,n32,64} to
decide about ABI and cpu type in a rather opaque manner.
With the myriads of embedded cpu's this wasn't viable any more, so
-mcpu was invented and lately split up in -march and -mtune.
Now we sit in the mess and have to support a compiler which has
only -mcpu=FOO ATM.

> If the desire with these flags was to move in the direction of the way
> arch/cpu selection is done for other architectures (in the compiler
> and assembler), shouldn't -mips1 become a synonym for "-march=mips1"?

It currently is a synonym for -march=r3000 if invoked correctly.
Introducing a generic arch for the old ISA's would be cleaner but
isn't really needed IMHO. My latest patch cares about "incorrect"
invocation as it might be done by GCC 3.0.

> If you're going there, with switches like:
> 
> 	-mips1 -march=FOO
> 
> -mips1 is irrelevant, completely overridden by -march=FOO.

That's the way it should be IMHO. When -mcpu gets deprecated, we can
get there and drop the ISA-dependent handling in gas. We could even
remove -mipsN as redundant, and hopefully also -{32,64}. My idea of
these options is:

	-arch=FOO	allowed insns, max register widths
	-tune=FOO	scheduling
	-mabi=BAR	ABI to conform to
	-m[fg]p=32	non-ABI-conformant register width reduction

Is command line compatibility to other assemblers an issue?


Thiemo

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Eric Christopher]

> I'm waiting for his intervention. :-)
> 

Here we go:

> > so one thing that i don't get, from all of these discussions and
> > patches is, why _are_ we still maintaining the notion of 'isa' as
> > separate from 'architecture' in the code?
> 
> Well, it's because of historic reasons I assume. Gas mimics the
> native MIPS (SGI) assembler which uses -mipsN and -{32,n32,64} to
> decide about ABI and cpu type in a rather opaque manner.
> With the myriads of embedded cpu's this wasn't viable any more, so
> -mcpu was invented and lately split up in -march and -mtune.
> Now we sit in the mess and have to support a compiler which has
> only -mcpu=FOO ATM.
> 

Only ATM. The current trunk has it split up into -march and -mtune.
-mcpu and -m<foo> is still valid, but deprecated (and in the case of
-m<foo> worked around via specs files).

> > If the desire with these flags was to move in the direction of the way
> > arch/cpu selection is done for other architectures (in the compiler
> > and assembler), shouldn't -mips1 become a synonym for "-march=mips1"?
> 
> It currently is a synonym for -march=r3000 if invoked correctly.
> Introducing a generic arch for the old ISA's would be cleaner but
> isn't really needed IMHO. My latest patch cares about "incorrect"
> invocation as it might be done by GCC 3.0.
> 

Right...

> > If you're going there, with switches like:
> > 
> > 	-mips1 -march=FOO
> > 
> > -mips1 is irrelevant, completely overridden by -march=FOO.
> 
> That's the way it should be IMHO. When -mcpu gets deprecated, we can
> get there and drop the ISA-dependent handling in gas. We could even
> remove -mipsN as redundant, and hopefully also -{32,64}. My idea of
> these options is:
> 
> 	-arch=FOO	allowed insns, max register widths
> 	-tune=FOO	scheduling
> 	-mabi=BAR	ABI to conform to
> 	-m[fg]p=32	non-ABI-conformant register width reduction
> 
> Is command line compatibility to other assemblers an issue?

Not that I know of - though I'd prefer if Ian were to speak up here and
let me know if it is the case.

Personally I agree with this assessment - though we should keep the
-mipsX options for compatability. They can simply be aliases like I'd
planned all along though. R3000, R4000, R5000, R8000 I believe (he says
without looking...)?

Oh yes, your patch is approved as well.

-eric

-- 
Look out behind you!

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Eric Christopher]

On 19 Aug 2001 00:23:09 +0200, Thiemo Seufer wrote:
> cgd@broadcom.com wrote:
> > It would probably be good if Eric spoke up about his intentions
> > here...  8-)
> 
> I'm waiting for his intervention. :-)
> 

Ok.  I just flew back from the UK this weekend (and boy are my arms
tired...).  I have a lot of mail to look at, but I'll get to this as
soon as I'm able.

-eric

-- 
Look out behind you!

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Ian Lance Taylor]

Eric Christopher <echristo@redhat.com> writes:

> > Is command line compatibility to other assemblers an issue?
> 
> Not that I know of - though I'd prefer if Ian were to speak up here and
> let me know if it is the case.

All MIPS assemblers take -mips1, -mips2, etc., to select the ISA.
Other than that, I don't think there is any compatibility issue.  Most
existing MIPS assemblers are of course just for a particular host, and
don't worry about many different CPU options.

If anybody has access to a current Irix system, it might be
interesting to see the range of options the assembler accepts there.

Of course it's important to consider how gcc is going to invoke the
assembler.

Ian

Re: Does -march=r5000 imply HAVE_64BIT_GPRS?

[Thiemo Seufer]

Ian Lance Taylor wrote:
> Eric Christopher <echristo@redhat.com> writes:
> 
> > > Is command line compatibility to other assemblers an issue?
> > 
> > Not that I know of - though I'd prefer if Ian were to speak up here and
> > let me know if it is the case.
> 
> All MIPS assemblers take -mips1, -mips2, etc., to select the ISA.
> Other than that, I don't think there is any compatibility issue.  Most
> existing MIPS assemblers are of course just for a particular host, and
> don't worry about many different CPU options.
> 
> If anybody has access to a current Irix system, it might be
> interesting to see the range of options the assembler accepts there.

This is what the Manpage says:

ISA/ABI COMMAND LINE OPTIONS
     The following options control the choice of ABI and Instruction Set
     Architecture (ISA).

     -o32 or -32    Generate a 32-bit object.  This defaults to -mips2 if
                    -mips1 is not specified.  This is the default when
                    compiling on any non-R8000 based system, if no default
                    specification file is present.  See the o32(5) man page
                    for details.

     -64            Generate a 64-bit object.  This defaults to -mips4 if
                    -mips3 is not specified.  This is the default when
                    compiling on any R8000 based system, if no default
                    specification file is present.  See the Defaults
                    Specification Files subsection at the end of this man
                    page for details.

     -n32           Generate an n32 object.  This defaults to -mips3 if
                    -mips4 is not specified.

     -mipsn         Determine architecture type. n can be one of the
                    following values:

                    1    Generate code using the instruction set of the
                         R2000/R3000 RISC architecture, and search for
                         mips1 libraries/objects at link time.  This
                         defaults to -o32.

                    2    Generate code using the MIPS II instruction set
                         (MIPS I + R4000 specific extensions), and search
                         for mips2 libraries/objects at link time.  This
                         defaults to -o32.

                    3    Generate code using the full MIPS III (e.g. R4000)
                         instruction set, and search for mips3
                         libraries/objects at link time.  This defaults to
                         -n32 if -64 has not been specified.  On R8000-
                         based systems this defaults to -64.

                    4    Generate code using the full MIPS IV instruction
                         set which is supported on R10000, R5000 and R8000
                         systems.  Also search for mips4 libraries/objects
                         at link time.  This is the default on R8000
                         systems.  This defaults to -n32 if -64 is not
                         specified.  On R8000-based systems it defaults to
                         -64.

AFAIK SGI never built Machines with R6000, so MIPS II is called a
"R4000 specific extension".


Thiemo