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

[whygee@club-internet.fr]

hi !

>De: Cedric BAIL
>> When the white list is done, we will have a first idea
>> of what problems to solve, and what can be already used
>> (recompiled) immediately. It is as simple as that for me.
>In that case it can be very interesting for us to know that.
:-)

>> > Perhaps it will be a good idea if you can
>> >send me a list of new opcode/instruction for ROP2 before starting helping
>> >porting debian ;-) Or give me a pointer to your latest package.
>
>> ouch....
>> can we meet this week-end ?...
>
>Sorry, I must go back to home (a stupid electrical problem with my
>server...)

:-(((

>> >In the same idea for the new instruction ll/sc for emulating CAS/CAS2 on
>> >a single processor what are the mnemonic and the option.
> 
>> i am currently investigating the idea (found in a discussion
>> some months ago) of a LL/SC unit that would work a bit
>> like the Load/Store Unit, but without the problems.
>
>Hum, the question was : wich form ?

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.

>> >I reread all instruction that use stream in the old manual, and I discover
>> >that if you specify the stream 0, it mean that it will use the last specified
>> >stream for this register.
> 
>> ??????????????????
>> 
>> it's not what i meant. stream 0 is the "default"
>> stream and that's all, there is no notion of a
>> persistent state. Unless you have found a really
>> good idea, which i would be pleased to read.
>
>>From what I remember you can find this into this tex file :
>http://f-cpu.seul.org/cedric/F-CPU_manual-0.2.6-en/src/i7/Draft/Memory/loadi.tex

oh i see :
"
Because of the width of the immediate data, there is no room to specify the 
stream hint bits. It is therefore assumed that the processor will associate'' 
the stream number with the pointer register thanks to a hidden status flag.
"

hmm that's a real problem, indeed.... you were right.
but it is not exactly the same thing as what you explained
("stream 0 = last stream").

>> > The question is what append if it wasn't specified ?
>> >(I think that we must say that stream 0 is like the other stream so that
>> >we didn't have any special strange case).
>
>> The idea of a "persistent default stream" has never
>> come into my head. I have never found a case where this
>> would be useful, so i never thought of it.
>> Maybe your questions about streams and libraries
>> (which i think can be answered in several ways)
>> made you think about this eventuality ?
>
>No, from what I think it's a bad idea.
>
>> >In the same idea I will add the following instruction :
>> >loadz Rc, [Rm], Rd
>> >....
>> >loadnz Rc, [Rm], Rd
>> >storez Rc, [Rm], Rd
>> >....
>> >storenz Rc, [Rm], Rd
> 
>> please mark this as preliminary and optional
>> for now. The LSU design is not finished and the
>> conditions could still change, maybe.
>
>I will mark it, like all the instruction that are not yet implemented as
>subject to change.

great !

>> >And I will specify a new form for assembler :
>> >loadaddri Imm64, Rm
>> >
>> >Where Imm64 will be marked as a PC relative relocation, and it will be
>> >expanded like this :
>> >loadcons.0 Imm64 & 0xFFFF, Rm
>> >loadcons.0 (Imm64 >> 16) & 0xFFFF, Rm
>> >loadcons.0 (Imm64 >> 32) & 0xFFFF, Rm
>> >loadcons.0 (Imm64 >> 48) & 0xFFFF, Rm
>> >loadaddr Rm, Rm
>
>> This is a macro, so it must be documented in the
>> assembler's doc, not in the CPU doc... right ?
>
>False, "loadcons Imm64, Rd" is in the manual,

???.... i thought there was only "loadcons(x) imm16, rd" ?

> and I think it must stay in
>the manual for compatible assembler. Same idea for loadaddr (NicO: I dont
>like the dot prefix for an instruction because it isn't really a macro, it
>must be treated by the assembler like a unique instruction for relocation).
> 
>> >If you want to specify something it will be a good idea to say it now. I
>> >am planning to post a prerelease for next week.
> 
>> I would like to add a small part about data types,
>> formats, pointers, addressing spaces. however i don't think
>> i have enough neurons to write it.... /o\
>
>Write a simple .txt file and send it. I will do the rest.

i won't promise anything....
but remember me often. Maybe there will be a time
when i will be lucid enough to write something simple
and clear...

>A+
>  Cedric
read you soon,
YG

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