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

Re: [f-cpu] 15 MIPS FC0 emulator



Sorry to say, but I don't understand what you are speaking about.

Are you speaking about a similar "ll/sc" that wa can find in MIPS
architecture ?

we need a "load" which tags a LSU entry as being not modified and a "store"
which checks if this LSU entry has not been modified. If this LSU entry has
been changed, we abort the "store" operation, otherwise we do "store" and
tags the LSU entry as being modified so other attempts to "store" fail. At
the end a register must be set to tell us if "store" operation aborted.

Unhopefully, I feel there is a problem with 3 threads :

thread A "load"s 1 in Va then adds 4 => Va = 5
thread B "load"s 1 in Vb then adds 2 => Vb = 3
thread C "load"s 1 in Vc then adds 1 => Vc = 2
thread C "store"s Vc (2) : success
thread A "store"s Va (5) : failure
thread A "load"s 2 in Va then adds 4 => Va = 6
thread B "store"s Vb (3) : success <--- INCONSISTENCY !

So there is a problem for multi-threading :(

I think the only way to circumvent it is to do so :

cmpxchg r1,[r2],r3

1) read the value from the LSU entry pointed by r2
2) if it equals to r3, r1 is stored in the LSU entry pointed by r2
3) the read value is ouput in r3.

an atomic increment looks like it :

atomic_inc:
load [r2],r1
loopentry r4
addi $1,r1,r3
cmpxchg r3,[r2],r1
xor r1,r3,r3
if (r3 != 0) jump r4

That can vary but I think we must to be able to read and/write in LSU entry
in atomic fashion.


----- Original Message -----
From: "nico" <nicolas.boulay@ifrance.com>
To: <f-cpu@seul.org>
Sent: Tuesday, December 10, 2002 10:32 PM
Subject: Re: [f-cpu] 15 MIPS FC0 emulator


> On Mon, 9 Dec 2002 19:38:35 +0000
> cedric <cedric.bail@free.fr> wrote:
>
> > > > For cload/cstore, I think that because nobody reply on Yann mail :
> > > >  "Re: [f-cpu] Conditionnal load and store, the return" (Date :
> > > > Fri, 30 Aug 2002 01:31:03 +0200), it was accepted.
> >
> > > Wrong. I know that SW people liked it, but it makes the
> > > implementation too complex.
> >
> > Ok, I will remove it.
> >
>
> Wait, wait, wait !
>
> Why conditionnal load&store must be removed ? load/store are maybe the
> most costly operation. It is much more efficient to use cload&cstore
> than use load&store then a cmove.
>
> nicO
>
> >
> > Cedric
> >
> *************************************************************
> 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/