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. This mailing list is addressing something different, IIRC. > > 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. On which platforms might it matter, then? Can you give a code- example (C will be fine) which shows any substantial difference in size or speed? cheers, felix