[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [f-cpu] Smooth Register backup issues...



> hello,
>
> Martin Vahi wrote:
>
>>>Or ARM. That's called swadow register. The problem with SRB is :
>>>- how do you handle nested interrupt ?
>>>
> this is exactly the same problem with shadow registers and hardware
> stacks.
> same problem, same solution.

Not really. With shadow register, all the stuf are maid by software and
could be quite fast, simple and effiscient. And this is very flexible for
all kind of OS. Otherwise it look like a "half" hardware scheduler which
look like x86 VM.

>
>>>- how do you "allocate" a new CMB ?
>>>
> through the OS. In a device driver,
> when you install an IRQ handler,
> you allocate a CMB if your IRQ routine is interruptibe.
> this case has been already discussed for a long while.
>

Yep but has been never completly fixed. You forced a lot of things in how
the OS should manages all of this.

>
>>>- If saving is automatique even on very light it handler you must save
>>> all
>>>of the register.
>>>
>>>
> This case can be solved with the help of the hidden "dirty" flags
> which indicate whether a register has been modified since SRB has
> been started.
>

In a normal way, all register are dirty. It's the it handler which knows
that it will not use many registers.

> You also seem to infer that the backup does not let handler's code run.
> in fact, SRB is designed so that the IRQ handler can start servicing
> hardware
> request as soon as the instructions are available. In a "normal" system,
> fetching the new code will already take 10 or 20 clock cycles (considering

In "big" it handler that's a win but it is a big loose in light one. With
shadow register, the "average case" need no cycle at all to begin.

> that misses etc). By that time, SRB will have saved 10 to 20 registers,
> that is, roughly one third of the register set. Now, if the IRQ handler
> has to "speak" with I/O, this takes several cycles each time the
> peripheral is accessed so SRB will continue without problem.
>

Such things are never done in IT context.

> Now, in case of cached code for handling page miss, for example,
> the hidden "dirty" flag will record what register has been saved or not
> and what register belongs to which "thread". Since TLB miss handlers
> are not interruptible and "terminal", there is no worry about allocating
> an
> additional CMB. So SRB can then be interrupted (the only case where
> it is possible) to restore the faulty thread as soon as the TLB is
> updated.
>

That sound like a big mess with so much execption, side effect... KISS :)


>
>>  But would a "shadow stack" be a bad idea? Like, instead of
>>one shadow-register, there would be, let's say, 1000-level deep stack??
>>OK, it takes up some mount of silicon or some quantity of gates in the
>>FPGA case, but it should work somehow...
>>
> it "works" for such CPU as SPARC or NIOS.

thats register windows. Not shadow register.

nicO

>>Regards,
>>  Martin Vahi
>>
>>
> YG
>
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
>

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/