Re: pseudo registers in the regcache

[Andrew Cagney <ac131313@cygnus.com>]

> Grepping through the sources for the targets that were using regcache 
> entries for pseudos it turns out that in current CVS only two targets are 
> using pseudos at all: sh and mc68hc11.
> 
> 
> The sh code is known not to put its pseudos in the regcache, which only 
> leaves the mc68hc11.

Elena?  Is the sh5 clear of all edge conditions?

The mc68hc11 pre-dates register_{read,write}.

> Looking at that code it appears that it uses the pseudos for registers 
> that are really part of the memory map, so it seems like we are really 
> overloading the "pseudo" name for two different things.

The origins of the register_{read,write} stem from a target David Taylor 
encountered that needed to represent memory locations as registers! 
Code that was caching memory values in the register cache had [obvious] 
coherency problems.

> How about renaming the 68k stuff as being MEMORY_REGS and reserving the 
> PSEUDO concept for what we really seem to want -- a view of a (or a 
> combination of) physical (or memory) register(s)?

Or update mc68hc11 :-)

> That would, I think allow us to say that pseudos are never in the regcache 
> and it should simplify many bits of code significantly.

> Oh, and I'd make NUM_REGS (the define) be NUM_PHYS_REGS + NUM_MEMORY_REGS 
> so that gdb-core sees these as a single resource (ie the separation is 
> below gdb-core).

No need.

Andrew

PS:  Or NUM_COOKED_REGS being NUM_RAW_REGS + NUM_PSEUDO_REGS?  Something 
like that is on a few hit lists.  I've been resisting the temptation to 
do this since it was noise compared to eliminating registers[].