[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [f-cpu] Smooth Register backup issues...
Christophe Avoinne wrote:
----- Original Message -----
From: "Michael Riepe" <firstname.lastname@example.org>
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
"exx" and "ex A, A'" ? :-)
interrupts very quickly -- just swap the registers on entry and exit
of the interrupt service routine.
Did anybody say "Zilog Z80"? ;)
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.
that, by itself, is bogus : you double the size of what certainly
constitutes the slowest
To be sure to understand what you mean :
- there are two independant register-sets, only one of which you can
part of the FC0 core, and that with _no_ gain in performance. On top of
one half of these transistors will sit idle 99,99% of the time.
on IRQ, the handler's code contains the addresses in constants within
the first instructions.
- 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 ?
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.
Still I see a problem : we must preload the values of new registers from thethere is an explicit instruction for SRB that says : 'restore the
previous context' so it's ok.
new CMB context, especially when switching between tasks. How do you plan
that ? have an explicit instruction to reload the new register set ?
BUT Michael's idea can increase the latency terribly, when compared to
which can start execute the next context as soon as the first registers
/me should really go out and buy these potentiometers, now.
To unsubscribe, send an e-mail to email@example.com with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/