Re: [f-cpu] PS

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

hello,

Ben Franchuk wrote: 
> "Yann Guidon [systeme]" wrote:
> > Looks like we'll need a separate, low-latency and
> > simple protocol for both interrupts and semaphores.
> > Something located in an independent address space
> > (if any), with no caching quirks and which communicates
> > almost directly (but point-to-point) with other cores.
> > That's not difficult to do but i have to make sure
> > this doesn't already exist. The VCI stuff is more
> > important now because the memory interface must
> > be designed, the IRQ and semaphore machinery is
> > to be designed a bit later.
> But would not the memory interface
> still need to be partially defined
> as semaphores are atomic functions?
I am not sure to fully understand your question
but i presume that you mean that semaphores are
locked load/store instructions. This would break
all the underlying machine which is designed for
managing 256-bit words (both for the instructions
and normal data) with up to 16 simultaneous transactions.
If you want to use a semaphore, you force all the
system to work with blocking, atomic transactions
and the system is almost stalling.

From that point of
view, it is "better" to use a "blocking" instruction
["get" for requesting a semaphore and "put" for
releasing it, all through the Special Register system]
which will stop the execution pipeline only, and will
leave the memory system work at full speed in parallel.
Furthermore, the SR space allows us to freely define
an implementation. For example, you can define that
"get SR_SEMAPHORE, rN" will ask the semaphore which number
is SR_SEMAPHORE-SR_BASE, the yes/no flag (or a handle,
or the semaphore's value) will be returned in register N.
The instruction decoder will stall during a few cycles
(all the instructions in the execution pipeline will
complete in the background) and the result will be
returned to the program without disturbing the L/S unit.
This is "safe" because the get and put instructions
are "safe" and "atomic" (they are the only ones that
stop the decoder until completion so it is completely
risk-free and scheduler-safe). You can also decide to
simulate the semaphores in SW, so you give the SW a
SR_BASE value which points to a forbidden range : when
accessing the semaphore, the application will trap and
the kernel can safely use implementation-dependent
mechanisms (or go through memory stuff if you want).

BTW i have already used semaphores in a dual CPU system
and i can say that memory-mapped semaphores s*ck.

Furthermore, the load/store unit, the fetcher unit, the
cache memory and the rest are so much simpler when
semaphores are not taken into account :-D

good night everybody,

> Ben Franchuk - Dawn * 12/24 bit cpu *
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/