PATCH: More mips3264 support

PATCH: More mips3264 support

[Eric Christopher]

This adds a few things that I need to put mips3264 support into the
compiler.  It basically contains a few additional instructions and
support for options to the linker and assembler.

I figure I'll put this up for Nick's approval since someone should look
at my changes :)

I'm also importing the current config.sub from gcc and adding support
for the configure target.  Though I'm not sure what the proper procedure
for this is - I'm sure Ben will tell me.

-eric

--
Look out behind you!

src/ChangeLog
2001-07-19  Eric Christopher  <echristo@redhat.com>
	    Jason Eckhardt  <jle@redhat.com>

	* config.sub: Import from gcc.  Add support for mipsisa32.

src/opcodes/ChangeLog
2001-07-19  Eric Christopher  <echristo@redhat.com>
	    Jason Eckhardt    <jle@redhat.com>

	* mips-opc.c: Add support for dmfc1, dmtc1, dmtc2, additional modes
	for mfc1 and mtc1.
	* mips-dis.c: Add support for bfd_mach_mipsisa32 and
	bfd_mach_mipsisa64.

src/ld/ChangeLog
2001-07-19  Eric Christopher  <echristo@redhat.com>
	    Jason Eckhardt  <jle@redhat.com>

	* ldmain.c (get_emulation): Add support for -mips32 and -mips64.

src/bfd/ChangeLog
2001-07-19  Eric Christopher  <echristo@redhat.com>
	    Jason Eckhardt  <jle@redhat.com>

	* bfd/archures.c: Add mipsisa32 and mipsisa64.
	* bfd/cpu-mips.c: Ditto.
	* bfd/elf32-mips.c (_bfd_mips_elf_final_write_processing): Ditto.

src/gas/ChangeLog
2001-07-19  Eric Christopher  <echristo@redhat.com>
	    Jason Eckhardt  <jle@redhat.com>

	* config/tc-mips.c (mips_cpu_info): Add support for mipsisa32,
	5kc, and 20kc.

2001-07-19  Eric Christopher  <echristo@redhat.com>
	    Jason Eckhardt    <jle@redhat.com>

	* mips-opc.c: Add support for dmfc1, dmtc1, dmtc2, additional modes
	for mfc1 and mtc1.
	* mips-dis.c: Add support for bfd_mach_mipsisa32 and
	bfd_mach_mipsisa64.

Index: config.sub
===================================================================
RCS file: /cvs/src/src/config.sub,v
retrieving revision 1.20
diff -u -p -w -r1.20 config.sub
--- config.sub	2001/03/22 11:09:20	1.20
+++ config.sub	2001/07/21 10:14:04
@@ -3,7 +3,7 @@
 #   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001
 #   Free Software Foundation, Inc.
 
-timestamp='2001-03-19'
+timestamp='2001-07-19'
 
 # This file is (in principle) common to ALL GNU software.
 # The presence of a machine in this file suggests that SOME GNU software
@@ -117,7 +117,7 @@ esac
 # Here we must recognize all the valid KERNEL-OS combinations.
 maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
 case $maybe_os in
-  nto-qnx* | linux-gnu* | storm-chaos* | os2-emx*)
+  nto-qnx* | linux-gnu* | storm-chaos* | os2-emx* | windows32-*)
     os=-$maybe_os
     basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
     ;;
@@ -157,6 +157,14 @@ case $os in
 		os=-vxworks
 		basic_machine=$1
 		;;
+	-chorusos*)
+		os=-chorusos
+		basic_machine=$1
+		;;
+ 	-chorusrdb)
+ 		os=-chorusrdb
+		basic_machine=$1
+ 		;;
 	-hiux*)
 		os=-hiuxwe2
 		;;
@@ -230,10 +238,12 @@ case $basic_machine in
 		| mips16 | mips64 | mipsel | mips64el \
 		| mips64orion | mips64orionel | mipstx39 | mipstx39el \
 		| mips64vr4300 | mips64vr4300el | mips64vr4100 | mips64vr4100el \
-		| mips64vr5000 | miprs64vr5000el | mcore | s390 | s390x \
-		| sparc | sparclet | sparclite | sparc64 | sparcv9 | v850 | c4x \
+		| mips64vr5000 | mips64vr5000el | mipsisa32 | mipsisa32el \
+		| mcore | s390 | s390x \
+		| sparc | sparclet | sparclite | sparc64 | sparcv9 | sparcv9b \
+		| v850 | c4x \
 		| thumb | d10v | d30v | fr30 | avr | openrisc | tic80 \
-		| pj | pjl | h8500)
+		| pj | pjl | h8500 | z8k)
 		basic_machine=$basic_machine-unknown
 		;;
 	m6811 | m68hc11 | m6812 | m68hc12)
@@ -241,13 +251,13 @@ case $basic_machine in
 		basic_machine=$basic_machine-unknown
 		os=-none
 		;;
-	m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | z8k | v70 | w65)
+	m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | v70 | w65 | z8k)
 		;;
 
 	# We use `pc' rather than `unknown'
 	# because (1) that's what they normally are, and
 	# (2) the word "unknown" tends to confuse beginning users.
-	i[234567]86 | x86_64)
+	i*86 | x86_64)
 	  basic_machine=$basic_machine-pc
 	  ;;
 	# Object if more than one company name word.
@@ -257,7 +267,7 @@ case $basic_machine in
 		;;
 	# Recognize the basic CPU types with company name.
 	# FIXME: clean up the formatting here.
-	vax-* | tahoe-* | i[234567]86-* | i860-* | ia64-* | m32r-* | m68k-* | m68000-* \
+	vax-* | tahoe-* | i*86-* | i860-* | ia64-* | m32r-* | m68k-* | m68000-* \
 	      | m88k-* | sparc-* | ns32k-* | fx80-* | arc-* | c[123]* \
 	      | arm-*  | armbe-* | armle-* | armv*-* | strongarm-* | xscale-* \
 	      | mips-* | pyramid-* | tron-* | a29k-* | romp-* | rs6000-* \
@@ -270,11 +280,12 @@ case $basic_machine in
 	      | alphaev6[78]-* \
 	      | we32k-* | cydra-* | ns16k-* | pn-* | np1-* | xps100-* \
 	      | clipper-* | orion-* \
-	      | sparclite-* | pdp10-* | pdp11-* | sh-* | powerpc-* | powerpcle-* \
-	      | sparc64-* | sparcv9-* | sparc86x-* | mips16-* | mips64-* | mipsel-* \
+	      | sparclite-* | pdp10-* | pdp11-* | sh-* | sh[34]-* | sh[34]eb-* \
+	      | powerpc-* | powerpcle-* | sparc64-* | sparcv9-* | sparcv9b-* | sparc86x-* \
+	      | mips16-* | mips64-* | mipsel-* \
 	      | mips64el-* | mips64orion-* | mips64orionel-* \
 	      | mips64vr4100-* | mips64vr4100el-* | mips64vr4300-* | mips64vr4300el-* \
-	      | mipstx39-* | mipstx39el-* | mcore-* \
+	      | mipstx39-* | mipstx39el-* | mipsisa32-* | mipsisa32el-* | mcore-* \
 	      | f30[01]-* | f700-* | s390-* | s390x-* | sv1-* | t3e-* \
 	      | [cjt]90-* \
 	      | m88110-* | m680[01234]0-* | m683?2-* | m68360-* | z8k-* | d10v-* \
@@ -506,19 +517,19 @@ case $basic_machine in
 		basic_machine=i370-ibm
 		;;
 # I'm not sure what "Sysv32" means.  Should this be sysv3.2?
-	i[34567]86v32)
+	i*86v32)
 		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
 		os=-sysv32
 		;;
-	i[34567]86v4*)
+	i*86v4*)
 		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
 		os=-sysv4
 		;;
-	i[34567]86v)
+	i*86v)
 		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
 		os=-sysv
 		;;
-	i[34567]86sol2)
+	i*86sol2)
 		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
 		os=-solaris2
 		;;
@@ -879,6 +890,10 @@ case $basic_machine in
 		basic_machine=hppa1.1-winbond
 		os=-proelf
 		;;
+	windows32)
+		basic_machine=i386-pc
+		os=-windows32-msvcrt
+		;;
 	xmp)
 		basic_machine=xmp-cray
 		os=-unicos
@@ -935,7 +950,7 @@ case $basic_machine in
 	sh3 | sh4)
 		basic_machine=sh-unknown
 		;;
-	sparc | sparcv9)
+	sparc | sparcv9 | sparcv9b)
 		basic_machine=sparc-sun
 		;;
         cydra)
@@ -957,6 +972,9 @@ case $basic_machine in
 		basic_machine=c4x-none
 		os=-coff
 		;;
+	*-unknown)
+		# Make sure to match an already-canonicalized machine name.
+		;;
 	*)
 		echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2
 		exit 1
@@ -1013,6 +1031,7 @@ case $os in
 	      | -lynxos* | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \
 	      | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \
 	      | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \
+	      | -chorusos* | -chorusrdb* \
 	      | -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \
 	      | -mingw32* | -linux-gnu* | -uxpv* | -beos* | -mpeix* | -udk* \
 	      | -interix* | -uwin* | -rhapsody* | -darwin* | -opened* \
@@ -1022,7 +1041,7 @@ case $os in
 		;;
 	-qnx*)
 		case $basic_machine in
-		    x86-* | i[34567]86-*)
+		    x86-* | i*86-*)
 			;;
 		    *)
 			os=-nto$os
Index: bfd/archures.c
===================================================================
RCS file: /cvs/src/src/bfd/archures.c,v
retrieving revision 1.36
diff -u -p -w -r1.36 archures.c
--- archures.c	2001/05/23 17:26:35	1.36
+++ archures.c	2001/07/21 10:14:06
@@ -142,6 +142,8 @@ DESCRIPTION
 .#define bfd_mach_mips5                 5
 .#define bfd_mach_mips64                64
 .#define bfd_mach_mips_sb1              12310201 {* octal 'SB', 01 *}
+.#define bfd_mach_mipsisa32             99032
+.#define bfd_mach_mipsisa64             99064
 .  bfd_arch_i386,      {* Intel 386 *}
 .#define bfd_mach_i386_i386 0
 .#define bfd_mach_i386_i8086 1
Index: bfd/cpu-mips.c
===================================================================
RCS file: /cvs/src/src/bfd/cpu-mips.c,v
retrieving revision 1.9
diff -u -p -w -r1.9 cpu-mips.c
--- cpu-mips.c	2001/05/23 17:26:35	1.9
+++ cpu-mips.c	2001/07/21 10:14:06
@@ -61,6 +61,8 @@ enum
   I_mips32_4k,
   I_mips5,
   I_mips64,
+  I_mipsisa32,
+  I_mipsisa64,
   I_sb1,
 };
 
@@ -89,6 +91,8 @@ static const bfd_arch_info_type arch_inf
   N (64, 64, bfd_mach_mips5,    "mips:mips5",     false, NN(I_mips5)),
   N (64, 64, bfd_mach_mips64,   "mips:mips64",    false, NN(I_mips64)),
   N (64, 64, bfd_mach_mips_sb1, "mips:sb1",       false, 0),
+  N (32, 32, bfd_mach_mipsisa32,  "mips:isa32",   false, NN(I_mipsisa32)),
+  N (64, 64, bfd_mach_mipsisa64,  "mips:isa64",   false, NN(I_mipsisa64)),
 };
 
 /* The default architecture is mips:3000, but with a machine number of
Index: bfd/elf32-mips.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-mips.c,v
retrieving revision 1.103
diff -u -p -w -r1.103 elf32-mips.c
--- elf32-mips.c	2001/07/04 07:15:20	1.103
+++ elf32-mips.c	2001/07/21 10:14:15
@@ -2422,6 +2422,13 @@ _bfd_mips_elf_final_write_processing (ab
     case bfd_mach_mips_sb1:
       val = E_MIPS_ARCH_64 | E_MIPS_MACH_SB1;
       break;
+
+    case bfd_mach_mipsisa32:
+      val = E_MIPS_ARCH_32;
+      break;
+
+    case bfd_mach_mipsisa64:
+      val = E_MIPS_ARCH_64;
     }
 
   elf_elfheader (abfd)->e_flags &= ~(EF_MIPS_ARCH | EF_MIPS_MACH);
Index: gas/config/tc-mips.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-mips.c,v
retrieving revision 1.51
diff -u -p -w -r1.51 tc-mips.c
--- tc-mips.c	2001/07/04 12:32:07	1.51
+++ tc-mips.c	2001/07/21 10:14:26
@@ -12074,6 +12074,7 @@ static const struct mips_cpu_info mips_c
   /* MIPS32 ISA */
   { "MIPS32",         1,      ISA_MIPS32,     CPU_MIPS32, },
   { "Generic-MIPS32", 0,      ISA_MIPS32,     CPU_MIPS32, },
+  { "mipsisa32",      0,      ISA_MIPS32,     CPU_MIPS32, },
 
 #if 1
   /* XXX for now, MIPS64 -> MIPS3 because of history */
@@ -12084,6 +12085,10 @@ static const struct mips_cpu_info mips_c
 #endif
   { "mips64isa",      1,      ISA_MIPS64,     CPU_MIPS64 },
   { "Generic-MIPS64", 0,      ISA_MIPS64,     CPU_MIPS64, },
+  { "5kc",            0,      ISA_MIPS64,     CPU_MIPS64, },
+  { "5Kc",            0,      ISA_MIPS64,     CPU_MIPS64, },
+  { "20kc",           0,      ISA_MIPS64,     CPU_MIPS64, },
+  { "20Kc",           0,      ISA_MIPS64,     CPU_MIPS64, },
 
   /* R2000 CPU */
   { "R2000",          0,      ISA_MIPS1,      CPU_R2000, },
Index: include/opcode/mips.h
===================================================================
RCS file: /cvs/src/src/include/opcode/mips.h,v
retrieving revision 1.15
diff -u -p -w -r1.15 mips.h
--- mips.h	2001/05/23 17:26:39	1.15
+++ mips.h	2001/07/21 10:14:27
@@ -228,6 +228,7 @@ struct mips_opcode
    "<>(),"
    "ABCDEFGHIJLMNPRSTUVW"
    "abcdfhijklopqrstuvwxz"
+
 */
 
 /* These are the bits which may be set in the pinfo field of an
Index: ld/ldmain.c
===================================================================
RCS file: /cvs/src/src/ld/ldmain.c,v
retrieving revision 1.25
diff -u -p -w -r1.25 ldmain.c
--- ldmain.c	2001/07/11 19:50:56	1.25
+++ ldmain.c	2001/07/21 10:14:28
@@ -511,6 +511,8 @@ get_emulation (argc, argv)
 	  else if (strcmp (argv[i], "-mips1") == 0
 		   || strcmp (argv[i], "-mips2") == 0
 		   || strcmp (argv[i], "-mips3") == 0
+		   || strcmp (argv[i], "-mips32") == 0
+		   || strcmp (argv[i], "-mips64") == 0
 		   || strcmp (argv[i], "-mips4") == 0
 		   || strcmp (argv[i], "-mips5") == 0)
 	    {
Index: opcodes/mips-dis.c
===================================================================
RCS file: /cvs/src/src/opcodes/mips-dis.c,v
retrieving revision 1.16
diff -u -p -w -r1.16 mips-dis.c
--- mips-dis.c	2001/05/23 17:26:40	1.16
+++ mips-dis.c	2001/07/21 10:14:35
@@ -388,6 +388,15 @@ mips_isa_type (mach, isa, cputype)
       *cputype = CPU_SB1;
       *isa = ISA_MIPS64;
       break;
+    case bfd_mach_mipsisa32:
+      * cputype = CPU_MIPS32;
+      * isa = ISA_MIPS32;
+      break;
+    case bfd_mach_mipsisa64:
+      * cputype = CPU_MIPS64;
+      * isa = ISA_MIPS64;
+      break;
+
     default:
       *cputype = CPU_R3000;
       *isa = ISA_MIPS3;
Index: opcodes/mips-opc.c
===================================================================
RCS file: /cvs/src/src/opcodes/mips-opc.c,v
retrieving revision 1.22
diff -u -p -w -r1.22 mips-opc.c
--- mips-opc.c	2001/06/22 21:10:01	1.22
+++ mips-opc.c	2001/07/21 10:14:35
@@ -401,14 +401,18 @@ const struct mips_opcode mips_builtin_op
 {"dmfc0",   "t,G,H",    0x40200000, 0xffe007f8, LCD|WR_t|RD_C0, 	I64     },
 {"dmtc0",   "t,G",	0x40a00000, 0xffe007ff, COD|RD_t|WR_C0|WR_CC,	I3	},
 {"dmtc0",   "t,G,H",    0x40a00000, 0xffe007f8, COD|RD_t|WR_C0|WR_CC,   I64     },
+{"dmfc1",   "t,S,H",    0x44200000, 0xffe007f8, LCD|WR_t|RD_S|FP_S,     I64},
 {"dmfc1",   "t,S",	0x44200000, 0xffe007ff, LCD|WR_t|RD_S|FP_S,	I3	},
 {"dmfc1",   "t,G",      0x44200000, 0xffe007ff, LCD|WR_t|RD_S|FP_S,     I3      },
+{"dmtc1",   "t,S,H",    0x44a00000, 0xffe007f8, COD|RD_t|WR_S|FP_S,     I64},
 {"dmtc1",   "t,S",	0x44a00000, 0xffe007ff, COD|RD_t|WR_S|FP_S,	I3	},
 {"dmtc1",   "t,G",      0x44a00000, 0xffe007ff, COD|RD_t|WR_S|FP_S,     I3      },
 {"dmfc2",   "t,G",      0x48200000, 0xffe007ff, LCD|WR_t|RD_C2, 	I3      },
 {"dmfc2",   "t,G,H",    0x48200000, 0xffe007f8, LCD|WR_t|RD_C2, 	I64     },
+{"dmfc2",   "t,S,H",    0x48200000, 0xffe007f8, LCD|WR_t|RD_S|FP_S,     I64},
 {"dmtc2",   "t,G",      0x48a00000, 0xffe007ff, COD|RD_t|WR_C2|WR_CC,   I3      },
 {"dmtc2",   "t,G,H",    0x48a00000, 0xffe007f8, COD|RD_t|WR_C2|WR_CC,   I64     },
+{"dmtc2",   "t,S,H",    0x48a00000, 0xffe007f8, COD|RD_t|WR_S|FP_S,     I64},
 {"dmfc3",   "t,G",      0x4c200000, 0xffe007ff, LCD|WR_t|RD_C3, 	I3      },
 {"dmfc3",   "t,G,H",    0x4c200000, 0xffe007f8, LCD|WR_t|RD_C3, 	I64     },
 {"dmtc3",   "t,G",      0x4ca00000, 0xffe007ff, COD|RD_t|WR_C3|WR_CC,   I3      },
@@ -563,6 +567,8 @@ const struct mips_opcode mips_builtin_op
 {"mfc0",    "t,G,H",    0x40000000, 0xffe007f8, LCD|WR_t|RD_C0, 	I32     },
 {"mfc1",    "t,S",	0x44000000, 0xffe007ff,	LCD|WR_t|RD_S|FP_S,	I1	},
 {"mfc1",    "t,G",	0x44000000, 0xffe007ff,	LCD|WR_t|RD_S|FP_S,	I1	},
+{"mfc1",    "t,S,H",    0x44000000, 0xffe007f8, LCD|WR_t|RD_S|FP_S,     I32},
+{"mfc1",    "t,G,H",    0x44000000, 0xffe007f8, LCD|WR_t|RD_S|FP_S,     I32},
 {"mfc2",    "t,G",	0x48000000, 0xffe007ff,	LCD|WR_t|RD_C2,		I1	},
 {"mfc2",    "t,G,H",    0x48000000, 0xffe007f8, LCD|WR_t|RD_C2, 	I32     },
 {"mfc3",    "t,G",	0x4c000000, 0xffe007ff,	LCD|WR_t|RD_C3,		I1	},
@@ -600,6 +606,8 @@ const struct mips_opcode mips_builtin_op
 {"mtc0",    "t,G,H",    0x40800000, 0xffe007f8, COD|RD_t|WR_C0|WR_CC,   I32     },
 {"mtc1",    "t,S",	0x44800000, 0xffe007ff,	COD|RD_t|WR_S|FP_S,	I1	},
 {"mtc1",    "t,G",	0x44800000, 0xffe007ff,	COD|RD_t|WR_S|FP_S,	I1	},
+{"mtc1",    "t,S,H",    0x44800000, 0xffe007f8, COD|RD_t|WR_S|FP_S,     I32     },
+{"mtc1",    "t,G,H",    0x44800000, 0xffe007f8, COD|RD_t|WR_S|FP_S,     I32     },
 {"mtc2",    "t,G",	0x48800000, 0xffe007ff,	COD|RD_t|WR_C2|WR_CC,	I1	},
 {"mtc2",    "t,G,H",    0x48800000, 0xffe007f8, COD|RD_t|WR_C2|WR_CC,   I32     },
 {"mtc3",    "t,G",	0x4c800000, 0xffe007ff,	COD|RD_t|WR_C3|WR_CC,	I1	},

Re: PATCH: More mips3264 support

[cgd]

I'm not Nick, but i'll comment anyway!  8-)

echristo@redhat.com ("Eric Christopher") writes:
> 	* mips-opc.c: Add support for dmfc1, dmtc1, dmtc2, additional modes
> 	for mfc1 and mtc1.

I disagree with these.  more on these at the end.


> 	* mips-dis.c: Add support for bfd_mach_mipsisa32 and
> 	bfd_mach_mipsisa64.

puzzled about these (and the related changes elsewhere that use them).
"MIPS32 and MIPS64 ISA" is what the existing bfd_mach_mips5 and
bfd_mach_mips64 were meant to address.

Why are new constants needed?  Am I missing something Subtle here?

(mips64isa is a name in mips_cpu_info_table in gas only because
historically mips64 is taken.)

As target names go, I think i'm fine with mipsisa64, though, so stuff
related to adding that is OK by me.


> src/ld/ChangeLog
> 2001-07-19  Eric Christopher  <echristo@redhat.com>
> 	    Jason Eckhardt  <jle@redhat.com>
> 
> 	* ldmain.c (get_emulation): Add support for -mips32 and -mips64.

perhaps silly, but the order in which you've sorted the options seems
... wrong no matter how you look at it.  8-)

(looks good to minimize diffs & conflicts though, good for your own
tree maintenance.  8-)


> src/bfd/ChangeLog
> 2001-07-19  Eric Christopher  <echristo@redhat.com>
> 	    Jason Eckhardt  <jle@redhat.com>
> 
> 	* bfd/archures.c: Add mipsisa32 and mipsisa64.
> 	* bfd/cpu-mips.c: Ditto.
> 	* bfd/elf32-mips.c (_bfd_mips_elf_final_write_processing): Ditto.

same issue as above.


> src/gas/ChangeLog
> 2001-07-19  Eric Christopher  <echristo@redhat.com>
> 	    Jason Eckhardt  <jle@redhat.com>
> 
> 	* config/tc-mips.c (mips_cpu_info): Add support for mipsisa32,
> 	5kc, and 20kc.

if you're going to configure as mipsisaNN-whatever, don't you also
need support in here for mipsisa64?  ("mips64isa" was an attempt to do
that, but I can imagine it'll run afoul of more autoconf lossage than
will mipsisa64...  if you agree, you might also nuke mips64isa.)

for the MIPS32-4K cores, when reformulating this table I made it:

  { "MIPS32-4K",      0,      ISA_MIPS32,     CPU_MIPS32_4K, },
  { "4kc",            0,      ISA_MIPS32,     CPU_MIPS32_4K, },
  { "4km",            0,      ISA_MIPS32,     CPU_MIPS32_4K, },
  { "4kp",            0,      ISA_MIPS32,     CPU_MIPS32_4K, },
  { "mips32-4kc",     0,      ISA_MIPS32,     CPU_MIPS32_4K, },
  { "mips32-4km",     0,      ISA_MIPS32,     CPU_MIPS32_4K, },
  { "mips32-4kp",     0,      ISA_MIPS32,     CPU_MIPS32_4K, },
 
the notion being:

	* canonical name first (upper case, though it's compared
	insensitively when searching)

	* variants that the user might resonably type, afterward.

You might want to do the same for the 5k and 20k I don't really care.
If you do want, the entries from my (not yet submitted -- you beat me
8-) source tree are:

  /* MIPS64 5K CPU */
  { "MIPS64-5K",        0,      ISA_MIPS64,     CPU_MIPS64_5K, },
  { "5kc",              0,      ISA_MIPS64,     CPU_MIPS64_5K, },
  { "mips64-5kc",       0,      ISA_MIPS64,     CPU_MIPS64_5K, },
  
  /* MIPS64 20K CPU */  
  { "MIPS64-20K",       0,      ISA_MIPS64,     CPU_MIPS64_20K, },
  { "20kc",             0,      ISA_MIPS64,     CPU_MIPS64_20K, },
  { "mips64-20kc",      0,      ISA_MIPS64,     CPU_MIPS64_20K, },


Your current entries are a bit bogus: the table is search w/o case
sensitivity, so there's no point in having entries that differ only by
case.



Any reason for adding the blank line in opcode/mips.h?  8-)



and now back to the mips-opc.c changes:

> Index: opcodes/mips-opc.c

> +{"dmfc1",   "t,S,H",    0x44200000, 0xffe007f8, LCD|WR_t|RD_S|FP_S,     I64},

If you look in the MIPS32/MIPS64 manuals (e.g.
http://www.mips.com/declassified/Declassified_2001/MD00087-2B-MIPS64BIS-AFP-00.95.pdf ),
they _do not_ define as 'sel' code for {d,}m[ft]c1!

I believe this is intentional and "correct": the FP architecture has
the FP regs, but a selector within them has no well-defined meaning.

if you look at the descriptions of all of the mfc/mtc opcodes, you'll
see that, alone, 1 is missing 'sel'.  (of course, you won't see c3 at
all.  8-)


> +{"dmfc2",   "t,S,H",    0x48200000, 0xffe007f8, LCD|WR_t|RD_S|FP_S,     I64},

This one I Just Don't Get, and I have three indepent issues with this
set of changes as is:

* You're adding interpretation of $fN as the cp register arg for c2?
Does that make sense?  It's not the FP coprocessor.  If i _is_ an FP
coprocessor on some machines, well, I'd say that that encoding should
be machine-specific.  but just saying e.g. "dmfc2 $10, $f3, 0" for
most MIPS processors doesn't make sense to me.

* you added it for dmfc2 and dmtc2, but not for mfc2 and mtc2.  That
seems incorrect.

* you added "t,S,H" variants, but didn't add "t,S" variants.  If the
former is appropriate, the latter must be as well I'd _think_!


chris

Re: PATCH: More mips3264 support

[Ben Elliston]

>>>>> "Eric" == Eric Christopher <echristo@redhat.com> writes:

  Eric> I'm also importing the current config.sub from gcc and adding support
  Eric> for the configure target.  Though I'm not sure what the proper procedure
  Eric> for this is - I'm sure Ben will tell me.

There is a comment in the comment block at the start of `config.sub'
that outlines how to submit patches.  It is not clear from your patch
which parts are genuinely new and which parts are being brought over
in the `config.sub' import.

So--please send a revised patch for `config.sub' itself.  Thanks.

Ben

Re: PATCH: More mips3264 support

[Andrew Cagney]

> I'm also importing the current config.sub from gcc and adding support
> for the configure target.  Though I'm not sure what the proper procedure
> for this is - I'm sure Ben will tell me.

To quote, src/MAINTAINERS:

config.guess; config.sub; dejagnu/config.guess;
readline/support/config.sub; readline/support/config.guess
         config: http://gnu.org
         Patches to config-patches@gnu.org.
         Changes need to be done in tandem with the official CONFIG
         sources or submitted to the master file maintainer and brought
         in via a merge.

both config.sub and config.guess should be updated simultaneously and 
for all the above cases.  It is easier to do this via the gdb/dejagnu 
tree.  If what you're doing is a straight import from the master 
repository (not GCC :-) then it doesn't need approval.

	Andrew

Re: PATCH: More mips3264 support

[Eric Christopher]

On 22 Jul 2001 11:11:40 -0700, cgd@sibyte.com wrote:
> I'm not Nick, but i'll comment anyway!  8-)
> 

How'd I guess?


> > 	* mips-dis.c: Add support for bfd_mach_mipsisa32 and
> > 	bfd_mach_mipsisa64.
> 
> puzzled about these (and the related changes elsewhere that use them).
> "MIPS32 and MIPS64 ISA" is what the existing bfd_mach_mips5 and
> bfd_mach_mips64 were meant to address.
> 
> Why are new constants needed?  Am I missing something Subtle here?
> 
> (mips64isa is a name in mips_cpu_info_table in gas only because
> historically mips64 is taken.)
> 
> As target names go, I think i'm fine with mipsisa64, though, so stuff
> related to adding that is OK by me.
> 

Yes.  Basically using MIPS32 and MIPS64 ISA are, IMO, confusing.  This
way we've separated out the base core (isa32 and isa64) for the newer
versions of the assembler/compiler.


> perhaps silly, but the order in which you've sorted the options seems
> ... wrong no matter how you look at it.  8-)
> 
> (looks good to minimize diffs & conflicts though, good for your own
> tree maintenance.  8-)
> 

;)  I'll check it to make sure.

> 
> > src/bfd/ChangeLog
> > 2001-07-19  Eric Christopher  <echristo@redhat.com>
> > 	    Jason Eckhardt  <jle@redhat.com>
> > 
> > 	* bfd/archures.c: Add mipsisa32 and mipsisa64.
> > 	* bfd/cpu-mips.c: Ditto.
> > 	* bfd/elf32-mips.c (_bfd_mips_elf_final_write_processing): Ditto.
> 
> same issue as above.
> 

I assume you meant the mipsisa32 and mipsisa64 and not the command
sorting.

> 
> > src/gas/ChangeLog
> > 2001-07-19  Eric Christopher  <echristo@redhat.com>
> > 	    Jason Eckhardt  <jle@redhat.com>
> > 
> > 	* config/tc-mips.c (mips_cpu_info): Add support for mipsisa32,
> > 	5kc, and 20kc.
> 
> if you're going to configure as mipsisaNN-whatever, don't you also
> need support in here for mipsisa64?  ("mips64isa" was an attempt to do
> that, but I can imagine it'll run afoul of more autoconf lossage than
> will mipsisa64...  if you agree, you might also nuke mips64isa.)
> 

Ok.  I'll do this and look into the patch a bit more.  Everything
_works_
but this is what peer review is for yes?

> for the MIPS32-4K cores, when reformulating this table I made it:
> 
>   { "MIPS32-4K",      0,      ISA_MIPS32,     CPU_MIPS32_4K, },
>   { "4kc",            0,      ISA_MIPS32,     CPU_MIPS32_4K, },
>   { "4km",            0,      ISA_MIPS32,     CPU_MIPS32_4K, },
>   { "4kp",            0,      ISA_MIPS32,     CPU_MIPS32_4K, },
>   { "mips32-4kc",     0,      ISA_MIPS32,     CPU_MIPS32_4K, },
>   { "mips32-4km",     0,      ISA_MIPS32,     CPU_MIPS32_4K, },
>   { "mips32-4kp",     0,      ISA_MIPS32,     CPU_MIPS32_4K, },
>  
> the notion being:
> 
> 	* canonical name first (upper case, though it's compared
> 	insensitively when searching)
> 
> 	* variants that the user might resonably type, afterward.
> 
> You might want to do the same for the 5k and 20k I don't really care.
> If you do want, the entries from my (not yet submitted -- you beat me
> 8-) source tree are:
> 
>   /* MIPS64 5K CPU */
>   { "MIPS64-5K",        0,      ISA_MIPS64,     CPU_MIPS64_5K, },
>   { "5kc",              0,      ISA_MIPS64,     CPU_MIPS64_5K, },
>   { "mips64-5kc",       0,      ISA_MIPS64,     CPU_MIPS64_5K, },
>   
>   /* MIPS64 20K CPU */  
>   { "MIPS64-20K",       0,      ISA_MIPS64,     CPU_MIPS64_20K, },
>   { "20kc",             0,      ISA_MIPS64,     CPU_MIPS64_20K, },
>   { "mips64-20kc",      0,      ISA_MIPS64,     CPU_MIPS64_20K, },
> 
> 

Heh.  I'll see.

> Your current entries are a bit bogus: the table is search w/o case
> sensitivity, so there's no point in having entries that differ only by
> case.
> 

Thanks for the catch.  I'd missed that one.  

> 
> 
> Any reason for adding the blank line in opcode/mips.h?  8-)
> 
> 

Umm.. some code that didn't get deleted? ;)

> 
> and now back to the mips-opc.c changes:
> 
> > Index: opcodes/mips-opc.c
> 
> > +{"dmfc1",   "t,S,H",    0x44200000, 0xffe007f8, LCD|WR_t|RD_S|FP_S,     I64},
> 
> If you look in the MIPS32/MIPS64 manuals (e.g.
> http://www.mips.com/declassified/Declassified_2001/MD00087-2B-MIPS64BIS-AFP-00.95.pdf ),
> they _do not_ define as 'sel' code for {d,}m[ft]c1!
> 
> I believe this is intentional and "correct": the FP architecture has
> the FP regs, but a selector within them has no well-defined meaning.
> 
> if you look at the descriptions of all of the mfc/mtc opcodes, you'll
> see that, alone, 1 is missing 'sel'.  (of course, you won't see c3 at
> all.  8-)
> 
> 

Hrm.  Ok, this must be a difference from the old versions and the new
versions.

> > +{"dmfc2",   "t,S,H",    0x48200000, 0xffe007f8, LCD|WR_t|RD_S|FP_S,     I64},
> 
> This one I Just Don't Get, and I have three indepent issues with this
> set of changes as is:
> 
> * You're adding interpretation of $fN as the cp register arg for c2?
> Does that make sense?  It's not the FP coprocessor.  If i _is_ an FP
> coprocessor on some machines, well, I'd say that that encoding should
> be machine-specific.  but just saying e.g. "dmfc2 $10, $f3, 0" for
> most MIPS processors doesn't make sense to me.
> 
> * you added it for dmfc2 and dmtc2, but not for mfc2 and mtc2.  That
> seems incorrect.
> 
> * you added "t,S,H" variants, but didn't add "t,S" variants.  If the
> former is appropriate, the latter must be as well I'd _think_!
> 
> 

Basically the idea behind all of this is from the original spec that we
received from MIPS.  How about I just go and assume that you did the
work
correctly when you submitted it and remove that part of the patch? ;)

Anyhow, I'll produce another set for you and Nick to comment on as soon
as I'm able to remerge all of my changes.

-eric


--
Look out behind you!

Re: PATCH: More mips3264 support

[cgd]

"Eric Christopher" <echristo@redhat.com> writes:
> cgd wrote:
> > > 	* mips-dis.c: Add support for bfd_mach_mipsisa32 and
> > > 	bfd_mach_mipsisa64.
> > 
> > puzzled about these (and the related changes elsewhere that use them).
> > "MIPS32 and MIPS64 ISA" is what the existing bfd_mach_mips5 and
> > bfd_mach_mips64 were meant to address.

actually, there was a typo there; the first was supposed to be
bfd_mach_mips32.

> > Why are new constants needed?  Am I missing something Subtle here?
> > 
> > (mips64isa is a name in mips_cpu_info_table in gas only because
> > historically mips64 is taken.)
> > 
> > As target names go, I think i'm fine with mipsisa64, though, so stuff
> > related to adding that is OK by me.
> > 
> 
> Yes.  Basically using MIPS32 and MIPS64 ISA are, IMO, confusing.  This
> way we've separated out the base core (isa32 and isa64) for the newer
> versions of the assembler/compiler.

Not sure what this means in terms of changes to the source.

If you plan to keep the bfd_mach_mipsisa32 & bfd_mach_mipsisa64
constant names, i suggest you do the same for bfd_mach_mipsisa5, and
nuke the bfd_mach_mips{32,64}.  Shouldn't need both sets, since the
latter are meant to describe the ISAs rather than particular
processors.


> Anyhow, I'll produce another set for you and Nick to comment on as soon
> as I'm able to remerge all of my changes.

Great!  8-)


chris

Re: PATCH: More mips3264 support

[Eric Christopher]

> 
> Not sure what this means in terms of changes to the source.

Not a whole lot really.  It's a name change, but it'll allow a hierarchy
for configure as well, e.g.

mipsisa32-*-elf
mipsisa32<weird chip>-*-elf
mipsisa64<weird chip>-*-elf
etc.

> 
> If you plan to keep the bfd_mach_mipsisa32 & bfd_mach_mipsisa64
> constant names, i suggest you do the same for bfd_mach_mipsisa5, and
> nuke the bfd_mach_mips{32,64}.  Shouldn't need both sets, since the
> latter are meant to describe the ISAs rather than particular
> processors.
> 

I kept meaning to ask.. what is bfd_mach_mips5 supposed to be for?  I've
only seen 1-4...

> 
> > Anyhow, I'll produce another set for you and Nick to comment on as soon
> > as I'm able to remerge all of my changes.
> 
> Great!  8-)
> 

You'll see 'em today. :)

-eric


-- 
Look out behind you!

Re: PATCH: More mips3264 support

[cgd]

"Eric Christopher" <echristo@redhat.com> writes:
> Not a whole lot really.  It's a name change, but it'll allow a hierarchy
> for configure as well, e.g.
> 
> mipsisa32-*-elf
> mipsisa32<weird chip>-*-elf
> mipsisa64<weird chip>-*-elf
> etc.

"Good."  8-)


> > If you plan to keep the bfd_mach_mipsisa32 & bfd_mach_mipsisa64
> > constant names, i suggest you do the same for bfd_mach_mipsisa5, and
> > nuke the bfd_mach_mips{32,64}.  Shouldn't need both sets, since the
> > latter are meant to describe the ISAs rather than particular
> > processors.
> > 
> 
> I kept meaning to ask.. what is bfd_mach_mips5 supposed to be for?  I've
> only seen 1-4...

"Why, binaries compiled with -mips5, using the MIPS V ISA!"  8-)

I'm not completely sure, but I don't believe that there are any
existing processors that actually implement 'vanilla' MIPS V.

A description of MIPS V ISA extensions can be pieced together from
looking at the MIPS64 spec (i.e. by looking to see what things came
from MIPS V), but can more easily be read in the document:

	http://www.mips.com/Documentation/isa5_tech_brf.pdf

("Paired Single" is basically it.)



cgd