allowing target to say which regs are pseudo regs

allowing target to say which regs are pseudo regs

[Doug Evans]

Would it make sense to allow a target to say which regs are pseudo regs?

i.e. make real_register() and pseudo_register() architecture-provided routines
[well, to be more precise, you'd just have one routine of course]

It seems rather clumsy to force a target to have registers
[0,NUM_REGS) be "real" regs and [NUM_REGS,NUM_REGS+NUM_PSEUDO_REGS)
be "pseudo" regs.  What's the difference other than
targets get to provide their own read/write routines for pseudo regs?

One would want to replace NUM_REGS and NUM_PSEUDO_REGS with
just NUM_REGS [or some such], and there'd be a set of corresponding
changes throughout the sources.

Re: allowing target to say which regs are pseudo regs

[Andrew Cagney]

Doug Evans wrote:
> 
> Would it make sense to allow a target to say which regs are pseudo regs?
> 
> i.e. make real_register() and pseudo_register() architecture-provided routines
> [well, to be more precise, you'd just have one routine of course]
> 
> It seems rather clumsy to force a target to have registers
> [0,NUM_REGS) be "real" regs and [NUM_REGS,NUM_REGS+NUM_PSEUDO_REGS)
> be "pseudo" regs.  What's the difference other than
> targets get to provide their own read/write routines for pseudo regs?
> 
> One would want to replace NUM_REGS and NUM_PSEUDO_REGS with
> just NUM_REGS [or some such], and there'd be a set of corresponding
> changes throughout the sources.

Doug,

Check the mailing list archives over the last few months for postings by
me.  There should be several articles explaing the general direction
that the register framework is going in.

Also check thread between my self and david taylor that resulted in the
addition of gdbarch_register_read/write.

Finally, check the 5.2 TODO list and just make certain that you're not
thinking of using any of those obsolete macros.

The distinction is slowly going away.

	Andrew