[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] F-CPU vs ALPHA



hi !

(with this flood of emails, i wasn't able to compile anything today,
not even MR's preprocessors... so don't worry if i stay mute awhile :-D)

nicO wrote:
> Yann Guidon a écrit :
> > nicO wrote:
> > > >Use semaphores that are mapped in the SRs !
> > > In all case, we need to write something in memory or to touch something
> > > in the VM unit.
> > why ? a semaphore is a semaphore, a flag if you want.
> > whether it is implemented in memory or with a dedicated HW in
> > a different addressign space, is "implementation dependent".
> 
> In all case, you have one memory access + 1 or more port to the outside.
maybe not. I am thinking about a separate and dedicated port in the chip,
that will communicate to a central FPGA or ASIC that will perform the
arbitration. a dozen of signal pins do the trick.

> Plus, you could add many problem for multicpu system. So there isn't any
> port dedicated to it, and shouldn't have ! Because it so tight to the
> OS, that we could have many compatibility problem in the futur.
if the SR interface is respected, it is transparent to the OS.

> I think
> you thought to an implementation of SGI not really usual processor.
SGI Indigo and other similar machines have a central semaphore management
that does not pollute the memory system.

> Today's µp implement semaphore with atomic read_modify_write
> instructions.
so what ?

> > > So it's just pushing the problem away !
> > and if possible where it doesn't disturb us :-P
> >
> > the L/S unit is optimised to allow high bandwidth through
> > cache-line width packet transfers, accessing single bytes
> > in scattered order is a good way to "kill" your memory subsystem
> > and the speed of your synchronisation.
> 
> You could add specific memory barrer (semaphore aren't so common!).
there is already a "barrier" ("serialize").
the problem is that not only it stalls the pipeline, but it
also perturbates the memory system's behaviour. It is used only
in "critical" sections that deal with DMA or I/O for example
("low speed" things). OTOH you would want your semaphore to be
effective in as few cycles as possible. when doing fine grained
multitasking and multiprocessing, the semaphore latency can become
the killer, especially in real-time.

> > > More generaly, i find the text very agressive against Alpha.(the 2 first
> > > sentences of the text, for example). We should never forget that alpha
> > > work since 10 years and fcpu is in it's very beginning. So this kink of
> > > speech could make laught a futur investor in the fcpu, never forget
> > > that.
> >
> > i think that you know that i am not "agressive" and that i respect the
> > ALPHA. I have two expensive books about it and unfortunately no
> > Alpha server at home.
> >
> > We can still discuss whether Alpha is dead or not. CPQ will keep
> > Alpha alive artificially as long as IA64 is not a serious competitor.
> > that is enough for me : it's just marketing and financial manipulation,
> > the ALPHA engineers have a very reduced freedom of decision now,
> > because they know that it will be dropped after the 364.
> >
> > So i could say : Alpha is dead as much as F-CPU is alive.
> > it's time to learn alpha's lessons, i think.
> >
> 
> the problem is the tone not the content.

what would you write instead ?

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