[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [f-cpu] Smooth Register backup issues...
Le Samedi 15 Novembre 2003 15:56, Yann Guidon a écrit :
> Michael Riepe wrote:
> > Hi gang,
> > email@example.com wrote:
> > An (asynchronous) interrupt will suspend the running task for a while,
> > and
> > then return to it. A task switch stops the current task and start a
> > new one. A software interrupt (e.g. system call) is similar to a
> > hardware interrupt but will run in the context of the current task
> > (i.e. no SRB is performed).
> At least some context must be saved ! access rights (properties), PC (in
> case the system calls traps,
> we want to be able to locate the offending call location) and PC+4 (so
> we return nicely).
> > When a task is created, the OS will allocate a CMB for it. When the OS
> > (or the CPU) switches from task A to task B, the CPU will have to save
> > register values to the CMB of task A and load new values from the CMB of
> > task B. It can do so beforehand or on an as-needed basis.
> Just like "old school SRB".
> > With shadow
> > registers, it could swap register banks, trigger an SRB-SAVE for the now
> > invisible bank, switch CMBs and start running the new task, performing
> > an SRB-RESTORE while it continues.
> why do i see only drawbacks with shadow registers ?
> except that it /may/ be a few cycles faster than "old school SRB",
> there are no benefit.
Benefit are clear : in the common case it's the fastest (simple it handler).
in case of the use of SRB you must save it and then restore it.
OOOc didn't change anything. You have to take care of it in both case.
> and simply switching banks does not take into account
> the pipeline that needs some synchronisation because of the *OOOC*
> scheduling. If i blindly follow your description,
> "late" results from the interrupted task will land in the
> alternate bank, thus corrupting both the saved CMB
> (which will not be complete) and the new task.
Why ? The problem are the same with CMB : how knowing if the register saved
aren't still inside the pipeline.
One easy way is to add an adresse bit for the write port at the beginning of
the pipeline and there isn't any problem any more.
> If you solve this, you end up doing the same thing as "old school SRB" :
> tracking whose task each register belongs and adding flags to
> keep coherency. Back to the beginning.
> > Hardware interrupts work similar, but they usually have no task context.
> well, they have no _previous_ state, it's like spawning a thread out of
> The kernel can also allocate a CMB if the handler is known to be recursive.
And what's up if there is an it because of tlb miss ?
> read you soon,
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/