Andrey Chernov wrote:
On Thu, Nov 01, 2007 at 03:23:56AM +1100, Bruce Evans wrote:
In fact, one of the cleanups/optimizations in rev.1.5 and 1.6 by ache
and me was to get rid of the mask. There was already a check for _c
< 0, so the mask cost even more. The top limit was 256 instead of
128, so the point about 8bit immediates didn't apply, but I don't know
of any machines where the mask is faster (didn't look hard :-). OTOH,
_c is often a char or a u_char (it is declared as mumble_rune_t, but
the functions are inline so the compiler can see the original type.
If _c is u_char and u_char is uint8_t, then (_c < 0 || c >= 256) is
always false, so the compiler should generate no code for it. The top
limit of 256 was preferred so that this optimization is possible. A
top limit of 128 doesn't work so well.
Please see the tests posted in this thread.
Please see my remarks on the tests.
Christoph
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
