[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] Supported Instructions



On Sun, Apr 07, 2002 at 10:17:52AM +0200, Christophe wrote:
[...]
> > there is a problem, however : if the code is faster than the SRB mechanism,
> > we'll read the old value from the CMB. worst, we could interrupt the SRB
> > to resume the task, but the result can reside in a register which has not
> > been "touched" by our routine. The effect is that upon return, the result
> > might not be updated.
> 
> Sorry, but it is an issue for a programmer : he/she shouldn't try to resume the
> task before setting the result.

Of course not - but that's not the point.

When a task generates an `invalid instruction' trap, the SRB is triggered
and a task switch is performed. When the interrupt handler is going to
access a register for the first time, the SRB must save its contents to
the CMB of the interrupted task. On return, the SRB starts again and
restores all registers that have been saved/modified by the interrupt
handler.

<Special Note>

If the new task reads the register's value (or performs a partial write),
the SRB must also fetch the value from the current tasks CMB before the
instruction is executed. That is, register values persist between handler
invocations.

<Special Note #2>

It might be reasonable to provide two versions of the `return from
exception' instruction, i.e. one that saves the handler's registers to
the handler's CMB, and one that discards all changes and just restores
the register values of the interrupted task. Alternatively, we could
implement only the second one und use an explicit `srb_save' instruction
if we need persistency.

<Special Note #3>

In either case, an interrupt handler must never interrupt itself,
directly or indirectly, unless each invocation has its own CMB.

<Return From Cloud Nine>

You have to make sure that the SRB has completed (i.e. that all registers
have been saved) before you can read arbitrary registers from the
interrupted task. Otherwise, the CMB may contain wrong values.

A register that has not been saved won't be restored either when the
interrupted task resumes. For this reason, writing a new value into
the CMB only works when the register has been saved; otherwise, the
new value will simply be lost.

That is, our hypothetical `invalid instruction' handler will have to
cause the SRB to save (on entry) and reload (on return) at least all
registers that are affected by the emulated instruction.

Personally, I think that performing a task switch *every time* the CPU
enters or leaves an interrupt/trap handler is inefficient. But I already
stated that a while ago.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/