Computer Chess Club Archives


Search

Terms

Messages

Subject: To Nalimov and other programmers about BSF/BSR in VC

Author: Dezhi Zhao

Date: 04:27:53 01/16/99


Hi!

I used bsf and bsr extensively in my program writen with VC.
As I read your FisrtOne()/LastOne() asm functions,  they reminded me of
the difficulties in using them.  I would say your FisrtOne()/LastOne()
are perfect x86 asm programming. However it is perfect at function level.
As you know these functions are really short in code size, it would be
ideal to make them inline. I tried one year ago, but failed because
VC does not allow a function containing asm statement inlined.
The documentation says the compiler copy the asm code as it is.
Apparently there is no register renaming facility for VC compiler to
make the asm function to be inlined.
And I still leave the bsf/bsr stuff in a fuction, which really makes me
unhappy. Here is my FisrtOne() for int32:

int _fastcall FisrtOne(int map)
{
   _asm bsf eax, ecx
}

You will certainly agree with me that the function call overhead
is much bigger than the function body, an asm instruction that takes
only 1/2 clocks in P6.

I also tried the following to embed it into a big user:

int big_bsf_caller()
{
   // ..... many stuff before we need bsf/ bsr

   int bitstring;

   //... map is set after some calculations

   int first_one;
   _asm bsf first_one , bitstring


   // ..... many stuff after we used bsf/ bsr
}

It works but is even worse than the function approach. After reading the
VC-generated asm code, I found that bitstring  is treated as a mem operand
in the bsf operation even though bitstring was in fact in a register before
the operation.  The complier moves the value of the register representing
bitstring back into stack and generates bsf reg, [esp + 8] alike instruction!
And I found the embedded instruction does harm the caller in terms of
optimizations (bad register uasage), as the documation suggests.
This experiment was done 1 year ago with VC5. This is probably still true
for VC6.

Sure, one could write big_bsf_caller() all in inline asm, but that only
hardens the design too early.

Life would be easier if your Microsoft would invent new c operators for
bsf/bsr as language extensions. This is quite easy for the complier writers
because bsf/bsr is just like other ordinary binary instructions (eg. xor).
I would like to suggest they use <% and >% as operators for bsr and bsf
instructions respectively.

After the lengthy problem description,  my question is:
Do you have any practical work-around solutions?

Thanks and
Best Regards

Dezhi Zhao



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.