Re: [patch] Add start of mips32/mips64 support to sim/mips/mips.igen

[Andrew Cagney <ac131313@cygnus.com>]

"Chris G. Demetriou" wrote:

[there was an interveening e-mail]

> Andrew Cagney <ac131313@cygnus.com> writes:
> > Two quick questions first off.
> >
> >       o       what is mipsV?

Sorry, what I ment to say was that the change adds ``mipsV'' yet nothing
else explains this.  If nothing else it is most likely a separate
change.

	Andrew
From ac131313@cygnus.com Mon Dec 04 16:33:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Chris G. Demetriou" <cgd@sibyte.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch] Add start of mips32/mips64 support to sim/mips/mips.igen
Date: Mon, 04 Dec 2000 16:33:00 -0000
Message-id: <3A2C35A7.A018EBEE@cygnus.com>
References: <5telznaixe.fsf@highland.sibyte.com> <3A2C2415.5709A40@cygnus.com>
X-SW-Source: 2000-12/msg00097.html
Content-length: 870

Andrew Cagney wrote:

>         o       is there documentation for mips32/mips64
>                 publically available so that I check
>                 your changes against it?

To expand on this one.  I've two concerns.

	o	I'd like to see a patch tabled
		that adds the full mips32/mips64 ISA.

		I think a new ISA should be added
		as a single patch and not as an
		incremental set of changes.

	o	I'd like to be sure that the information
		being committed is, one way, or another
		public.

		Instruction set simulators include a semantic
		specification of each instruction.  I'd
		like to be sure that your allowed to publish/
		submit this for the ISS.		

If there is published documentation that you can refer people to then
things are pretty easy.  If there isn't then I'll work on the assumption
that you've gone through due process on this.

enjoy,
	Andrew
From ac131313@cygnus.com Mon Dec 04 16:55:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Orjan Friberg <orjan.friberg@axis.com>
Cc: gdb-patches@sources.redhat.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: New port: CRIS architecture
Date: Mon, 04 Dec 2000 16:55:00 -0000
Message-id: <3A2C3AC7.9F7F454F@cygnus.com>
References: <3A2BAEF0.A4641A0C@axis.com>
X-SW-Source: 2000-12/msg00098.html
Content-length: 678

FYI,

I can't find an assignment in place?

Several more generic comments.

tm-cris.h:
	I'm trying to figure out why it is needed.
	The obvious problem is SOFTWARE_SINGLESTEP_P.
	I'll fix that.

	Beyond that one, what else is needed?  I'd
	like to see a second pure multi-arch target
	in GDB so will help where needed.

cris-tdep.c:
	It is preferable to have enums and
	two line functions rather than macros.
	They both make the long term job of
	maintenance far easier.

	Other files have put __initialize*
	and xxx_arch_init() at the end.  I'd
	just suggest moving them.

	Other than that, absolutly nothing
	has jumped up and even the above
	are not problems.

cool!
	Andrew
From cgd@sibyte.com Mon Dec 04 17:25:00 2000
From: cgd@sibyte.com (Chris G. Demetriou)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] Add start of mips32/mips64 support to sim/mips/mips.igen
Date: Mon, 04 Dec 2000 17:25:00 -0000
Message-id: <5t8zpvacdl.fsf@highland.sibyte.com>
References: <5telznaixe.fsf@highland.sibyte.com> <3A2C2415.5709A40@cygnus.com> <3A2C35A7.A018EBEE@cygnus.com>
X-SW-Source: 2000-12/msg00099.html
Content-length: 2032

[ To reply to two messages in one ]

> To expand on this one.  I've two concerns.
> 
> 	o	I'd like to see a patch tabled
> 		that adds the full mips32/mips64 ISA.
> 
> 		I think a new ISA should be added
> 		as a single patch and not as an
> 		incremental set of changes.

OK.  Having worked in the other tools, my inclination was stepwise
refinement.

We can certainly do this if you are so inclined.  Would you prefer:

(a) 1 patch which adds MIPS V, MIPS32, and MIPS64 at once, or

(b) 1 patch for each.

I think if the goal is to do "one patch that just does it," I'd prefer
the former, because it means a lot less duplication of effort.


> 	o	I'd like to be sure that the information
> 		being committed is, one way, or another
> 		public.
> 
> 		Instruction set simulators include a semantic
> 		specification of each instruction.  I'd
> 		like to be sure that your allowed to publish/
> 		submit this for the ISS.		
> 
> If there is published documentation that you can refer people to then
> things are pretty easy.  If there isn't then I'll work on the assumption
> that you've gone through due process on this.

There is some public documentation on MIPS32, as part of the MIPS32 4K
core documentation available on:

	http://www.mips.com/publications/index.html

For the rest, yes, we've done the due process.  8-)


> "Chris G. Demetriou" wrote:
> [there was an interveening e-mail]
>
> > Andrew Cagney <ac131313@cygnus.com> writes:
> > > Two quick questions first off.
> > >
> > >       o       what is mipsV?
>
> Sorry, what I ment to say was that the change adds ``mipsV'' yet nothing
> else explains this.  If nothing else it is most likely a separate change.

Oh, I'm sorry.  I thought i'd mentioned it in my ChangLog, along with
the mips32 and mips64 entries, but I guess I didn't.

It's another ISA, like MIPS I - MIPS IV.  (It incorporates all of MIPS
IV and adds on to it.)  If i recall correctly, its main addition is
Paired Single floating point operations, but it's been a while since
I've checked.



chris
From hans-peter.nilsson@axis.com Mon Dec 04 17:57:00 2000
From: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
To: ac131313@cygnus.com
Cc: orjan.friberg@axis.com, gdb-patches@sources.redhat.com, jimb@cygnus.com
Subject: Re: New port: CRIS architecture
Date: Mon, 04 Dec 2000 17:57:00 -0000
Message-id: <200012050156.CAA03951@ignucius.axis.se>
References: <3A2C3AC7.9F7F454F@cygnus.com>
X-SW-Source: 2000-12/msg00100.html
Content-length: 323

> Date: Tue, 05 Dec 2000 11:45:59 +1100
> From: Andrew Cagney <ac131313@cygnus.com>

> I can't find an assignment in place?

There is a multi- assign.future a'la Wind River and former
Cygnus in place since October 1998 for all Axis Communications
employees, listing GDB as one item.  Suggest search for "Axis".

brgds, H-P
From dje@transmeta.com Mon Dec 04 18:40:00 2000
From: Doug Evans <dje@transmeta.com>
To: Ben Elliston <bje@redhat.com>
Cc: <gdb-patches@sources.redhat.com>, <cgen@sources.redhat.com>
Subject: Re: [Sim] New sim/common/cgen.sh
Date: Mon, 04 Dec 2000 18:40:00 -0000
Message-id: <14892.21907.916077.737133@casey.transmeta.com>
References: <14891.59510.53616.923378@casey.transmeta.com> <Pine.LNX.4.30.0012050810410.5910-100000@moshpit.cygnus.com>
X-SW-Source: 2000-12/msg00101.html
Content-length: 601

Ben Elliston writes:
 >     > I have also just fixed genmloop.sh so that it has an -outfile-suffix option.
 >     > This allows the generated files to form unique filenames -- so it, too, can
 >     > be run by a parallel make.
 > 
 >    Can't this problem be solved without adding an option?
 > 
 > Can you suggest how?

The theory is that the script is already being passed something it can use.

There's the -cpu argument.  I dunno if your @prefix@ patches change whether
genmloop.sh should use @cpu@ or @prefix@, but won't one of them
(whichever it is) be sufficient to separate the output files?
From msnyder@cygnus.com Mon Dec 04 19:15:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] Fix typo in error msg.
Date: Mon, 04 Dec 2000 19:15:00 -0000
Message-id: <200012050315.TAA01235@cleaver.cygnus.com>
X-SW-Source: 2000-12/msg00102.html
Content-length: 1248

In internal_verror, the error message has the word "make" twice.

2000-12-04  Michael Snyder  <msnyder@cleaver.cygnus.com>

        * utils.c (internal_verror): Fix typo in error msg.

Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.23
diff -c -3 -p -r1.23 utils.c
*** utils.c	2000/11/20 02:06:19	1.23
--- utils.c	2000/12/05 03:14:31
*************** internal_verror (const char *fmt, va_lis
*** 699,705 ****
    /* Default (no case) is to quit GDB.  When in batch mode this
       lessens the likelhood of GDB going into an infinate loop. */
    continue_p = query ("\
! An internal GDB error was detected.  This may make make further\n\
  debugging unreliable.  Continue this debugging session? ");
  
    /* Default (no case) is to not dump core.  Lessen the chance of GDB
--- 699,705 ----
    /* Default (no case) is to quit GDB.  When in batch mode this
       lessens the likelhood of GDB going into an infinate loop. */
    continue_p = query ("\
! An internal GDB error was detected.  This may make further\n\
  debugging unreliable.  Continue this debugging session? ");
  
    /* Default (no case) is to not dump core.  Lessen the chance of GDB
From bje@redhat.com Mon Dec 04 19:29:00 2000
From: Ben Elliston <bje@redhat.com>
To: Doug Evans <dje@transmeta.com>
Cc: <gdb-patches@sources.redhat.com>, <cgen@sources.redhat.com>
Subject: Re: [Sim] New sim/common/cgen.sh
Date: Mon, 04 Dec 2000 19:29:00 -0000
Message-id: <Pine.LNX.4.30.0012051428270.7250-100000@moshpit.cygnus.com>
References: <14892.21907.916077.737133@casey.transmeta.com>
X-SW-Source: 2000-12/msg00103.html
Content-length: 368

   The theory is that the script is already being passed something it can
   use.

The same could be said for determining the input filename (ie. mloop.in),
but we provide the flexibility to specify *that*.  There is even a comment
in genmloop.sh that says that it would be useful to provide options to
specify the output filenames (both of them) in the future.

Ben