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

[Yann Guidon <whygee@f-cpu.org>]

hi,

nico@seul.org wrote:

> 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.
if you want to allocate CMBs "on the fly", you're free to waste clock 
cycles.
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 
saving the
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 registers
> could be enought and is smaller than aving the comlete 64 registers bank.
>  
now, go tell the compiler that it can only use 16 registers in "some 
circumstances
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 
more
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 
registers",
or whatever, then it's up to you to write the code. You only risk to 
become a hero
if it ever works.

YG


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