Re: WIP: Register doco

[Andrew Cagney <ac131313@ges.redhat.com>]

> 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