Author Topic: ISTRUE - now truly optimized?  (Read 6103 times)

0 Members and 1 Guest are viewing this topic.

Offline Theo Gottwald

  • Administrator
  • Hero Member
  • *****
  • Posts: 929
  • User-Rate: +30/-4
    • it-berater
ISTRUE - now truly optimized?
« on: February 16, 2009, 07:11:42 AM »
Code: [Select]
IF ISTRUE(R01) THEN
    ! NOP
END IF 


becomes:
Code: [Select]
MOV EAX, ESI
TEST EAX, EAX
MOV EAX, DWORD FFFFFFFF
JNZ SHORT L4024F9
INC  EAX

L4024F9:

while our optimized version becomes:

Code: [Select]
IF NOT(R01=0) THEN
    ! NOP
END IF 

' Becomes

CMP ESI, BYTE 00
MOV EAX, DWORD FFFFFFFF
JZ  SHORT L402510
INC  EAX

L402510:

which may even be a Tick slower.

Means we can use ISTRUE now, even for optimized cases.

But then what do we get for:
Code: [Select]
IF (R01<>0) THEN
    ! NOP
END IF   

No wonder, nearly the same.

Code: [Select]
CMP ESI, BYTE 00
JZ  L40250F
NOP

L40250F:

Please note that this will only be TRUE when using LONG's.
Using DWORD will give a Penalty in terms of Speed-Optimization.

The  IF ISTRUE will become:

Code: [Select]
MOV DWORD PTR [EBP-6C], ESI
MOV DWORD PTR [EBP-68], DWORD 00000000
FILD QUAD PTR [EBP-6C]
FTST
FNSTSW AX
SAHF
FSTPST, ST(0)
MOV EAX, DWORD FFFFFFFF
JNZ SHORT L402509
INC  EAX

L402509:

The (R1<>0) will be not better:

Code: [Select]
FILD LONG PTR [004071E0]
MOV DWORD PTR [EBP-6C], ESI
MOV DWORD PTR [EBP-68], DWORD 00000000
FILD QUAD PTR [EBP-6C]
FCOMPP
FNSTSW AX
SAHF
JZ  L40253E
NOP

L40253E:

What we see here is that writing:

REGISTER R01 AS LONG

is much better in terms of Optimization then just writing

LOCAL R01 AS DWORD

Now lets go the other direction to the 64 Bit QUAD variables.

Using this code:

Code: [Select]
IF (R01=0) THEN
    ! NOP
END IF
'
IF NOT(R01=0) THEN
    ! NOP
END IF
   


Lets see what we get for "REGISTER R01 AS DWORD"

Code: [Select]
FILD LONG PTR [004071E0]
MOV DWORD PTR [EBP-6C], ESI
MOV DWORD PTR [EBP-68], DWORD 00000000
FILD QUAD PTR [EBP-6C]
FCOMPP
FNSTSW AX
SAHF
JNZ L40250C
NOP
L40250C:

FILD LONG PTR [004071E0]
MOV DWORD PTR [EBP-6C], ESI
MOV DWORD PTR [EBP-68], DWORD 00000000
FILD QUAD PTR [EBP-6C]
FCOMPP
FNSTSW AX
SAHF
MOV AX, WORD FFFF
JZ  SHORT L40252F
INC  AX
L40252F:

which is by no surprise not far from what we get when writing:

LOCAL R01 AS QUAD


Code: [Select]
FILD LONG PTR [004071E0]
FILD QUAD PTR [EBP+FFFFFF64]
FCOMPP
FNSTSW AX
SAHF
JNZ L402504
NOP
L402504:


FILD LONG PTR [004071E0]
FILD QUAD PTR [EBP+FFFFFF64]
FCOMPP
FNSTSW AX
SAHF
MOV AX, WORD FFFF
JZ  SHORT L402520
INC  AX

L402520:
« Last Edit: February 16, 2009, 07:15:23 AM by Theo Gottwald »

Offline Petr Schreiber

  • Full Member
  • ***
  • Posts: 183
  • User-Rate: +14/-4
Re: ISTRUE - now truly optimized?
« Reply #1 on: February 16, 2009, 02:28:46 PM »
Theo,

thanks a lot for this experiments, I appreciate it a lot.
I am just not sure why NOT (R01=0) should be one tick slower than ISTRUE(R01)?


Thanks,
Petr
AMD Sempron 3400+ | 1GB RAM @ 533MHz | GeForce 6200 / GeForce 9500GT | 32bit Windows XP SP3

psch.thinbasic.com

Offline Edwin Knoppert

  • Sr. Member
  • ****
  • Posts: 254
  • User-Rate: +11/-4
    • Hellobasic.com
Re: ISTRUE - now truly optimized?
« Reply #2 on: February 16, 2009, 08:10:50 PM »
Theo, are you interested in a logfile issue/problem the PB compiler gives on Wine (Mac)
I don't need you to install anything but i am curious what is used on creating + appending to the logfile.
Under Wine it creates the log with 0 bytes but no text is written.
Maybe you (just) can see something odd in the code?
:)

Offline Theo Gottwald

  • Administrator
  • Hero Member
  • *****
  • Posts: 929
  • User-Rate: +30/-4
    • it-berater
Re: ISTRUE - now truly optimized?
« Reply #3 on: March 01, 2009, 08:32:11 AM »
@Edwin, if you post to a dedicated User (lets take me here) it makes sense you also sent a small Message or mail because the perosjn may not find your post soon.

Now to the point. If it is a PB Compiler Problem, it should be discussed with PB Support.
About "Wine" i don't have it, I have heared that Semen uses it. Besides that I am not sure who else needs it.

If the problem does occur outside WINE, you can of course sent me the code and I could try a dissassembly.
If its only inside WINE i can't help you on this, as i do not plan to install it, and even if I would do,
i doubt I'll be more competent on this then you.

If you get a empty file, the "FILE CLOSE" may not have been executed.
Means the file was written, but the directory cache was not finally written.
Did you try a "CLOSE#" explicitly and a small time delay before ending the program?

If you talk from the log-file PB itself creates, again  I'd ask support on this.