Is it possible to make this little code smarter or / and faster ? !:*)

[FairLight]

Code Select Expand



Getyinyang1 proc

LOCAL systime: SYSTEMTIME


invoke GetLocalTime, addr systime
movzx eax, systime.wMilliseconds

test ax,ax

jnp SHORT @not_straight

mov yyvar1,"2"

jmp SHORT @ready

@not_straight:

mov yyvar1,"3"

@ready:

ret

Getyinyang1 endp


[FairLight]

I've done some modifications before, and i don't know if there's a better solution than this ^^ !
In my opinion it's the best one, but ... maybe there's a better solution ?

[hutch--]

FairLight,

With an API call like "GetLocalTime" there is little to optimise, the call takes a specific amount of time in the OS, loads the "SYSTEMTIME" structure with values and returns and there is almosat nothing you can do to make it faster. Just process the results in the structure in whatever way you like and it will do the job.

[FairLight]

Thank you !

[lingo]

FairLight, 

Try to avoid jumps in you code: :wink

Code Select Expand


mov     yyvar1, 2
sub     esp, sizeof SYSTEMTIME
invoke  GetLocalTime, esp
xor     eax, eax
cmp     [esp][SYSTEMTIME.wMilliseconds], 1
setnp   al
add     esp, sizeof SYSTEMTIME
add     yyvar1, eax

Regards,
Lingo

[FairLight]

Wow, such an unreadable code, but if i am looking longer  :dazzled: at the lines, ... :D h3h3

I will try it.

Thank you !

CUL8'er.

[FairLight]

 :U



Next step:

Code Select Expand



Getyinyang proc
LOCAL systime: SYSTEMTIME

invoke GetLocalTime, addr systime
movzx eax, systime.wMilliseconds

mov CurrentTimer,eax       ; for WM_TIMER - delay in milliseconds

test ax,ax

jnp SHORT @not_straight

mov yyvar,"2"

jmp SHORT @ready

@not_straight:

mov yyvar,"3"

@ready:

mov eax,CurrentTimer
.if (eax > 127) && (eax <1025)      ; shorten the delay a little bit,
shr eax,3                           ; by dividing it by 8  (because the Getyinyangproc is needed 18 times)
mov CurrentTimer,eax                ; but has to be random !
.endif

ret

Getyinyang endp





If i am using Lingo's example, how can i get the CurrentTimer ?
Working with esp (stackpointer) fails...  hmm...

To set it before the call to the Proc is possible, but i want to have it in the Proc !

Want to have a look at the TimerProc ? File is attached.

You'll see that i am learning from the scratch...   :red

[attachment deleted by admin]

[FairLight]

Want to have a look at the program ?

Sample testprogram is attached.
I use this to test things.
If the code is alright, i am porting the code to my mainprogram ^^

( start the prog and click on the "CPU-Icon" to get the yijing-results from the bottom up, like in life - things grow ...  :bg  )


[attachment deleted by admin]

[Tedd]

Code Select Expand

Getyinyang1 proc
    LOCAL systime: SYSTEMTIME

    invoke GetLocalTime, ADDR systime
    movzx eax, systime.wMilliseconds
    push eax        ;(for CurrentTimer modification below)
    test eax,eax
    setnp al        ;al = 0 if parity, else 1
    add al,"2"      ;al = "2" if parity, else "3"
    and eax,0ffh    ;mask out upper bits of eax (only needed if yyvar1 is dword)
    mov yyvar1,eax

    pop eax
    .IF (eax > 127)        ;milliseconds must already be < 1000 -- so no need to test < 1025
        shr eax,3
    .ENDIF
    mov CurrentTimer,eax
    ret
Getyinyang1 endp

[FairLight]

Very elegant !  :8)

Thanks !

CUL8'er.

[lingo]

FairLight 

"Is it possible to make this little code smarter or / and faster ? !:*
"You'll see that i am learning from the scratch..."

Ok, try to learn this "from the  scratch"... :wink

- Try to avoid jumps in you code
- Try to avoid high level "Readable" constructions
  in your ASSEMBLY code as:  .IF, .ENDIF, proc, endp, etc.
  they are "hidden" sources of the additional (garbage)
  instructions and slow down your program
  If you can't, just write in pure C and use C compiler with
  optimization. Your code will be faster than your "assembly" code     
- try to understand my code: :lol

Code Select Expand



usage:  call Getyinyang1
...
...
Getyinyang1:
           sub     esp, sizeof SYSTEMTIME
           invoke  GetLocalTime, esp
           movzx   ecx, [esp].SYSTEMTIME.wMilliseconds
           xor     eax, eax
   mov      edx, ecx 
           test     ecx, ecx
           setnp   al
   shr      edx, 3 
           add      eax, 32h
   cmp      ecx, 128
           mov     yyvar1, eax
   sbb      eax, eax
           xor     ecx, edx
           add     esp, sizeof SYSTEMTIME
           and     eax, ecx
           xor     eax, edx
           mov     CurrentTimer, eax    
   ret   


Unreadable? Yes, for beginners
Smarter and Faster? Yes, for all

This book will help you "to became READBLE":  :wink
"How to optimize for the Pentium family of microprocessors" by Agner Fog

Regards,
Lingo

[Tedd]

Lingo, speed is not the 'all' for everyone :P
And beginners should walk before they try to run :wink

[lingo]

"..speed is not the 'all' for everyone"
first: the name of the topic is about speed

and second:
It is a shame for an "assembly" programmer to avoid the
speed possibilities of the new CPUs, just because he is lazy
to learn and try new staff...

"And beginners should walk before they try to run"
Ok, but why start walking with old high language shits...
From such walking a lot of people (including some administrators)
remain beginners forever :lol

Regards,
Lingo

[hutch--]

I wonder what the problem is, while I will comfortably wear gutting algorithms down to their bare bones with no stack frame and properly optimised code, once you slop an API call into assembler code, it becomes as slow as the API call. Where you can get speed, you get something for it but the alternative with an API call is something like "WOW I have the fastest MessageBoxA call on the planet" which is a "who cares" situation.

[lingo]

"wonder what the problem is,.."
the problem is: some people are lazy to learn new stuff
and need excuse for that
Other people (including you) give them arguments as:
"API is slow, hence we can use every shits to call them"
or with other words:
"You can dream for Bugatti Veyron 16.4
but you can't drive in the city with more than 50 km/h"


The result is:
- What is this: MMX,SSE2,SSE3,SSSE3,SSE4  etc and why to learn about them?
  (API is slow)
- Who is A.Fog and why to learn his book?  (API is slow)
- Why my program runs faster in C and slower in assembly?  (API is slow)
- "Wow, such an unreadable code"  (API is slow)
I can continue... :lol