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

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

hi,

Christophe Avoinne wrote:
----- Original Message -----
From: "Michael Riepe" <michael@stud.uni-hannover.de>


I prefer a double-buffering approach: The "shadow" register is loaded
from the new ("incoming") CMB, while the "foreground" register is
saved to the old ("outgoing") CMB.  As soon as the shadow is loaded,
register and shadow can be swapped (by flipping an address or enable
bit).  That way, a direct connection between a register and its
shadow counterpart is not required since you never have to transfer
data between them.


let me get a better picture :
- there are 2 instances of the register set's "memory array"
- these 2 share data connexions to the Xbar (3 out, 2 in) and 2
    connexions to ... memory (1 in, 1 out) for backup/restore.
So not only you double the area (and reduce the clock speed)
but you also need to multiplex the data busses.

OTOH, SRB uses only one single bank (with added control/flags)
and the existing connexion to the Xbar so it can flush data to the LSU.
In addition to that, it enables you to process
interrupts very quickly -- just swap the registers on entry and exit
of the interrupt service routine.

Did anybody say "Zilog Z80"? ;)

"exx" and "ex A, A'" ? :-)

this also exists in certain DSPs.
yet, even though the switch occurs in virtually 1 cycle,
there is enough code around it to compensate negatively
for the gain.


To be sure to understand what you mean :

- there are two independant register-sets, only one of which  you can
access.
that, by itself, is bogus : you double the size of what certainly constitutes the slowest
part of the FC0 core, and that with _no_ gain in performance. On top of that,
one half of these transistors will sit idle 99,99% of the time.

- when executing a CMB switching, you just implicitely select the other set
so that old registers can be saved in old CMB context, and we can continue
to run code with the new registers without write-back memory delay penalty.
For interrupt, it may be very interesting if we dont need to read the values
of registers ( the stack pointer is fixed-address at raising interrupt ?
on IRQ, the handler's code contains the addresses in constants within the first instructions.
from there, it can access its private areas.

what about the reentrance ? ).

If the IRQ handler can be interrupted, then the driver has requested a CMB block to the OS.
so when the handler is ready to accept new IRQs, it just puts its CMB address in the SR_NEXT
and enables IRQs.

I remember i had posted code for that.
long ago.

Still I see a problem : we must preload the values of new registers from the
new CMB context, especially when switching between tasks. How do you plan
that ? have an explicit instruction to reload the new register set ?

there is an explicit instruction for SRB that says : 'restore the previous context' so it's ok.
BUT Michael's idea can increase the latency terribly, when compared to the SRB
which can start execute the next context as soon as the first registers and opcodes
are available.

/christophe

YG

/me should really go out and buy these potentiometers, now.

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