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

[f-cpu] More Dark and Dusty Corners



Hi!

Again, some ambiguities crossed my way.  This time it's all about
user/supervisor mode, context switching, SRB, nested interrupts and so on.
I hope it's not too confusing; this is rather complex stuff that isn't
easily groked at the first glance (I'm not quite sure whether *I* grok
everything -- and I may have overlooked some important details).

First of all, how do we detect supervisor mode?  I guess there should be
a special register indicating the current privilege level.  Bit 0 will
be the `supervisor' bit, all other bits are reserved and must be zero
(we can later refine the model to include specific privileges, similar
to capabilities in the linux kernel).

When doing a context switch, the `privilege' SR should be loaded from
the new CMB before any other operation is performed.  Remember that
the F-CPU might be interrupted in supervisor mode, and must be able to
return to that mode when `rfe' is executed.

Apropos `rfe'/interrupts: something that is not clear yet is what
happens when the F-CPU is interrupted.  Is it supposed to perform
a full context switch in all cases?  That might be overkill in some
situations, especially when the interrupt handler is short.  What happens
if the IRQ handler reaches the final `rfe' before the SRB is finished?
According to the manual, the running SRB must finish before a new one
can be started, but that's not appropriate -- why finish something you
have to undo anyway?

Another problem is nested interrupts.  When each interrupt (or exception)
causes a context switch, we need a CMB stack -- on the second interrupt,
the context of the first IRQ handler must be saved, and it must be
properly restored when the "inner" handler returns.  If we don't
permit an IRQ to interrupt its own handler (that is, block it until
the corresponding `rfe'), we may get away with one CMB per possible
IRQ/exception, but that's already a whole lot of CMBs.  Oh by the way:
we need an `interrupt enable' SR, too.

There are several instructions which cause a user/supervisor mode
transition and/or a context switch: `syscall'/`trap', `rfe' and `halt'.
`rfe' is supposed to undo the effects of `syscall'/`trap' as well as
those of an IRQ or exception; that means it needs to know *what* to
undo if syscall, IRQs and exceptions act differently.  This information
must be saved somewhere, and must not be overwritten when a nested
interrupt returns (that means we need an "invocation stack" here, too).

One question is what to do when an IRQ/exception/syscall/rfe occurs.
Always switching contexts is too expensive, IMHO.  Switching only under
certain conditions makes `rfe' a very complex task (similar to `iret'
on Intel CPUs, which is a real nightmare).  On the other hand, we have to
save and restore certain items -- return address, privileges, interrupt
mask, maybe the contents of other special registers -- in order to be
able to return to the original state.  And we *may* want to preload some
special registers when entering supervisor mode in order to put the CPU
into a defined state.  But shall we really preload the general registers
from memory when an interrupt occurs, and save them before we return to
the interrupted task?  Or discard their contents when `rfe' is executed?
IMHO, we should leave that decision to the programmer.

Whether or not we do a full context switch on each IRQ/exception,
we always need a kind of "invocation stack" in order to handle nested
interrupts properly.  If we change CMBs, there must be at least one
CMB pointer for each possible interrupt source (assuming an interrupt
never interrupts its own handler, which may not be possible for some
exceptions), or a stack of CMBs.  If we don't, we need at least some space
for the return address, privileges, and interrupt mask of the interrupted
program, plus pointers to the current and last "invocation records" for
`rfe'.

I'd better stop now before my head starts spinning ;)  But that
doesn't mean that this topic is dead and buried now, not at all.

CU,
-- 
 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/