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

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



hi !

>> >> >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 :
><snip the interesting proposition>
>
>> 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.
>
>Did we need to add a bit in the TLB entry to manage right on page
>for this unit ?
if a new addressing space is created, there is no need to
care about the TLB entries...

> I mean the VM must be able to create a page only
>for ll/sc to prevent normal load/store on it.
a different "address space" is necessary because
if a local CPU can prevent L/S, nothing prevents
another CPU from not doing it...

>> 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").
>
>Right, I don't remember if it was exactly that or if it was somewhere else
>in the manual.
at least you pointed to this page.

> When I have time I will to it.
?...

>> >> > 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).
>But the question is still open.

huh lazy me :-)

if the stream number is lost (through IRQ or a context switch)
then the "best" thing is to default to stream 0.

>> >> >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" ?
>
>Oups, not in the 0.2.6, but 0.2.4/5 I think. That's not the problem in fact.
>We must provide in all assembler this "instruction" so that relocation
>are possible without it we will have a lot of problem. But in fact like
>what nicO say, we need an other syntax so that 16 bits versions can be forced.
ok.

>  I will look to the one that reduce gperf colision and I think that we
>must specify this one.

ARAARRRRGGGGHLHLLHH...... "gperf collision"....
forget about this and think more in terms of simplicity,
rather than parsing speed.... gperf is not the only tool
on Earth...

>A+
>  Cedric

YG

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