[WIP/RFC] MIPS registers overhaul

cgd@broadcom.com cgd@broadcom.com
Fri May 16 22:50:00 GMT 2003


At Fri, 16 May 2003 22:25:13 +0000 (UTC), cgd@broadcom.com wrote:
> This MIPS specifications (M64 1.00 Volume I, page 50, section 5.6.2)
> indicate that doing 64-bit reads/writes from/to odd FP registers when
> FR=0 are "illegal", and that values produced by such operations are
> unpredictable.

Actually, on the reads they say that the values produced are
unpredictable.

For writes, they indicate that the operation itself is unpredictable
("UNPREDICTABLE").

in other words, doing an ldc1 when FR == 0 could cause a trap if an
implementation were paranoid (*cough* simulator 8-).

So, really, when FR == 0, best to think of yourself as having only 32
* 32 bits.


Now, the question is, in the remote protocol, if 64-bit registers are
being passed, *how*.  (64-bit target, normally 64-bit registers... i'd assume
they're being passed as 64-bits.)

One reasonable way to do it, which i believe would be the result of
using n32 / n64 RDA on linux to debug an o32 executable, would be:

	0: meaningful
	1: garbage
	etc.

this is the natural way to do it on a 64-bit part, with a 64-bit FPU.
another reasonable way (but less efficient on a 64-bit part with a
64-bit FPU) would be:

	0: <high half garbage><low half meaningful>
	1: <high half garbage><low half meaningful>

Are there 64-bit parts out there that have FPUs with 32 single float
regs which one can operate on (4650, looking at gcc srcs?)  If so, the
latter would be a reasonable representation for them.


So, my conclusion is:

for raw registers that are xferred as 64-bits, yeah, fine, let people
have acess to them.  that's for debugger-debugging, and people who
muck with them may be shooting themselves in the head, but if they're
debugging the debugger they're smart, right?  8-)

need to have some way to tell which of the ways above is being used to
xfer the register data.  (or, need to define that only one way may be
used.)


chris



More information about the Gdb-patches mailing list