Re: [rfc] read_register_gen(...) -> cooked_register_read (current_regcache,...)

[Andrew Cagney <ac131313 at ges dot redhat dot com>]

To flesh this out a bit more (now that I've tried it).  I would like to 
propose:


Functions for manipulating the raw cache:

regcache_raw_read() (was regcache_read())
regcache_raw_write() (was regcache_write())


Functions for using the raw cache to construct ``cooked'' registers. 
Cooked registers being in the range [0 .. NUM_REGS + NUM_PSEUDO_REGS) 
and are constructed using the multi-arch methods gdbarch register 
read/write:

regcache_cooked_read() (was kind of read_register_gen())
regcache_cooked_write() (was kind of write_register_gen())


So far not too much has switched to using regcache read/write.  There 
are ~83 read/write register gen call.

The question is really, is ``cooked'' an acceptable term for 
differentiating between the raw and non-raw ways of accessing registers?

Time to write that doco ...

Andrew




> Hello,
>
> I wrote:
>
> Note the fixme though:
>
> +      /* FIXME: cagney/2002-06-26: This should be via the
> +         gdbarch_register_read() method so that it, on the fly,
> +         constructs either a raw or pseudo register from the raw
> +         register cache.  */
> +      regcache_read (registers, regnum, bufferp);
>
> I've opened a change-request against that one.
> I'd like to propose a new pair of functions
>
>     cooked_register_read(regcache, regnum, buff)
>     cooked_register_write(regcache, regnum, buff)
>
> that provide a superset of the functionality found in read_register_gen() and write_register_gen().
>
> I'd also replace the read_register_gen() / write_register_gen() calls with calls to these functions but with a current_regcache parameter.
>
> thoughts?
>
> If this change looks good, I'm ready to do that long promised documentation.
>
> enjoy,
> Andrew