• Welcome to Jose's Read Only Forum 2023.

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

Started by Theo Gottwald, January 02, 2007, 09:33:08 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Theo Gottwald

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
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.

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:

!OR T16,1 

' 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

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.