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

Re: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project and Debian)



the original term of "ll" is "load-linked" and not "load locked". Indeed
"lock" term is misused. We don't lock anything, we just set a bit to tell us
later if an memory content is dirty or not. Executing the first "sc" on a
"ll"-ed memory set this dirty bit to one to prevent following "sc" from
success : no lock, just a status flag. Kinda of "safe-load" and "safe-store"
indeed.

ll r1,r2,r3 :
    what the purpose of storing a status in r3 ? which status ? is there any
reasons to have it ? several "ll"s without "sc" don't harm at all, so what's
its purpose ? just a addinational way to know if several "people" try to
access the same memory, so we can have a different behavior if a previous
"ll" on the same address has been set ? like a conditional load as spoken in
one pdf about non-blocking syncs ?

sc r1,r2,r3 :
    "checking the value of r2" ? what does that mean ? what you only need is
to check the nodirty flag is still set when "sc" is executed so that r2 may
be stored at address r1. r3 should just tell us whether the nodirty flag was
set or not, that is, if r2 is stored.

    But your example looks correct, so I think it is just the way you
explain which is disturbing, not the example :).

What does that mean a separate address ? just a separate way to access data
in SDRAM or just a special memory. Using a special memory is not appropriate
for a large database of several GB : you would need a dynamic allocation of
slots, to store them somewhere so you can read them in r1 before executing
"ll r1,..." or "sc r1,...", etc. Not really a cool thing to handle, and
memory accesses in SDRAM are not avoided since we still need to keep the
slot number somewhere so objects can lock or unlock their access with their
allocated slot number. By the way, you don't prevent the user code to read
the content of slots allocated for kernel !!! it is a hole in the security.
If you plan to forbid user code to allocate slots, well you are completely
wrong,because you force user code to call kernel code... in any case, I
don't see where it is the quickest way to execute "ll/sc" since you need
other slowing workarounds to do to use them.

If you are just speaking about a separate way to access data in SDRAM. Well,
no virtualisation of memory, no right access. We still have a problem of
security : user code or kernel code could read or change anything they want
in SDRAM that way.

As you can see, a separate address still leads to several problems that I'm
not sure you did well consider as you should.


----- Original Message -----
From: <whygee@club-internet.fr>
To: <f-cpu@seul.org>
Sent: Wednesday, October 09, 2002 5:49 PM
Subject: ll/sc (was Re: Re: Re: [f-cpu] F-CPU project and Debian)


My proposition is :
make a "load locked" and "store conditional" couple
of instruction that is not related to the usual memory
system (no streams, no size, no alignment etc).
A bit like "get" and "put" but in a different addressing
space (a 3rd one, after the memory space and the SR
space).

"Load Locked" and "Store conditional" take
an "address" (a handle that can be controlled
by the kernel), an operand (a read (store) or
write (load) register) and a result
( 0 => ok, 1 => retry (data was modified since
last checkout), 2 => wrong address...)

    adr val flag
 ll r1, r2, r3  => checkout at address R1 then put
           the result in R2 and the status in r3
 sc r1, r2, r3  => checkin the value of R2 at address R1
          and put the status in R3

So a "dumb" 'locked add' would look like

loopentry r1
ll r3, r4, r2
addi.64 r5, r4, r4
sc r3, r4, r2
loop r1, r2

(this adds r5 to the mutexed value which address is in r3)
The advantage is that any number of values can be
checked in and out at a time.

By using a separate Execution Unit and a separate
addressing space, all the collision worries
and the race conditions are forgotten.
However some protection measures are needed
and the kernel must allocate a certain accessible
range to the tasks.

It is obvious, however, that the LSU tags can't
be reused because the "address" (or "item number")
is not a pointer to memory. To keep the format simple,
i have put the "address" in the first position (read only),
the status result at the last position (write only)
and the data in the middle (this field can also be
written to, for example in the post-incremented loads)
The principle of the unit that performs this operation
will be a bit similar to the LSU but smaller and simpler.
we could even start making it before the LSU.


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