Re: LL/SC benchmarking [was: Mipsel libc with LL/SC online anywhere?]

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

"Kevin D. Kissell" wrote:
> The prudent thing to do would be to load the MAGIC_COOKIE
> value explicitly into k1 on the way out of general exception
> service.  Fortunately, it looks to me as if at least half
> of the overhead of this operation (LUI/ORI) can be concealed
> in branch/jump delay slots that are currently going unfilled.

I was distracted in the middle of that reply and got confused.
The MAGIC_COOKIE needs only to be destroyed, which can be 
done in a single instruction.  The 100% safe approach would
be to insert a "move k1,zero" instruction before all ERETs,
including those generated by the RESTORE_ALL_AND_RET macro
expansion, but it should faster, if very slightly larger 
and somewhat more burdensome for maintenence, to plant those
instructions in branch delay slots just "upstream" from the
context restore.  I'm working on the code a bit and may
be able to propose (if not test :-) a patch along these
lines, but in looking at entry.S, I note something a bit
disturbing:

There's a lot of code in there that allows the assembler
to schedule the instructions, but which also contains
SSNOPs to force timing.  Isn't that a bit dangerous?
Unless it is specified that the assembler will refuse
to reschedule SSNOPs, I think those sequences need to
be bracketed with .noreorder directives.  That would
also allow k1 destructors to be placed explicitly in
the delay slots, rather than assuming that they will
be put there by the assembler.

	Regards,

	Kevin K.