Felix:
> Where exactly? I can't find it... ;-)

You'll find it deep within the churning (nay, roiling) bowels of the
processor, being the number of different condition code flags being
checked in the course of executing a Jxx (x86) or B + cc (ARM).  If you
were working on a FPGA or implementing bignum comparisons, then I think
you could more easily find it or its equivalent.

David:
> This seems kinda [...] architecture-specific.

The way that arithmetical operations affect condition codes shows little
variation, at least among the popular contemporary processors using
condition codes.  x86 and ARM are rather diverse architectures, yet they
agree on Z, N (aka S), C, V.  SPARC, too, I think.  VAX ditto.  All the
way back to the hoary PDP-11.

MIPS is different, not using condition codes.  The only pure-comparison
MIPS operation is <.  (Not <=, not >.)  Anything else you'd have to
synthesize with a subtraction.

Beyond cycle counting, I see op< as more primitive than op<=: one
establishes order, while the other allows for equivalence.  I would
prefer a SORT which lets me use the most primitive predicate possible.
On many platforms it won't matter; but on some, it may.

Enough from me, already.  Let's hear from some other voices.

Ben

(P.S. I lied.  One more from me.  Wouldn't using op<= instead of op<
complicate the implementation of STABLE-SORT? )