Re: sub-optimal code for packed boolean arrays -- bug or inherent limitation

["Randy Brukardt" <randy@rrsoftware.com>]

"Alinabi" <alexander.the.average@gmail.com> wrote in message
news:1183486662.806585.71680@q69g2000hsb.googlegroups.com...
> One more thing: some inline assembly is unavoidable. There are two
> other bitboard operations that are required: First_One(Bitboard_T)
> returns Natural and Last_One(Bitboard_T) returns Natural; They return
> the position of the least significant and most significant set bit
> respectively. On x86 processors you can do this with one instruction
> BSF (bit scan forward) and BSR (bit scan reverse), and you cannot
> expect a compiler to generate them.

There's a reason for that: Intel recommended to compiler writers to not use
"complex" instructions, as sets of simple instructions are often supposed to
be faster. The "complex" instructions were implemented essentially as
"macros" of simple instructions. (This is information is somewhat old, so it
may vary on the most recent processors.)

My point is that it might not actually be faster to use those instructions
than to use a loop of your own design (and there is a small chance that
they'd be slower). As suggested elsewhere, you need to test that in a
suitable benchmark. The number of instructions has had no real bearing on
the execution time since the 486 came out (and indeed, given that some
instructions are much slower than others, it never had much bearing on
Intel's x86 processors).

                                    Randy.