bitblit: mp_size_t or size_t?
bhurt at spnz.org
Mon Feb 2 17:58:45 CET 2004
The current code uses size_t, which makes it safe for me to do modulos and
divides instead of shifts and ands. I am considering shifting the code
over to using mp_size_t's in the prototype at least, under the assumption
that if it's provided, it should be used.
The problem is that both bitwise operations (like and) and modulo are
dicey propositions on negative numbers. -1 % 4 can be either -1 or 3,
depending upon the implementation. -1 & 3 can be either 1
(sign-magnitude), 2 (one's complement), or 3 (two's complement) depending
upon how negative numbers are expressed.
Which means, if I move to mp_size_t, I'm going to have to introduce two
new branchs to catch negative offsets (negative length I can catch by
changing existing branches- you'll fall into len == 0 case). This will
slow the short blits down by about 10% (long blits won't care).
The argument in favor of using mp_size_t is that it puts mp_bitblit into
more conformance with the rest of the API. And the slowdown is only with
using the generic code- on processor specific code where we know the sign
format, we can correct and it has basically no performance cost.
I'm leaning towards using mp_size_t at the moment, but wanted to give
people a chance to weigh in.
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
- Gene Spafford
More information about the gmp-devel