We want to set one bit.
PB has a command for this:
BIT SET. Lets take a look, just on the result.
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.
LOCAL T16 AS LONG
T16= (T16 OR 1)
Looks quite simple, we assume that it becomes what it becomes:
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:
LOCAL T16 AS LONG
!OR T16,1
' We get this result:
402887 838D5CFFFFFF01 OR DWORD PTR [EBP+FFFFFF5C], BYTE 01
This is it, we cant get better here!
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.
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.