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. -- http://ache.pp.ru/ _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
