This page is part of the web mail archives of SRFI 32 from before July 7th, 2015. The new archives for SRFI 32 contain all messages, not just those from before July 7th, 2015.
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? )