[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [f-cpu] Smooth Register backup issues...
if you want to allocate CMBs "on the fly", you're free to waste clock
I just add that :
- SRB system did not gain many cycles. It gain cycle only on nested
interrupt IF you could alloc a CLB without other trapping problem.
now, modern OS kernels allocate some room to manage each thread and process.
i don't see why it's impossible to allocate a portion of that space to
registers : all OS do that already ! (otherwise it's impossible to
restart the interrupted process, hehe :-P)
now get this straight : all interruptible threads have a space where the
registers are saved.
This is done by the kernel, just like with OTHER CPUs, with the detail
that the CMB's
format is fixed (a bit like on x86). Now, there is a little difference :
there is no "stack", hence no worry about smashing or stack overflow.
If a "normal user thread" is interrupted by whatever (whether an IRQ
or a normal thread switch), the state of the previous thread is stored
in its OWN CMB, not on a stack.
if your thread can't be interrupted, then no need to pre-allocate a CMB.
but i write this more for the other interested readers, if any.
i know that you will forget it soon and get back to this matter in a
year or two.
-SRB could be slow : SBR add muxes on the read port of the register bank
which are on the critical data path
i like the "could".
the "old school" SRB does NOT touch the datapath.
the point is that it reuses as much existing mechanisms as possible,
so it goes through the Xbar to reach the LSU. There, no chance
of memory inconsistency arises.
- In it handler, you try to put as less code as possible, so 16 registersnow, go tell the compiler that it can only use 16 registers in "some
could be enought and is smaller than aving the comlete 64 registers bank.
and not others". Compiler writers will love you.
F-CPU is meant to be as general and scalable as possible, meaning that
the programming model is orthogonal and has reduced constraints.
more importantly, the user should not be limited by arbitrary decisions,
like "only 16 registers in IRQ handlers". determining the total number of
register was already painful, so don't add a limit that will make design
difficult in the future (everybody would remember your name as
"the guy who forced later implementors to create ugly cludges
in order to override a silly early limitation").
Now, if you want to manage the mess created by 16 additional "side
or whatever, then it's up to you to write the code. You only risk to
become a hero
if it ever works.
To unsubscribe, send an e-mail to email@example.com with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/