On Wed, 26 May 1999, Simon Burge wrote:

> Chris G. Demetriou wrote:
> 
> > A standard API would be fine, good actually.
> 
> As far as I can tell, this is a DEC API, not a MIPS API.  But it is most
> useful on MIPS, so I guess the "right" thing to do is implement it as an
> architecture-specific call and not a machine specific call.  Would we
> need to add the same API for VAX/Ultrix and Alpha/OSF1 compatibility as
> well?  And would it go in libc or libcompat?

I'd vote for libc.

> > > The R4000 and later MIPS processors (actually MIPS II CPUs and later)
> > > have the LL (Load Linked) and SC (Store Conditional) instructions, but
> > > this really doesn't help everyone :-(  Are there any other archs other
> > > than MIPS that don't have a test and set available to user code?

Those _are_ the RISC TAS instructions. :-) The idea is to not make a TAS
memory instruction, but to rely on the cache coherency hardware to
impliment a TAS instruction. In an MP system, this type of TAS won't tie
down the whole cpu bus, and it can do full TAS functionality.

The ppc does it this way, and the 601 manual (or was it the Mind Share
book?) I have includes assembly code to do it. :-)

> > really, on the mips, what you probably want is a library
> > routine/function pointer which on first run checks the cpu type and
> > replaces the function pointer either with one that invokes a the LL/SC
> > instructions or invokes the syscall.
> 
> This is what I meant by "or a possibly system-call backed library
> routine".  From what I can tell, on the MIPS you can't tell which CPU
> type you have from userland so we'd need a sysctl to give us the CPU
> architecture.  It looks as though we don't have the machinery in place
> (on MIPS at least) to support arch-dependant vs. cpu-dependant sysctl's
> at the moment - I'll look into that.

Your routine looked good, assuming the return code for non-LL/SC cpu's
would not be 0. :-)

Take care,

Bill