Re: Multiplexed registers and invalidating the register cache

[Daniel Jacobowitz <drow@false.org>]

On Wed, Apr 14, 2004 at 01:44:43PM +0200, Orjan Friberg wrote:
> Hi all,
> 
> I'm working on support for a CPU where some of the registers are in a 
> bank selected by another register, meaning that changing the bank select 
> register changes the contents (and meaning) for a whole set of other 
> registers.
> 
> The target is a remote stub, and the way I've pictured this in my head a 
> change to the bank select register (via a 'P' packet) invalidates the 
> register cache, causing the whole register contents to be fetched again 
> (with a 'g' packet).  (The remote stub needs to re-read the affected 
> registers upon the write of the bank select register, of course.)
> 
> Is there some sort of "write register" hook I could use to indicate that 
> the registers should be fetched again if the bank select register is 
> written to?  I followed what happens when doing a "set $register", but I 
> couldn't find any such hook in that path.

I think you should make this change unconditionally - and flush the
entire frame cache.  I'm not sure whether it should be in the generic
code that writes a register or the user-level code triggered by set
$reg = val, though.

I've been meaning to do this for a long time.  For instance, there is a
writeable register on PowerPC targets which has some read-only bits. 
Right now, if you set it to an arbitrary value and then print it you'll
get the value GDB wrote - not the value that was actually accepted into
the register.

Andrew convinced me that the performance cost associated with this
would be small in practice.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer