On Fri, Dec 21, 2001 at 02:16:26AM -0600, Mark Roberts wrote:
> Anyone ever look at an isset like this:
> #define ISSET (*((a)+((b)>>5))&(1<<((b)&0x1f)))
>
> Since we're dividing by a power of two: b>>5 (32)
> and to get the bit you're looking for... b&0x1f :) :)
>
> Hmmmm... how's that for efficiency?
Needless?
If your assembler is worth two bits (um, no pun intended), it will
optimize " x / 32 " into a right shift 5.
A simple bit of C:
static int foo, bar, baz;
baz = 12345;
bar = baz / 32 ;
foo = baz >> 5 ;
(the three variables are statics since that means I don't have to
include the ugly stack manipulation stuff....)
and the relavant output from gcc -S:
; initialize baz.
movl $12345,baz.5
movl baz.5,%edx
; we're smart enough to know it's sitting there in %edx, so move to %eax
; this is bar being set to baz/32:
movl %edx,%eax
sarl $5,%eax
movl %eax,bar.3
; the only real difference: we fetch it again from memory, but that's
; just because with no optimization, the compiler doesn't remember it's
; already in %edx...
; and foo is set to baz >> 5:
movl baz.5,%eax
sarl $5,%eax
movl %eax,foo.4
Either way, with no special "-O" flags, the compiler is smart enough to
know that x/32 is the same as an arithmetic right shift.
This isn't anything new. Microsoft's BASIC compiler for the Z80 knew
about this optimiazation 20 years ago.
Go for readability over obscurity: the performance gain on obscurity
is often zero, losing readability has a real cost in finding bugs,
though.
Oh, and 'man indent'
