(Optimization) Something about "Bit Set" and the good old "OR"

[Theo Gottwald]

We want to set one bit.

PB has a command for this:
BIT SET. Lets take a look, just on the result.

Code Select Expand


40287B B801000000             MOV EAX, DWORD 00000001
402880 8D9D5CFFFFFF           LEA EBX, DWORD PTR [EBP+FFFFFF5C]
402886 E8D82B0000             CALL L405463

405463 E813000000             CALL L40547B
405468 0803                       OR  BYTE PTR [EBX], AL
40546A C3                         RET NEAR


Doesn't look promissing. We just want to set ONE BIT. We don't want to make Subroutine calls.

Ok, lets try teh traditional BASIC-way.

Code Select Expand

LOCAL T16 AS LONG
T16= (T16 OR 1) 

Looks quite simple, we assume that it becomes what it becomes:

Code Select Expand


40287B B801000000             MOV EAX, DWORD 00000001
402880 09855CFFFFFF           OR  DWORD PTR [EBP+FFFFFF5C], EAX


Looks good!

Thinking a bit about the bit, we can simply use PB-Inline ASM:

Code Select Expand


LOCAL T16 AS LONG
!OR T16,1 

Code Select Expand

' We get this result:
402887 838D5CFFFFFF01         OR  DWORD PTR [EBP+FFFFFF5C], BYTE 01

This is it, we cant get better here!

[Donald Darden]

Agreed, for bits within a given word.  However, you can use BIT statements to
span any array as well, so treating it as a pointer offset works best for that
purpose.

Often, the tradeoff to gain power and flexibility is at the expense of doing something simple in the simplest way.

[Theo Gottwald]

Agreed, also while looking in the Disassembly, my idea was that the more universal the instruction, the worse the optimization.
Anyway, there may be chances, where future compilers can be improved in optimization on such things.

On the other side thats a architectural question. If you do the Optimization as a "third pass", you may have lost important datatype Informations from the source code. Thats why it these sort of optimizations depends on how open the compiler architecture is.