Re: Multiplexed registers and invalidating the register cache

[Andrew Cagney <cagney at gnu dot org>]

> Andrew Cagney wrote:
>
> > Simpler, "target_changed" - no parameters.
>
>
> Hm. observer.texi says "all events must take at least one parameter", but having an event without a parameter worked fine.  I assumed observer.sh would yell at me, but it didn't ;) .

Oops, yes, pass the current_target (I ment that it shouldn't have a 
parameter trying to tell the observers anything beyond the fact that the 
target has changed).  (the sed script generates () instead of (void)).

> But wouldn't it make sense to have the register number parameter, and based on that determine (in target-specific code) whether to flush the frame cache and registers?  Or was that part of the cost discussion between you and Daniel, and what you're saying is that "whenever *any* register is changed in *any* target, flush the frame and register cache"?

There are architectures where registers live in memory so the 
information is simply misleading.

> > The core code, after doing the write, should trigger this event ...
> >
> > > In addition, someone needs to notify that the event has happened, but I assume these notifications should be inserted at the same places that register_changed_hook is called for GUI purposes.
> >
> >
> >
> > ... [yes] replacing registers changed.
>
>
> ... meaning all calls to registers_changed should be changed into calls to observer_notify_target_changed?

Eventually, yes.  The two can co-habitate for a bit, first just:

- add the observer
- add code to frame.c and regcache.c to register themselves
- add code to the problem area to trigger the observer

> Also, if the observer should a generic
>
>   void
>   observer_target_changed (void)
>   {
>     registers_changed ();
>     flush_cached_frames ();
>   }
>
> instead of target-specific one (I couldn't infer that from your answer), where should it go?

sorry, I'm lost

Andrew