Re: [f-cpu] PS

["Rob Finch" <robfinch@sympatico.ca>]

Hi,

I've been following the F-CPU project for a few months now, I think it's an
interesting idea.

Anyway, regarding semaphores. Semaphores don't have to be implemented using
atomic read-modify-write memory operations or blocking instructions. I
believe there are software algorithms for handling semaphores for example,
Dekker's algorithm. You can also implement semaphores using an address
reservation system in hardware. An address reservation system is used in the
PowerPC for example, and is my current favorite method.

Rob    http://www.birdcomputer.ca/

----- Original Message -----
From: "Yann Guidon" <whygee@f-cpu.org>
To: <f-cpu@seul.org>
Sent: Thursday, January 17, 2002 7:57 PM
Subject: Re: [f-cpu] PS


> 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/

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