WIP: Register doco

WIP: Register doco

[Andrew Cagney]

Hello,

Below is just the starting of a chapter describing GDB's registers and 
the register cache.  I've not even shown it to makeinfo (so for the 
moment I'd ignore texinfo errors :-).  I'm interested in comments and 
even suggestions for things that need to be expanded.

Andrew



@node Registers
@chapter Registers

@section Register Spaces

@value{GDBN} internally has two register spaces:

@table @emph
@item cooked
@itemize @bullet
@item
manipulated by core @value{GDBN}
@item
correspond to user level, or abi registers
@end itemize
@item raw
@itemize @bullet
@item
manipulated by target backends
@item
correspond to physical registers
@end itemize
@end table

@subsection Raw Registers

The raw register space, containing @code{NUM_REGS}
@c index NUM_REGS
raw registers, abstracts the instruction set architectures physical
register set.  @value{GDBN}'s register cache contains raw registers.
Each raw register is mapped, one-to-one, onto a corresponding physical
register.  For instance:

@itemize @bullet

@item
For 64 bit architecture that has 32 general purpose registers, the
register cache, and the raw register space would include space for those
32 registers.

@item
For an architectures that has register banks, the register cache, and
raw register space would contain space for registers from all banks.
The one-to-one relationship between the raw registers and the
architecture's physical registers being preserved.

@item
For a 64 bit architecture that is running in 32 bit mode, the register
cache and raw register space would contain the 64 bit hardware
registers.  The raw register space would not include cut down 32 bit
registers.

@item
For an architecture that determines the program-counter by examining the
value of severaal hardware registers, the register cache and raw
register space will contain the separate hardware values.  The raw
register space would not include the program-counter.

@item
For an architecture that has memory mapped registers, those registers
are not be part of the register cache or raw register space (there is no
corresponding hardware register).

@end itemize

@emph{Maintainer note: Old architectures, since they didn't know better,
broke all of the above rules, sigh!}

The raw registers are not necessarily directly visible to the user.

@emph{Maintainer note: There should be be a @samp{maint info registers}
command so that the raw register cache is visible.}

@section Cooked Registers

The core of @value{GDBN} manipulates registers in the cooked register
space.  Any external or user visible register is mapped onto the cooked
register space, in particular:

@itemize @bullet
@item
registers refered to by debug information
@item
user visible registers (specified by name)
@item
mode dependant registers (e.g., a 64 bit architecture in 32 bit mode may
need to manipulate the 32 bits of 64 bit registers)
@item
memory mapped registers
space.
@item
state dependant registers (e.g., bank registers)
@end itemize

Architecture methods then map the @code{NUM_REGS + NUM_PSEUDO_REGS}
cooked registers onto raw registers or memory.  While arbitrary mappings
are possible, the first @code{NUM_REGS} registers should be be mapped
direct to the raw registers.  The remaining @code{NUM_PSEUDO_REGS then
having more arbitrary mappings.  That is:

@smallexample
cooked:   [0..NUM_REGS) [..NUM_REGS+NUM_PSEUDO_REGS)
                |          /           |
                |         /            |
                |        /             |
                |       /              |
raw:      RAW REGISTERS             MEMORY
@end smallexample

@section The Register Cache

@value{GDBN} stores the target register state in a register cache
(@code{struct regcache}).

The register cache has three separate interfaces:

@itemize @bullet
@item
cooked
@item
raw
@item
target
@end itemize

Core @value{GDBN} manipulates the register cache using the cooked
interfaces:

@deftypefun void regcache_cooked_read (struct regcache *@var{regcache}, 
int @var{regnum}, void *@var{buf})
Read a cooked register value from the register cache (or memory).
@end deftypefun
@deftypefun void regcache_cooked_write (struct regcache *@var{regcache}, 
int @var{regnum}, const void *@var{buf})
Write a cooked register value to the register cache (or memory).
@end deftypefun

These methods then use corresponding architecture methods to map the
cooked registers onto either raw registers or memory:

@deftypefun void gdbarch_cooked_register_read (struct gdbarch 
*@var{gdbarch}, struct regcache *@var{regcache}, int @var{regnum}, void 
*@var{buf})
Read the specified @var{regnum} register value from the @var{regcache}
(or memory for memory mapped registers).
@end deftypefun
@deftypefun void gdbarch_cooked_register_write (struct gdbarch 
*@var{gdbarch}, struct regcache *@var{regcache}, int @var{regnum}, const 
void *@var{buf})
Write the specified @var{regnum} register value into the @var{regcache}
(or memory for memory mapped registers).
@end deftypefun

The raw register values being manipulated using:

@deftypefun void regcache_raw_read (struct regcache *@var{regcache}, int 
@var{regnum}, void *@var{buf})
Read a cooked register value from the register cache (or memory).
@end deftypefun
@deftypefun void regcache_raw_write (struct regcache *@var{regcache}, 
int @var{regnum}, const void *@var{buf})
Write a raw register value to the register cache (or memory).
@end deftypefun

When a raw register read or write needs to go through to the target (the
value isn't yet in the cache or a modification needs to be written to
the target) the register cache state is then manipulated by the target
using the methods:

@deftypefun regcache_collect (struct regcache *@var{regcache}, int 
@var{regnum}, void *@var{buf})
@end deftypefun
@deftypefun regcache_supply (struct regcache *@var{regcache}, int 
@var{regnum}, const void *@var{buf})
@end deftypefun

Re: WIP: Register doco

[Jim Blandy]

I'm not saying the questions below couldn't be worked out by examining
the whole document carefully.  But ideally, a document makes sense in
the first read-through.

Andrew Cagney <ac131313@ges.redhat.com> writes:
> @table @emph
> @item cooked
> @itemize @bullet
> @item
> manipulated by core @value{GDBN}
> @item
> correspond to user level, or abi registers

Don't you mean "ISA" here, not "ABI"?  If I disassemble some code and
see an instruction that refers to r12, then I should be able to see
that register's value by saying "print $r12".  The ABI in use has
nothing to do with it.


> @end itemize
> @item raw
> @itemize @bullet
> @item
> manipulated by target backends
> @item
> correspond to physical registers

I think you're introducing a new term here, "physical", which doesn't
do anything for you.  When I see "physical", I think of actual
flip-flops.  But that's clearly not what you're talking about: GDB has
no idea how many ports these registers have, whether they get renamed
for speculative execution, etc.

In effect, all that phrase does is define "raw" in terms of another
undefined term, "physical".

By "raw", do you really mean the registers as presented by the
underlying protocol GDB uses to examine the inferior (be it remote,
/proc, or ptrace)?  I dunno.

> @subsection Raw Registers
> 
> The raw register space, containing @code{NUM_REGS}
> @c index NUM_REGS
> raw registers, abstracts the instruction set architectures physical
> register set.  @value{GDBN}'s register cache contains raw registers.
> Each raw register is mapped, one-to-one, onto a corresponding physical
> register.  For instance:
> 
> @itemize @bullet
> 
> @item
> For 64 bit architecture that has 32 general purpose registers, the
> register cache, and the raw register space would include space for those
> 32 registers.
> 
> @item
> For an architectures that has register banks, the register cache, and
> raw register space would contain space for registers from all banks.
> The one-to-one relationship between the raw registers and the
> architecture's physical registers being preserved.
> 
> @item
> For a 64 bit architecture that is running in 32 bit mode, the register
> cache and raw register space would contain the 64 bit hardware
> registers.  The raw register space would not include cut down 32 bit
> registers.

By "32 bit mode", do you mean that there's an actual bit on the
processor that makes shift, divide, etc. instructions behave as if
there were only 32 bits?  Or do you mean an ABI that simply only uses
the lower 32 bits of the registers?

> @item
> For an architecture that determines the program-counter by examining the
> value of severaal hardware registers, the register cache and raw
> register space will contain the separate hardware values.  The raw
> register space would not include the program-counter.
> 
> @item
> For an architecture that has memory mapped registers, those registers
> are not be part of the register cache or raw register space (there is no
> corresponding hardware register).

I think it would be nice to use the IA-64's arrangement as an example
here.  I assume the raw registers would include the unrotated register
file, and the registers that determine how they're rotated at the
current point.  Whereas the cooked registers would be numbered the way
they appear in the machine instructions.

> @end itemize
> 
> @emph{Maintainer note: Old architectures, since they didn't know better,
> broke all of the above rules, sigh!}
> 
> The raw registers are not necessarily directly visible to the user.
> 
> @emph{Maintainer note: There should be be a @samp{maint info registers}
> command so that the raw register cache is visible.}
> 
> @section Cooked Registers
> 
> The core of @value{GDBN} manipulates registers in the cooked register
> space.  Any external or user visible register is mapped onto the cooked
> register space, in particular:
> 
> @itemize @bullet
> @item
> registers refered to by debug information
> @item
> user visible registers (specified by name)
> @item
> mode dependant registers (e.g., a 64 bit architecture in 32 bit mode may
> need to manipulate the 32 bits of 64 bit registers)
> @item
> memory mapped registers
> space.
> @item
> state dependant registers (e.g., bank registers)
> @end itemize
> 
> Architecture methods then map the @code{NUM_REGS + NUM_PSEUDO_REGS}
> cooked registers onto raw registers or memory.

So pseudo registers are different from cooked registers?  Or are they
the same?  If they're the same, then distinguishing NUM_REGS and
NUM_PSEUDO_REGS sort of implies that NUM_REGS corresponds to the
number of raw registers.  But that shouldn't be visible to the outside
at all.

> While arbitrary mappings
> are possible, the first @code{NUM_REGS} registers should be be mapped
> direct to the raw registers.  The remaining @code{NUM_PSEUDO_REGS then
> having more arbitrary mappings.  That is:
> 
> @smallexample
> cooked:   [0..NUM_REGS) [..NUM_REGS+NUM_PSEUDO_REGS)
>                 |          /           |
>                 |         /            |
>                 |        /             |
>                 |       /              |
> raw:      RAW REGISTERS             MEMORY
> @end smallexample

One of the problems with this explanation is that we have a real
menagerie of different kinds of registers:

- raw registers
- cooked registers
- pseudo registers
- whatever you call a cooked register that isn't a pseudo register

This is a big source of confusion --- for me, at least.

Why can't we just have "cooked" and "raw" registers, and draw the
picture like this?

> cooked:   [0..NUM_REGS)
>                 |      \   
>                 |       \  
>                 |        \ 
>                 |         \
> raw:      RAW REGISTERS  MEMORY

In other words, given that we're allowing cooked registers to be
computed arbitrarily from raw registers and memory contents, why not
dispense with pseudo registers altogether?
 
> @section The Register Cache
> 
> @value{GDBN} stores the target register state in a register cache
> (@code{struct regcache}).
> 
> The register cache has three separate interfaces:
> 
> @itemize @bullet
> @item
> cooked
> @item
> raw
> @item
> target
> @end itemize
> 
> Core @value{GDBN} manipulates the register cache using the cooked
> interfaces:
> 
> @deftypefun void regcache_cooked_read (struct regcache
> *@var{regcache}, int @var{regnum}, void *@var{buf})
> Read a cooked register value from the register cache (or memory).
> @end deftypefun
> @deftypefun void regcache_cooked_write (struct regcache
> *@var{regcache}, int @var{regnum}, const void *@var{buf})
> Write a cooked register value to the register cache (or memory).
> @end deftypefun
> 
> These methods then use corresponding architecture methods to map the
> cooked registers onto either raw registers or memory:
> 
> @deftypefun void gdbarch_cooked_register_read (struct gdbarch
> *@var{gdbarch}, struct regcache *@var{regcache}, int @var{regnum},
> void *@var{buf})
> Read the specified @var{regnum} register value from the @var{regcache}
> (or memory for memory mapped registers).
> @end deftypefun
> @deftypefun void gdbarch_cooked_register_write (struct gdbarch
> *@var{gdbarch}, struct regcache *@var{regcache}, int @var{regnum},
> const void *@var{buf})
> Write the specified @var{regnum} register value into the @var{regcache}
> (or memory for memory mapped registers).
> @end deftypefun
> 
> The raw register values being manipulated using:
> 
> @deftypefun void regcache_raw_read (struct regcache *@var{regcache},
> int @var{regnum}, void *@var{buf})
> Read a cooked register value from the register cache (or memory).
> @end deftypefun
> @deftypefun void regcache_raw_write (struct regcache *@var{regcache},
> int @var{regnum}, const void *@var{buf})
> Write a raw register value to the register cache (or memory).
> @end deftypefun
> 
> When a raw register read or write needs to go through to the target (the
> value isn't yet in the cache or a modification needs to be written to
> the target) the register cache state is then manipulated by the target
> using the methods:
> 
> @deftypefun regcache_collect (struct regcache *@var{regcache}, int
> @var{regnum}, void *@var{buf})
> @end deftypefun
> @deftypefun regcache_supply (struct regcache *@var{regcache}, int
> @var{regnum}, const void *@var{buf})
> @end deftypefun

Re: WIP: Register doco

[Jim Blandy]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> > I'm not saying the questions below couldn't be worked out by examining
> > the whole document carefully.  But ideally, a document makes sense in
> > the first read-through.
> 
> So, you're saying that this document doesn't make sense on a first
> reading?  I'm not suprized! :-)

Oh, of course!  I'm just explaining what I'd like us to shoot for.

> >> @table @emph
> >> @item cooked
> >> @itemize @bullet
> >> @item
> >> manipulated by core @value{GDBN}
> >> @item
> >> correspond to user level, or abi registers
> > Don't you mean "ISA" here, not "ABI"?  If I disassemble some code and
> > see an instruction that refers to r12, then I should be able to see
> > that register's value by saying "print $r12".  The ABI in use has
> > nothing to do with it.
> 
> No, ABI.  For instance mipsIII and o32.  The o32 ABI thinks registers
> have 32 bits yet the real register has 64 bits.  This gives two views
> of the same register.  When o32 debug info indicates a value in two
> adjacent registers, it is refering to 32 bit and not 64 bit registers.
> 
> (Should user visible registers be displayed according to the
> underlying ISA or ABI is an item for debate.  It has never been
> specified and I suspect in part because GDB, prior to
> gdbarch_register_read/write, couldn't handle both.)

I think the cooked registers should be ISA.  When the user is stepping
by instruction, disassembling code, she needs to be able to see the
values those instructions are really operating on.  If the compiler,
in accordance with a particular ABI, happens to be using those
registers in a limited way (say, that ignores their upper 32 bits),
that's not GDB's business.

For example, suppose the compiler has a bug, and although it intends
to be using the o32 ABI, it accidentally uses a 64-bit instruction.
(I've seen this happen, I think.)  GDB should certainly show the
reality, and not present a "view" that obscures the compiler's
mistake.

Usually the only reason I drop down to assembly language is because
I'm confused by what the optimizer has done, and I want to know what's
*really* happening.  Or I don't trust the compiler at all.  If GDB
decides to show me an "ABI view" of the processor, and not show me
what's really happening, then that's a major lose.

> >> @end itemize
> >> @item raw
> >> @itemize @bullet
> >> @item
> >> manipulated by target backends
> >> @item
> >> correspond to physical registers
> > I think you're introducing a new term here, "physical", which doesn't
> > do anything for you.  When I see "physical", I think of actual
> > flip-flops.  But that's clearly not what you're talking about: GDB has
> > no idea how many ports these registers have, whether they get renamed
> > for speculative execution, etc.
> 
> That was the intent.  The objective is to focus the reader on the
> target architecture's hardware and identify the registers that
> correspond to real hardware.  Often in GDB, people haven't focused on
> the hardware and its registers and instead stored cooked registers in
> the raw register cache.  See older SH and bank registers or d10v and
> its two stack pointers.
> 
> However, often, what GDB gets access to is actually the ``spill
> registers'' - the hardware registers saved to memory.  I guess I
> should refine this.
> 
> (Mind you, with a jtag target, it really is NAND and NOR gates :-)

(Well, but GDB doesn't clock the bits through the snaky JTAG digestive
tract itself.  It talks to some library which "cleans up" the view
from the JTAG.  Talking about `real hardware' or `flip-flops' is only
helpful if one holds naive Z80-era beliefs about hardware.  If one
knows about the amazing hair associated with registers on modern
processors, then there are all sorts of confusing questions that
brings up --- e.g., "How in the world would GDB get hold of the state
of the raw flip-flops on a native Linux system?")

Okay, I understand a little better.  What makes sense to me at the
moment is for the "cooked" registers to be what the instructions refer
to, and the "raw" registers to be the bits --- also ISA-level
constructs --- that make up those values.

The example of the IA-32's MMX and FP registers is a great example for
this.  The MMX registers, MM0--MM7, and the FP registers,
ST(0)--ST(7), actually refer to the same set of eight eighty-bit
registers, R0--R7.  A reference to the floating-point register ST(i)
becomes a reference to R((TOP + i) % 8), where TOP is a three-bit
field in the FPU status register.  But a reference to the MMX register
MM(i) becomes a reference to the lower 64 bits of R(i) (which would be
the mantissa of some ST(i)).

So here I'd say that MM0--MM7 and ST(0)--ST(7) registers are the
"cooked" registers --- the ones instructions refer to --- and R0--R7
are the "raw" registers: the bits that they refer to.  

But this whole circus is ISA-level stuff --- you have to know it to
generate correct code for the architecture.

On the SPARC, the analogous situation would be for g0--g7, i0--i7,
l0--l7, and o0--o7 to be the cooked registers, which are affected by
changes of the window, and the raw registers to be the underlying set
of NWINDOWS * 16 registers.  The SPARC spec avoids giving those
underlying registers any name: it just calls them "register windows".

The same thing follows here: the fact that the registers are windowed
is definitely part of the ISA.  We never leave ISA territory for
flip-flop territory.  Only JTAG drivers do that.


> > In effect, all that phrase does is define "raw" in terms of another
> > undefined term, "physical".
> > By "raw", do you really mean the registers as presented by the
> > underlying protocol GDB uses to examine the inferior (be it remote,
> > /proc, or ptrace)?  I dunno.
> 
> I'll likely change it to ``hardware'', I think I've been using that
> term more consistently elsewhere.

I think "hardware" is misleading for the same reasons "physical" is.
You're still just hinting, and not saying what you mean.

> >> @item
> >> For a 64 bit architecture that is running in 32 bit mode, the register
> >> cache and raw register space would contain the 64 bit hardware
> >> registers.  The raw register space would not include cut down 32 bit
> >> registers.
> > By "32 bit mode", do you mean that there's an actual bit on the
> > processor that makes shift, divide, etc. instructions behave as if
> > there were only 32 bits?  Or do you mean an ABI that simply only uses
> > the lower 32 bits of the registers?
> 
> Who knows --- target architecture dependant detail.  Some targets have
> a true 32 bit mode, some just run 32 bit ABI's on a 64 bit
> architectures. The MIPS floating point registers and their various
> modes shows how tangled the web can get.

I see the former as an ISA thing --- the instructions execute
differently depending on the state of that bit --- and the latter as
an ABI thing --- how the compiler has chosen to use the resources the
ISA gives you.  The ISA level is visible to GDB's user, via
disassembly and register references; those need (and have always
needed) to show the user everything they need to know how the
instructions will behave when executed.

Consider, for example, some code compiled to the o32 ABI, but running
on a 64-bit processor.  There's no reason the user couldn't write some
inline assembly language that uses some 64-bit instructions for a bit,
as long as they get everything back into the right places by the time
they get back into C code.  That's not ABI-conformant, but who cares?
An embedded user knows what they're doing.  They might just be using
o32 for compatibility with legacy code or something.  In any case, GDB
should happily show the full 64-bit register values here.


> >> @item
> >> For an architecture that has memory mapped registers, those registers
> >> are not be part of the register cache or raw register space (there is no
> >> corresponding hardware register).
> > I think it would be nice to use the IA-64's arrangement as an example
> > here.  I assume the raw registers would include the unrotated register
> > file, and the registers that determine how they're rotated at the
> > current point.  Whereas the cooked registers would be numbered the way
> > they appear in the machine instructions.
> 
> As a description of memory registers or bank registers?  Your
> description of the IA-64 sounds more like bank selectable registers
> and similar --- the FP register stack of the i386 is an example that
> more people might be familar with.  (Remember we're talking theory
> here, neither the ia64 nor the i386 use this mechanism.)

Yeah, the FP register stack would be a much better example.
Especially if you can include an explanation of the interactions
between the MMX and FP registers, as I did above.

> Some architectures can refer to memory addresses using a register like
> notation.  In fact I know of one architecture where every memory
> location can also be refered to using a register notation.  Such an
> architecture would have zero raw registers.

Makes sense.

> >> @itemize @bullet
> >> @item
> >> registers refered to by debug information
> >> @item
> >> user visible registers (specified by name)
> >> @item
> >> mode dependant registers (e.g., a 64 bit architecture in 32 bit mode may
> >> need to manipulate the 32 bits of 64 bit registers)
> >> @item
> >> memory mapped registers
> >> space.
> >> @item
> >> state dependant registers (e.g., bank registers)
> >> @end itemize
> >> Architecture methods then map the @code{NUM_REGS + NUM_PSEUDO_REGS}
> >> cooked registers onto raw registers or memory.
> > So pseudo registers are different from cooked registers?  Or are they
> > the same?  If they're the same, then distinguishing NUM_REGS and
> > NUM_PSEUDO_REGS sort of implies that NUM_REGS corresponds to the
> > number of raw registers.  But that shouldn't be visible to the outside
> > at all.
> 
> Pseudo registers?  Beyond the constant NUM_PSEUDO_REGS, this section
> makes no reference to pseudo-registers.
> 
> I guess I should add an historical note to the opening section
> pointing out that the constant NUM_PSEUDO_REGS originated from an
> earlier mechanism called ``pseudo registers''.  While, for the moment,
> the constant remains, new targets use gdbarch register read/write and
> not pseudo registers.

Yeah, that would be helpful.  Just something that says, "for
historical reasons, the number of cooked registers is `NUM_REGS +
NUM_PSEUDO_REGS'; this section doesn't make any distinction between
pseudo-registers and other registers."



> 
> >
> >> cooked:   [0..NUM_REGS)
> >>                 |      \                   |       \
> >> |        \                 |         \
> >> raw:      RAW REGISTERS  MEMORY
> > In other words, given that we're allowing cooked registers to be
> > computed arbitrarily from raw registers and memory contents, why not
> > dispense with pseudo registers altogether?
> 
> The need for pseudo registers was dispensed with a year ago.  Someone
> just needs to clean up the old targets and cleanup some edge cases
> .... As for NUM_REGS, that defines the number of registers in the raw
> register cache (note below).
> 
> I'll add a comment mentioning the rationale behind direct mapping the
> first [0..NUM_REGS) registers.  It was firstly a case of K.I.S.S. and
> secondly due to suspected limitations in the current GDB code - the
> constant NUM_REGS unfortunatly still determines far more than the
> number of raw registers.

That would be great.

Re: WIP: Register doco

[Andrew Cagney]

> I'm not saying the questions below couldn't be worked out by examining
> the whole document carefully.  But ideally, a document makes sense in
> the first read-through.

So, you're saying that this document doesn't make sense on a first 
reading?  I'm not suprized! :-)

>> @table @emph
>> @item cooked
>> @itemize @bullet
>> @item
>> manipulated by core @value{GDBN}
>> @item
>> correspond to user level, or abi registers
> 
> 
> Don't you mean "ISA" here, not "ABI"?  If I disassemble some code and
> see an instruction that refers to r12, then I should be able to see
> that register's value by saying "print $r12".  The ABI in use has
> nothing to do with it.

No, ABI.  For instance mipsIII and o32.  The o32 ABI thinks registers 
have 32 bits yet the real register has 64 bits.  This gives two views of 
the same register.  When o32 debug info indicates a value in two 
adjacent registers, it is refering to 32 bit and not 64 bit registers.

(Should user visible registers be displayed according to the underlying 
ISA or ABI is an item for debate.  It has never been specified and I 
suspect in part because GDB, prior to gdbarch_register_read/write, 
couldn't handle both.)

>> @end itemize
>> @item raw
>> @itemize @bullet
>> @item
>> manipulated by target backends
>> @item
>> correspond to physical registers
> 
> 
> I think you're introducing a new term here, "physical", which doesn't
> do anything for you.  When I see "physical", I think of actual
> flip-flops.  But that's clearly not what you're talking about: GDB has
> no idea how many ports these registers have, whether they get renamed
> for speculative execution, etc.

That was the intent.  The objective is to focus the reader on the target 
architecture's hardware and identify the registers that correspond to 
real hardware.  Often in GDB, people haven't focused on the hardware and 
its registers and instead stored cooked registers in the raw register 
cache.  See older SH and bank registers or d10v and its two stack pointers.

However, often, what GDB gets access to is actually the ``spill 
registers'' - the hardware registers saved to memory.  I guess I should 
refine this.

(Mind you, with a jtag target, it really is NAND and NOR gates :-)

> In effect, all that phrase does is define "raw" in terms of another
> undefined term, "physical".
> 
> By "raw", do you really mean the registers as presented by the
> underlying protocol GDB uses to examine the inferior (be it remote,
> /proc, or ptrace)?  I dunno.

I'll likely change it to ``hardware'', I think I've been using that term 
more consistently elsewhere.

>> @item
>> For a 64 bit architecture that is running in 32 bit mode, the register
>> cache and raw register space would contain the 64 bit hardware
>> registers.  The raw register space would not include cut down 32 bit
>> registers.
> 
> 
> By "32 bit mode", do you mean that there's an actual bit on the
> processor that makes shift, divide, etc. instructions behave as if
> there were only 32 bits?  Or do you mean an ABI that simply only uses
> the lower 32 bits of the registers?

Who knows --- target architecture dependant detail.  Some targets have a 
true 32 bit mode, some just run 32 bit ABI's on a 64 bit architectures. 
  The MIPS floating point registers and their various modes shows how 
tangled the web can get.

>> @item
>> For an architecture that has memory mapped registers, those registers
>> are not be part of the register cache or raw register space (there is no
>> corresponding hardware register).
> 
> 
> I think it would be nice to use the IA-64's arrangement as an example
> here.  I assume the raw registers would include the unrotated register
> file, and the registers that determine how they're rotated at the
> current point.  Whereas the cooked registers would be numbered the way
> they appear in the machine instructions.

As a description of memory registers or bank registers?  Your 
description of the IA-64 sounds more like bank selectable registers and 
similar --- the FP register stack of the i386 is an example that more 
people might be familar with.  (Remember we're talking theory here, 
neither the ia64 nor the i386 use this mechanism.)

Some architectures can refer to memory addresses using a register like 
notation.  In fact I know of one architecture where every memory 
location can also be refered to using a register notation.  Such an 
architecture would have zero raw registers.

>> @itemize @bullet
>> @item
>> registers refered to by debug information
>> @item
>> user visible registers (specified by name)
>> @item
>> mode dependant registers (e.g., a 64 bit architecture in 32 bit mode may
>> need to manipulate the 32 bits of 64 bit registers)
>> @item
>> memory mapped registers
>> space.
>> @item
>> state dependant registers (e.g., bank registers)
>> @end itemize
>> 
>> Architecture methods then map the @code{NUM_REGS + NUM_PSEUDO_REGS}
>> cooked registers onto raw registers or memory.
> 
> 
> So pseudo registers are different from cooked registers?  Or are they
> the same?  If they're the same, then distinguishing NUM_REGS and
> NUM_PSEUDO_REGS sort of implies that NUM_REGS corresponds to the
> number of raw registers.  But that shouldn't be visible to the outside
> at all.

Pseudo registers?  Beyond the constant NUM_PSEUDO_REGS, this section 
makes no reference to pseudo-registers.

I guess I should add an historical note to the opening section pointing 
out that the constant NUM_PSEUDO_REGS originated from an earlier 
mechanism called ``pseudo registers''.  While, for the moment, the 
constant remains, new targets use gdbarch register read/write and not 
pseudo registers.

> 
>> cooked:   [0..NUM_REGS)
>>                 |      \   
>>                 |       \  
>>                 |        \ 
>>                 |         \
>> raw:      RAW REGISTERS  MEMORY
> 
> 
> In other words, given that we're allowing cooked registers to be
> computed arbitrarily from raw registers and memory contents, why not
> dispense with pseudo registers altogether?

The need for pseudo registers was dispensed with a year ago.  Someone 
just needs to clean up the old targets and cleanup some edge cases .... 
  As for NUM_REGS, that defines the number of registers in the raw 
register cache (note below).

I'll add a comment mentioning the rationale behind direct mapping the 
first [0..NUM_REGS) registers.  It was firstly a case of K.I.S.S. and 
secondly due to suspected limitations in the current GDB code - the 
constant NUM_REGS unfortunatly still determines far more than the number 
of raw registers.  You may want to read the e-mail exchange between 
myself and RichardE as it contains all the gorry details.

I think I'll also add a simplified version of the diagraram to the 
opening section.

thanks for all the comments,

enjoy,
Andrew

Re: WIP: Register doco

[Andrew Cagney]

> The example of the IA-32's MMX and FP registers is a great example for
> this.  The MMX registers, MM0--MM7, and the FP registers,
> ST(0)--ST(7), actually refer to the same set of eight eighty-bit
> registers, R0--R7.  A reference to the floating-point register ST(i)
> becomes a reference to R((TOP + i) % 8), where TOP is a three-bit
> field in the FPU status register.  But a reference to the MMX register
> MM(i) becomes a reference to the lower 64 bits of R(i) (which would be
> the mantissa of some ST(i)).

(In the current code, ST(I) and not R(I) is stored, so we end up with 
MM(I) == regcache(FP0 + (TOP + 1) % 8) :-(   I'm almost ready to dust 
off the patch that does this.)

Anyway, I think the above example highlights why I see it as important 
to use terms like ``hardware'' or even ``physical''.  Those terms drag 
the GDB developer's eye away from those glossy user level ISA specs, and 
instead focuses their attention on the underlying hardware model used to 
implement the userland ISA. While well above the level of flip-flops, it 
is still a clear step below the ISA that a typical native GDB user will 
be aware of.  (A PPC refers to the ``operating environment architecture'').

For the i387, the programmer spec is all about a register stack, yet the 
underlying hardware uses a block of 8 registers and an index.  It is the 
latter, the lower level hardware details, that the GDB developer should 
focus their attention on when deciding the contents of a register cache.

> processors, then there are all sorts of confusing questions that
> brings up --- e.g., "How in the world would GDB get hold of the state
> of the raw flip-flops on a native Linux system?")

Clearly that isn't low level enough!  GDB needs to be getting down to 
the level of quantum effects :-^

There is a bit of irony here mind.  The i386 Linux kernel correctly 
provides a low-level hardware view of the i387 registers (the 8 register 
block and the index).   Current GDB however, by failing to abstract the 
raw register cache at that same low level, has ended up suffering from a 
series of obscure FP vs THREAD related register corruption bugs.

enjoy,
Andrew

Re: WIP: Register doco

[Jim Blandy]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> > The example of the IA-32's MMX and FP registers is a great example for
> > this.  The MMX registers, MM0--MM7, and the FP registers,
> > ST(0)--ST(7), actually refer to the same set of eight eighty-bit
> > registers, R0--R7.  A reference to the floating-point register ST(i)
> > becomes a reference to R((TOP + i) % 8), where TOP is a three-bit
> > field in the FPU status register.  But a reference to the MMX register
> > MM(i) becomes a reference to the lower 64 bits of R(i) (which would be
> > the mantissa of some ST(i)).
> 
> (In the current code, ST(I) and not R(I) is stored, so we end up with
> MM(I) == regcache(FP0 + (TOP + 1) % 8) :-(   I'm almost ready to dust
> off the patch that does this.)
> 
> Anyway, I think the above example highlights why I see it as important
> to use terms like ``hardware'' or even ``physical''.  Those terms drag
> the GDB developer's eye away from those glossy user level ISA specs,
> and instead focuses their attention on the underlying hardware model
> used to implement the userland ISA. While well above the level of
> flip-flops, it is still a clear step below the ISA that a typical
> native GDB user will be aware of.  (A PPC refers to the ``operating
> environment architecture'').
> 
> For the i387, the programmer spec is all about a register stack, yet
> the underlying hardware uses a block of 8 registers and an index.  It
> is the latter, the lower level hardware details, that the GDB
> developer should focus their attention on when deciding the contents
> of a register cache.

No, I think we need to draw the GDB developer's eye *to* those glossy
user-level ISA specs.  :) Figure 8-1 --- the first diagram in the
chapter titled "Programming with the X87 FPU" --- has R0 -- R7 right
there.  The second diagram, figure 8-2, shows how the TOP field
affects the relationship between ST(i) and Ri.  The fact that there is
a fixed set of registers accessed as a rotating stack is very much
part of the ISA documentation.

The chapter on MMX also gives the gorey details about how the aliasing
works.  It's not just for gee-whiz value --- you have to know this
stuff in order to write code which does both floating-point and MMX
operations.  Every MMX instruction sets the FPU's TOP field to zero,
for example.

As a sanity check, assuming that SPARC register windows are analogous:
the SPARC ISA spec talks about register windows immediately, as well.
Figure 2 in the chapter on Registers shows "Three Overlapping Windows
and the Eight Global Registers".  (For some reason, that makes me
think of Goldilocks and the Three Bears.)

So in both cases, these underlying structures are explicitly part of
the ISA.  The distinctions can be made clearly without going beyond
the ISA.  We don't need to resort to non-distinctions like "hardware
register" to make our point.

In cases like this one, where we're trying to draw a distinction
(between "cooked" and "raw" registers) whose exact meaning varies from
one architecture to the next, there is no way to really define what
you mean: each person doing a GDB port needs to get the gist of the
distinction, and see how it might help them best describe their
architecture to GDB.  The best way to do that is with a series of
examples showing how it applies to existing, well-known architectures.

I'd be happy to contribute text for those examples, if you agree they
would be useful.  At this point I've dug out the relevant parts of my
IA-32, SPARC, and IA-64 ISA manuals anyway.  :)

Re: WIP: Register doco

[Andrew Cagney]

> No, I think we need to draw the GDB developer's eye *to* those glossy
> user-level ISA specs.  :) Figure 8-1 --- the first diagram in the
> chapter titled "Programming with the X87 FPU" --- has R0 -- R7 right
> there.  The second diagram, figure 8-2, shows how the TOP field
> affects the relationship between ST(i) and Ri.  The fact that there is
> a fixed set of registers accessed as a rotating stack is very much
> part of the ISA documentation.

I was talking generally.

However looking at specific manual set(1) 
(http://developer.intel.com/design/pentium4/manuals), vol1 is the user 
stuff; vol3 is the system stuff.  The GDB developer needs to look beyond 
vol1 and and into vol3.  Vol1 8.1.10 Saving the x87 FPU's State with the 
FXSAVE Instruction, for instance, just points the reader at volume 3. 
In addition, the GDB developer ends up studying kernel interfaces and 
too often (ulgh!) kernel sources.

Taking a step back.  Cooked registers are at the level of the user 
and/or ABI.  Raw registers are at the level of the underlying 
system/hardware.  The GDB developer needs to be familar with both.  More 
importantly, and as I mentioned last time, we need to be very careful to 
ensure that the GDB developer looks beyond that user model and on down 
to the lower level details of the architecture.

> As a sanity check, assuming that SPARC register windows are analogous:
> the SPARC ISA spec talks about register windows immediately, as well.
> Figure 2 in the chapter on Registers shows "Three Overlapping Windows
> and the Eight Global Registers".  (For some reason, that makes me
> think of Goldilocks and the Three Bears.)

Just FYI, an example involving the SPARC is on my things todo list for 
frames.  It turns out that the OS for a register-window architecture 
typically flushes all but the inner most window to memory before 
transfering control to GDB.  Consequently the only raw registers that 
GDB sees are those that are innermost.  It is the frame, and not the 
register cache code, that needs to handle this one.

enjoy,
Andrew

(1) The ia32 manual set is badly organized.  Try figuring out the full 
set of registers (user and system) on, say, a p4.

Re: WIP: Register doco

[Daniel Jacobowitz]

On Sun, Jul 21, 2002 at 12:40:59PM -0400, Andrew Cagney wrote:
> 
> >No, I think we need to draw the GDB developer's eye *to* those glossy
> >user-level ISA specs.  :) Figure 8-1 --- the first diagram in the
> >chapter titled "Programming with the X87 FPU" --- has R0 -- R7 right
> >there.  The second diagram, figure 8-2, shows how the TOP field
> >affects the relationship between ST(i) and Ri.  The fact that there is
> >a fixed set of registers accessed as a rotating stack is very much
> >part of the ISA documentation.
> 
> I was talking generally.
> 
> However looking at specific manual set(1) 
> (http://developer.intel.com/design/pentium4/manuals), vol1 is the user 
> stuff; vol3 is the system stuff.  The GDB developer needs to look beyond 
> vol1 and and into vol3.  Vol1 8.1.10 Saving the x87 FPU's State with the 
> FXSAVE Instruction, for instance, just points the reader at volume 3. 
> In addition, the GDB developer ends up studying kernel interfaces and 
> too often (ulgh!) kernel sources.
> 
> Taking a step back.  Cooked registers are at the level of the user 
> and/or ABI.  Raw registers are at the level of the underlying 
> system/hardware.  The GDB developer needs to be familar with both.  More 
> importantly, and as I mentioned last time, we need to be very careful to 
> ensure that the GDB developer looks beyond that user model and on down 
> to the lower level details of the architecture.
> 
> >As a sanity check, assuming that SPARC register windows are analogous:
> >the SPARC ISA spec talks about register windows immediately, as well.
> >Figure 2 in the chapter on Registers shows "Three Overlapping Windows
> >and the Eight Global Registers".  (For some reason, that makes me
> >think of Goldilocks and the Three Bears.)
> 
> Just FYI, an example involving the SPARC is on my things todo list for 
> frames.  It turns out that the OS for a register-window architecture 
> typically flushes all but the inner most window to memory before 
> transfering control to GDB.  Consequently the only raw registers that 
> GDB sees are those that are innermost.  It is the frame, and not the 
> register cache code, that needs to handle this one.

"Typically" doesn't seem terribly useful... especially when debugging
through a monitor rather than ptrace.  I just worked on a GDB port to
an architecture which does not do this (and let me tell you, it's
awkward to deal with in GDB.  It will be much easier when some more of
your regcache work is finished.).  The frame code had to figure out
where in the register file to find the registers for the current (or
any other) frame.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: WIP: Register doco

[Andrew Cagney]

> 
> "Typically" doesn't seem terribly useful... especially when debugging
> through a monitor rather than ptrace.  I just worked on a GDB port to
> an architecture which does not do this (and let me tell you, it's
> awkward to deal with in GDB.  It will be much easier when some more of
> your regcache work is finished.).  The frame code had to figure out
> where in the register file to find the registers for the current (or
> any other) frame.

Outch!  BTW, typically == to the best of my knowledge all register 
windows targets (ignoring the m88k).

Andrew

Re: WIP: Register doco

[Daniel Jacobowitz]

On Mon, Jul 22, 2002 at 12:38:06PM -0400, Andrew Cagney wrote:
> >
> >"Typically" doesn't seem terribly useful... especially when debugging
> >through a monitor rather than ptrace.  I just worked on a GDB port to
> >an architecture which does not do this (and let me tell you, it's
> >awkward to deal with in GDB.  It will be much easier when some more of
> >your regcache work is finished.).  The frame code had to figure out
> >where in the register file to find the registers for the current (or
> >any other) frame.
> 
> Outch!  BTW, typically == to the best of my knowledge all register 
> windows targets (ignoring the m88k).

The target I'm working with used to do this; but it was somewhat
undesirable from an architecture standpoint.  So we moved the support
into GDB.  If I had a better register cache (the port was done vs 5.2,
which was almost but not quite there), it would have been almost
painless.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: WIP: Register doco

[Mark Kettenis]

Andrew Cagney <ac131313@ges.redhat.com> writes:

> > The example of the IA-32's MMX and FP registers is a great example for
> > this.  The MMX registers, MM0--MM7, and the FP registers,
> > ST(0)--ST(7), actually refer to the same set of eight eighty-bit
> > registers, R0--R7.  A reference to the floating-point register ST(i)
> > becomes a reference to R((TOP + i) % 8), where TOP is a three-bit
> > field in the FPU status register.  But a reference to the MMX register
> > MM(i) becomes a reference to the lower 64 bits of R(i) (which would be
> > the mantissa of some ST(i)).
> 
> (In the current code, ST(I) and not R(I) is stored, so we end up with 
> MM(I) == regcache(FP0 + (TOP + 1) % 8) :-(   I'm almost ready to dust 
> off the patch that does this.)

Oh dear, another confusing discussion about the IA-32's FP registers.
While the Intel manuals talk about the registers R0--R7, the ISA
doesn't really expose these.  Both the old fsave and the new fxsave
instructions store ST(I) and not R(I).  Until the introduction of the
Pentium MMX processor the R0--R7 registers really can be considered an
implementation detail, and the fact that the MMX instructions set TOP
to zero makes sure that as far as the MMX registers are concerned,
there still is something like an identity mapping between ST(I) and
R(I).

In other words, I consider the fact that GDB stores ST(I) and not
R(I), the right approach.

Mark

Re: WIP: Register doco

[Mark Kettenis]

Andrew Cagney <ac131313@ges.redhat.com> writes:

> > processors, then there are all sorts of confusing questions that
> > brings up --- e.g., "How in the world would GDB get hold of the state
> > of the raw flip-flops on a native Linux system?")
> 
> Clearly that isn't low level enough!  GDB needs to be getting down to 
> the level of quantum effects :-^

Hey, I knew my PhD in quantum physics would be useful for something ;-).

Re: WIP: Register doco

[Jim Blandy]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> > No, I think we need to draw the GDB developer's eye *to* those glossy
> > user-level ISA specs.  :) Figure 8-1 --- the first diagram in the
> > chapter titled "Programming with the X87 FPU" --- has R0 -- R7 right
> > there.  The second diagram, figure 8-2, shows how the TOP field
> > affects the relationship between ST(i) and Ri.  The fact that there is
> > a fixed set of registers accessed as a rotating stack is very much
> > part of the ISA documentation.
> 
> I was talking generally.
> 
> However looking at specific manual set(1)
> (http://developer.intel.com/design/pentium4/manuals), vol1 is the user
> stuff; vol3 is the system stuff.  The GDB developer needs to look
> beyond vol1 and and into vol3.  Vol1 8.1.10 Saving the x87 FPU's State
> with the FXSAVE Instruction, for instance, just points the reader at
> volume 3. In addition, the GDB developer ends up studying kernel
> interfaces and too often (ulgh!) kernel sources.

No, everything I cited was in volume 1, the user's manual set.  The
diagrams explaining the underlying fixed registers and the rotating
names for them are in the "user stuff" manual. 

I'm still trying to get a handle on your intent, though.  In a case
like MIPS III (an ISA with 64-bit registers) running o32 (an ABI which
only uses the lower 32 bits of each register), would you suggest that
printing registers in the usual way should show the full 64 bits of
the register, or only the lower 32 bits?

For the rest, all I'm saying is that the text you've written fails to
draw the distinction you need to make.  The term "hardware registers"
applies equally well to ST(0) and R0.  I've suggested a better way to
make the distinction in the rego document, i.e., by giving examples
showing how real architectures might use the distinction.  If you'd
like me to do that, just let me know.


> > As a sanity check, assuming that SPARC register windows are analogous:
> > the SPARC ISA spec talks about register windows immediately, as well.
> > Figure 2 in the chapter on Registers shows "Three Overlapping Windows
> > and the Eight Global Registers".  (For some reason, that makes me
> > think of Goldilocks and the Three Bears.)
> 
> Just FYI, an example involving the SPARC is on my things todo list for
> frames.  It turns out that the OS for a register-window architecture
> typically flushes all but the inner most window to memory before
> transfering control to GDB.  Consequently the only raw registers that
> GDB sees are those that are innermost.  It is the frame, and not the
> register cache code, that needs to handle this one.

Yeah, since there aren't any underlying protocols I know of that
actually give you all the SPARC register windows directly, the SPARC
would not be a good second example.  Perhaps the IA-64 with its
rotating registers for software-pipelined loops?

Re: WIP: Register doco

[Andrew Cagney]

>> I was talking generally.
>> 
>> However looking at specific manual set(1)
>> (http://developer.intel.com/design/pentium4/manuals), vol1 is the user
>> stuff; vol3 is the system stuff.  The GDB developer needs to look
>> beyond vol1 and and into vol3.  Vol1 8.1.10 Saving the x87 FPU's State
>> with the FXSAVE Instruction, for instance, just points the reader at
>> volume 3. In addition, the GDB developer ends up studying kernel
>> interfaces and too often (ulgh!) kernel sources.
> 
> 
> No, everything I cited was in volume 1, the user's manual set.  The
> diagrams explaining the underlying fixed registers and the rotating
> names for them are in the "user stuff" manual. 

Sorry, I'm lost here.

I was working my way through volume one and found, for some of the FP 
register stuff, it directed the reader to volume three.  Too completly 
understand the i387 FP stuff (for the P[34]) I need to [re-]read chunks 
from both the user and the system volumes.

Remember, my point was that the GDB developer needs to look beyond the 
user level documentation and on, into the system level documentation, 
and even kernel sources when designing GDB's register cache.  Even for 
the above case, that is true.

> I'm still trying to get a handle on your intent, though.  In a case
> like MIPS III (an ISA with 64-bit registers) running o32 (an ABI which
> only uses the lower 32 bits of each register), would you suggest that
> printing registers in the usual way should show the full 64 bits of
> the register, or only the lower 32 bits?

Sorry, I'm again lost.  I earlier wrote (note edits):

``No, ABI.  For instance mipsIII and o32.  The o32 ABI thinks registers 
have 32 bits yet the real register has 64 bits.  This gives two [cooked] 
views of the same [raw] register.  When o32 debug info indicates a value 
in two adjacent [cooked] registers, it is refering to 32 bit and not 64 
bit registers.''

I'm not discussing which of these should be printed since that is 
outside of the scope of this discussion.

> For the rest, all I'm saying is that the text you've written fails to
> draw the distinction you need to make.  The term "hardware registers"
> applies equally well to ST(0) and R0.  I've suggested a better way to
> make the distinction in the rego document, i.e., by giving examples
> showing how real architectures might use the distinction.  If you'd
> like me to do that, just let me know.

So "hardware" is as problematic as "physical"?  What you're telling me 
is that I should avoid all such terms, right?

>> > As a sanity check, assuming that SPARC register windows are analogous:
>> > the SPARC ISA spec talks about register windows immediately, as well.
>> > Figure 2 in the chapter on Registers shows "Three Overlapping Windows
>> > and the Eight Global Registers".  (For some reason, that makes me
>> > think of Goldilocks and the Three Bears.)
> 
>> 
>> Just FYI, an example involving the SPARC is on my things todo list for
>> frames.  It turns out that the OS for a register-window architecture
>> typically flushes all but the inner most window to memory before
>> transfering control to GDB.  Consequently the only raw registers that
>> GDB sees are those that are innermost.  It is the frame, and not the
>> register cache code, that needs to handle this one.
> 
> 
> Yeah, since there aren't any underlying protocols I know of that
> actually give you all the SPARC register windows directly, the SPARC
> would not be a good second example.  Perhaps the IA-64 with its
> rotating registers for software-pipelined loops?

If this section needs an example then (given MarkK's observation about 
the i387) then either d10v's two stack pointers or the SH's bank 
registers.  Neither of these are especially complicated.

Andrew

Re: WIP: Register doco

[Jim Blandy]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> So "hardware" is as problematic as "physical"?  What you're telling me
> is that I should avoid all such terms, right?

I'm saying that they're unhelpful terms in drawing a distinction
between cooked and raw registers, and that a better approach would be
to provide examples of how the distinction allows GDB to cleanly
describe one or two well-known architectures.

In situations where the contrast being drawn is obvious, "hardware"
and "physical" are fine terms.  For example, if one were writing about
how stubs return from exceptions they've trapped, one could talk about
the necessity to restore the values of the "hardware registers" from
the stub's working copy.  There it's clear.

But in the present discussion, neither the raw and the cooked
registers are closer to the "hardware" --- they both describe entities
that have some reality in the "hardware".  So the term isn't helpful.
It's a public placeholder for a private intuition.  It lets the writer
think they've made their point, while leaving the reader in the dark.

> If this section needs an example then (given MarkK's observation about
> the i387) then either d10v's two stack pointers or the SH's bank
> registers.  Neither of these are especially complicated.

But... but the IA-32's FP and MMX hair is, like, the canonical
motivation for the cooked/raw distinction.  You've said repeatedly
that a GDB developer needs to understand this distinction.  That makes
it a *good* example, right?  I think it's one of the best ---
especially since it's something familiar to a lot more people than the
d10v and the SH.

Re: WIP: Register doco

[Jim Blandy]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> > I'm still trying to get a handle on your intent, though.  In a case
> > like MIPS III (an ISA with 64-bit registers) running o32 (an ABI which
> > only uses the lower 32 bits of each register), would you suggest that
> > printing registers in the usual way should show the full 64 bits of
> > the register, or only the lower 32 bits?
> 
> Sorry, I'm again lost.  I earlier wrote (note edits):
> 
> ``No, ABI.  For instance mipsIII and o32.  The o32 ABI thinks
> registers have 32 bits yet the real register has 64 bits.  This gives
> two [cooked] views of the same [raw] register.  When o32 debug info
> indicates a value in two adjacent [cooked] registers, it is refering
> to 32 bit and not 64 bit registers.''
> 
> I'm not discussing which of these should be printed since that is
> outside of the scope of this discussion.

(Sorry, the `what would this print' is a distraction.)

Suppose I have a program compiled to the o32 ABI which has a 64-bit
variable that the debug info says is in $a0.  I'm running it on a MIPS
III machine.  This means that half of my variable is in the low 32
bits of $a0, and the the other half is in the low 32 bits of $a1.

So, when you say that cooked registers are "ABI registers", are you
saying that, in the cooked register set, $a0 and $a1 would be 32-bit
registers, even though we're executing a 64-bit instruction set?
Having the register sizes disagree with the actual instructions being
executed is what seems like a bad idea to me.

Re: WIP: Register doco

[Andrew Cagney]

> If this section needs an example then (given MarkK's observation about
>> the i387) then either d10v's two stack pointers or the SH's bank
>> registers.  Neither of these are especially complicated.
> 
> 
> But... but the IA-32's FP and MMX hair is, like, the canonical
> motivation for the cooked/raw distinction.  You've said repeatedly
> that a GDB developer needs to understand this distinction.  That makes
> it a *good* example, right?  I think it's one of the best ---
> especially since it's something familiar to a lot more people than the
> d10v and the SH.

The original motivation for this model was work by David Taylor for an 
architecture that dual ported all of memory (memory == register). 
Additional motivations came from SH4 (sh5 proved the model), d10v and 
MIPS.  The i386 was but a blip on the horizon.

Given we're struggling amonst ourselves with the IA-32 I think that 
suggests it is a very poor choice for an example.  Especially given 
there are better cleaner examples to be had using other familar 
architectures.  I would assume this is why people like H&P chose DLX 
when describing CPU architectures.

enjoy,
Andrew

Re: WIP: Register doco

[Andrew Cagney]

>> Sorry, I'm again lost.  I earlier wrote (note edits):
>> 
>> ``No, ABI.  For instance mipsIII and o32.  The o32 ABI thinks
>> registers have 32 bits yet the real register has 64 bits.  This gives
>> two [cooked] views of the same [raw] register.  When o32 debug info
>> indicates a value in two adjacent [cooked] registers, it is refering
>> to 32 bit and not 64 bit registers.''
>> 
>> I'm not discussing which of these should be printed since that is
>> outside of the scope of this discussion.
> 
> 
> (Sorry, the `what would this print' is a distraction.)
> 
> Suppose I have a program compiled to the o32 ABI which has a 64-bit
> variable that the debug info says is in $a0.  I'm running it on a MIPS
> III machine.  This means that half of my variable is in the low 32
> bits of $a0, and the the other half is in the low 32 bits of $a1.
> 
> So, when you say that cooked registers are "ABI registers", are you
> saying that, in the cooked register set, $a0 and $a1 would be 32-bit
> registers, even though we're executing a 64-bit instruction set?
> Having the register sizes disagree with the actual instructions being
> executed is what seems like a bad idea to me.

As I pointed out in the above, there are two cooked $a0's.  One is 32 
bits and one is 64 bits.  With regard to which should be user visible, I 
wrote:

``(Should user visible registers be displayed according to the 
underlying ISA or ABI is an item for debate.  It has never been 
specified and I suspect in part because GDB, prior to 
gdbarch_register_read/write, couldn't handle both.)''

It was in paren because I want to first fix the regcache (and its doco). 
  That debate can be left to when someone has the cycles spare for 
fixing it.

enjoy,
Andrew

Re: WIP: Register doco

[Jim Blandy]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> >> Sorry, I'm again lost.  I earlier wrote (note edits):
> >> ``No, ABI.  For instance mipsIII and o32.  The o32 ABI thinks
> >> registers have 32 bits yet the real register has 64 bits.  This gives
> >> two [cooked] views of the same [raw] register.  When o32 debug info
> >> indicates a value in two adjacent [cooked] registers, it is refering
> >> to 32 bit and not 64 bit registers.''
> >> I'm not discussing which of these should be printed since that is
> >> outside of the scope of this discussion.
> > (Sorry, the `what would this print' is a distraction.)
> > Suppose I have a program compiled to the o32 ABI which has a 64-bit
> > variable that the debug info says is in $a0.  I'm running it on a MIPS
> > III machine.  This means that half of my variable is in the low 32
> > bits of $a0, and the the other half is in the low 32 bits of $a1.
> > So, when you say that cooked registers are "ABI registers", are you
> > saying that, in the cooked register set, $a0 and $a1 would be 32-bit
> > registers, even though we're executing a 64-bit instruction set?
> > Having the register sizes disagree with the actual instructions being
> > executed is what seems like a bad idea to me.
> 
> As I pointed out in the above, there are two cooked $a0's.  One is 32
> bits and one is 64 bits.

Wow.  I read what you wrote, but I didn't get that.  So, there are
going to be two cooked register numbers for $a0, depending on whether
one is looking at it from the ABI point of view --- like debug info
does --- or from the ISA point of view.  Is that right?

Re: WIP: Register doco

[Jim Blandy]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> Given we're struggling amonst ourselves with the IA-32 I think that
> suggests it is a very poor choice for an example.  Especially given
> there are better cleaner examples to be had using other familar
> architectures.  I would assume this is why people like H&P chose DLX
> when describing CPU architectures.

It's my understanding that folks disagree about exactly what the raw
bits should be.  But we all agree that the raw registers should
represent the actual underlying bits only once, and that MMi / ST(j)
should be cooked registers that alias each other in the right way.  Is
that much, at least, correct?

Re: WIP: Register doco

[Andrew Cagney]

> Andrew Cagney <ac131313@ges.redhat.com> writes:
> 
>> >> Sorry, I'm again lost.  I earlier wrote (note edits):
>> >> ``No, ABI.  For instance mipsIII and o32.  The o32 ABI thinks
>> >> registers have 32 bits yet the real register has 64 bits.  This gives
>> >> two [cooked] views of the same [raw] register.  When o32 debug info
>> >> indicates a value in two adjacent [cooked] registers, it is refering
>> >> to 32 bit and not 64 bit registers.''
>> >> I'm not discussing which of these should be printed since that is
>> >> outside of the scope of this discussion.
> 
>> > (Sorry, the `what would this print' is a distraction.)
>> > Suppose I have a program compiled to the o32 ABI which has a 64-bit
>> > variable that the debug info says is in $a0.  I'm running it on a MIPS
>> > III machine.  This means that half of my variable is in the low 32
>> > bits of $a0, and the the other half is in the low 32 bits of $a1.
>> > So, when you say that cooked registers are "ABI registers", are you
>> > saying that, in the cooked register set, $a0 and $a1 would be 32-bit
>> > registers, even though we're executing a 64-bit instruction set?
>> > Having the register sizes disagree with the actual instructions being
>> > executed is what seems like a bad idea to me.
> 
>> 
>> As I pointed out in the above, there are two cooked $a0's.  One is 32
>> bits and one is 64 bits.
> 
> 
> Wow.  I read what you wrote, but I didn't get that.  So, there are
> going to be two cooked register numbers for $a0, depending on whether
> one is looking at it from the ABI point of view --- like debug info
> does --- or from the ISA point of view.  Is that right?

An architecture is free to provide multiple views onto a single hardware 
register, yes.  In the case of the MIPS that technique is likely to be 
useful as a clean way of mapping debug registers onto raw registers.  It 
isn't, however, a requirement --- the typical architecture will have a 
1:1 cooked:raw mapping.  BTW, did you get a chance to read through the 
discussions between RichardE and myself where we when through 
implementation details like this?

Andrew

Re: WIP: Register doco

[Andrew Cagney]

> Andrew Cagney <ac131313@ges.redhat.com> writes:
> 
>> Given we're struggling amonst ourselves with the IA-32 I think that
>> suggests it is a very poor choice for an example.  Especially given
>> there are better cleaner examples to be had using other familar
>> architectures.  I would assume this is why people like H&P chose DLX
>> when describing CPU architectures.
> 
> 
> It's my understanding that folks disagree about exactly what the raw
> bits should be.  But we all agree that the raw registers should
> represent the actual underlying bits only once, and that MMi / ST(j)
> should be cooked registers that alias each other in the right way.  Is
> that much, at least, correct?

Yep.

Andrew