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

[Cedric BAIL <cedric.bail@free.fr>]

> >> >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 ? I mean the VM must be able to create a page only
for ll/sc to prevent normal load/store on 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. 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.

> >> >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.
  I will look to the one that reduce gperf colision and I think that we
must specify this one.
 
A+
  Cedric
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/