Re: why unsigned int?
* Keith H Duggar, on 22.05.2010 02:50:
On May 21, 3:34 pm, "Alf P. Steinbach"<al...@start.no> wrote:
* Keith H Duggar, on 21.05.2010 20:54:
On May 21, 5:24 am, James Kanze<james.ka...@gmail.com> wrote:
On 20 May, 23:10, ?????????????????????????? Tiib<oot...@hot.ee> wrote:
On 21 mai, 00:29, Marcel M????????????ller<news.5.ma...@spamgourmet.org> wrote:
Yes, but on typical PC the division with constant is quicker for
unsigned (and so %).
Are you sure. I think on a typical PC today, division is
a single clock, regardless of the type.
No. For example the following
int halfi ( int x ) { return x / 2 ; }
unsigned halfu ( unsigned x ) { return x / 2 ; }
compiled with
g++ --version
i686-apple-darwin9-g++-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)
Copyright (C) 2005 Free Software Foundation, Inc.
g++ -O3 -S
yields the following (cleaned up)
__Z5halfii:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %edx
leave
movl %edx, %eax
shrl $31, %eax
addl %edx, %eax
sarl %eax
ret
__Z5halfuj:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %eax
leave
shrl %eax
ret
Notice the int divide compiles to 3 Intel arithemtic instructions
and an extra move compared to the single instruction for unsigned.
As I recall there is SAR (Shift Arithmetic Right, signed div by 2) and SHR
(Shift Right, unsigned div by 2).
Obviously since the code I posted uses both SAR and SHR. There
really is nothing to "recall" at that point. Did you read the
entire post?
I skimmed it. AT&T syntax looks like gobbledegook to me. Sorry.
It seems you haven't turned on optimization,
I posted the command I used "g++ -O3 -S" so that's obviously
a false wild-ass guess.
or compiler stupid
Right ... let's just assume the compiler is stupid. Geesh.
or, Intel has somehow turned those two instructions into
multiple clock cycle monstrosities?
Right ... let's just assume Intel is stupid. Geesh.
I guess it is just human nature (for some) to pay so little
respect to the giants all around us. To just assume they are
big stupid lumbering oafs before even bothering to pour one
drop of thought into the problem at hand.
I don't like your piecemeal quoting of a sentence, pretending you quoted the
full sentence. But, you're upset, naturally, and then such techniques and some
verbiage may seem called for. The morons here, like me, just hazily recollect
some assembly from decades ago instead of studying your AT&T syntax example...
The code generated is the fastest way implement truncated ie
round-to-zero division on Intel. There is no stupidity involved,
just basic ignorance as usual for USENET.
It may well be the fastest. At least on my old clunky computer using a jump for
sign testing was 5 to 10% slower (I thought perhaps so little code would fit
into some internal cache, and then with the magic predictive powers of processor
perhaps fewer ops on average, but no), and incredibly to me, but perhaps not to
some doing assembly programming on modern computers daily, using bit-testing was
about 50% slower.
On the other hand, shaving off the stack frame maintainance reduced the call
time by 10 or 15% or so, e.g. now 0.188 seconds versus 0.219 seconds for my test
program. Well it might confuse the gdb debugger to not have that frame. But then
gdb is so easily confused by just about anything. :-)
<code compiler="g++">
extern "C" int aHalfI( int x );
__asm (
".intel_syntax noprefix \n"
".globl _aHalfI \n"
"_aHalfI: \n"
" mov eax, [esp+4] \n"
" mov edx, eax \n"
" shr edx, 31 \n"
" lea eax, [edx+eax] \n"
" sar eax \n"
" ret \n"
".att_syntax \n"
);
</code>
Just to be clear, that shave has nothing to do with the division itself.
Also, by the way, division is generally NOT a single operation
or clock and in fact depends on the inputs. The same is true for
division by a constant where the number of operations (combos of
shift, add, and multiplies) required will depend on the structure
of the divisor. This is basic computer engineering covered all
over academia and the web. Here is a nice tutorial for you:
http://www.cs.uiowa.edu/~jones/bcd/divide.html
KHD
Thanks. I probably don't need it. But resources are always great.
Cheers,
- Alf
--
blog at <url: http://alfps.wordpress.com>