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
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 ?
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.
Thank you !
FairLight,
Try to avoid jumps in you code: :wink
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
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.
:U
Next step:
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]
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]
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
Very elegant ! :8)
Thanks !
CUL8'er.
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
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
Lingo, speed is not the 'all' for everyone :P
And beginners should walk before they try to run :wink
"..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
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.
"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
Yep, I can continue too. :bg
No matter what you do with a system API call, its no faster if its called in assembler, C or even VB, optimising an API call is a non event as its within the system and beyond your control. There is a trick on some API calls to copy them to local memory and you see a speed improvement but thats hardly what is being discussed. Then there is the processor compatibility issue, SSE3 runs really lousy on hardware that does not support it and a vast amount of data processing has no advantage trying to use MMX or SSE.
Agner Fog's various optimisation manuals do not deal with optimising a system API call as it is a non-event. If you program in assembler runs slower than the same functionality in C, stop wasting time trying to optimise an API call and start timing assembler code where it matters. If you write unreadable code, get used to the idea that few others either can or will be bothered to decypher it.
I have sold the argument for a long time of putting your effort where it matters, not where it is wasted. Having the fastest MessageBoxA on the planet is a "so what" affair but putting your effort into a decent data munching algorithm or image processing algo and you will see a reasonable result from bothering.
Now to invert your automotive example, why bother putting twin superchargers and an afterburner on something you are going to drive around the city at 50 KPH ? Spend your effort on a 3000 HP+ dragster and you will see something go fast. :bg
My questions were not to be intended for ... "Wow, i've got the fastest API-call, as fast as API calls !"
Only wanted to look @ other people's code how they will write a solution for small steps of data ...
I have got thousands of learning books, pdfs, tutorials, links, forums, example code,... (except AFog, Iczel, etc.) ,
but was too lazy to read them all !
:'( And there's so much information about learning assembler in my own language, it's very amazing ! C'est la vie !
.. Sorry about that !
And sorry that i was born. Sorry, that i have every time in the world ! Sorry to start this topic ...
sorry about my very bad english ... sorry about that i am not as excellent as lingo is ...
sorry about that i want to learn from other people:
"Time and money makes the world go round !"
mov Recyclebin, Topic
xor Recyclebin,Recyclebin
SYS 64738
btw.:
"A protected forum where programmers learning assembler can ask questions in a sensible and safe atmosphere without being harassed or insulted. This is also targetted at experienced programmers from other languages learning assembler that don't want to be treated like kids."
O and O and Cul8'er.
:(
FairLight,
have no concern about the debate, it does not effect you and it was not pointed at you. Just write your code to get it reliable, faster if you can and it will do the job. When you start writing algos in assembler, thats where the fast stuff will be and where the real fun starts. :bg
:U :bg
Ich bin mit dem Hutch einverstanden, keinem beleidige hier.
Es war mein freundlicher Rat und reiner assembler code :wink
QuoteSYS 64738
Haha :green C64 (fat model) was my first comp!
"I have sold the argument for a long time of putting your effort where it matters,
not where it is wasted.
We do programming under different OS and we ALWAYS will call
OS system functions (APIs are slow) using different
languages. So, again (according to Hutch):
"APIs are slow, hence we can use every shit to call them"
and no optimization, no new technology, no A.Fog and write all
in I486 way... :lol
:bg
I will make you a deal, you can write the fastest MessageBoxA call on the planet and we will all applaud you for doing so. "Hay man, I have the fastest MessageBoxA on the planet, big deal huh ?"
Do you permit me to change the name of
API from MessageBoxA to strlenA? :lol
Analysing my mum's computer habits, replacing all calls to MessageBoxA with an assumed return value of "MB_DONTCARE" or "MB_GOAWAYMESSAGEBOX" would radically improve program flow :lol
:bg
> Do you permit me to change the name of
> API from MessageBoxA to strlenA?
I would not want you to miss out on such a claim to fame as creating the fastest MessageBoxA on the planet. Think of this, if you did the jumps correctly you could shave off two processor cycles after reading the message in the MessageBoxA and clicking the OK button.
:bg
Here is a slightly slowed down MessageBoxA application.
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
.data
msg$ db "! huH wolS",0
ttl$ db "sgniteerG",0
pmsg dd msg$
pttl dd ttl$
.code
start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
call main
exit
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
main proc
push MB_OK
mov pttl, rev$(pttl)
push pttl
mov pmsg, rev$(pmsg)
push pmsg
mov ecx, 1000
@@:
sub ecx, 1
jnz @B
push 0
call MessageBoxA
ret
main endp
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start
This is why I don't bother to try and optimise API code, its so slow it just does not matter.
Hutch, where is the info for making macro's like rev$? :toothy
Thanks in advance!
Tom,
In the MACROS.ASM file in the MACROS directory.