Re: first packages for mipsel

["Kevin D. Kissell" <kevink@mips.com>]

Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:
> On Fri, 6 Apr 2001, Kevin D. Kissell wrote:
>
> > What advantage would there be to using sysmips() as opposed
> > to doing the ll/sc emulation?  It seems to me that the decode path
> > in the kernel would be just as fast, and there would be a single
> > "ABI" for all programs - the ll/sc instructions themselves.
>
>  It was discussed a few times already.  It's ugly and is an overkill for
> UP machines -- you take at least two faults for ll/sc emulation and only a
> single syscall for TAS.

Depends on your point of view.  Syscalls will be faster than
emulation on processors without LL/SC support, certainly,
but much slower than just executing the instructions on processors
that do support LL/SC.  Intuitively, emulation would be roughly
2x worse for an R3K, but a syscall will be 10-100 times worse
for an R4K.  If we gave an equal weight to both families, that
would argue in favor of LL/SC emulation - and working for
MIPS Technologies (where all our designs for the past
10 years have supported LL/SC) I would consider equal
weighting to be very generous!  ;-)

I've seen the hybrid proposal of having libc determine the LL/SC
capability of the processor and either executing the instructions
or doing the syscall as appropriate. While that would allow
near-optimal performance on all systems, I find it troublesome,
both on the principle that the OS should conceal hardware
implementation details from the user, and on the practical basis
that glibc is the last place I would want to put more CPU-specific
cruft.  But reasonable people can disagree.

            Kevin K.