well i have try unsuccesfuly to do this.... heres some code:
does this make any sence at all??? i keep getting an illegal operation when running it... any help would be apreciated. thanx. -brad
invoke lstrlen,addr passw ;get string lenth mov lo,eax ;lo has total amount invoke Encrypt, addr passw, addr destin, lo ;call function invoke MessageBox,hWnd,addr destin,NULL,MB_OK ;tell us what the string is backwards.... . . . Encrypt proc source :DWORD, dest :DWORD, lo :DWORD LOCAL lo2:DWORD mov ecx, source ;put address into ecx @@: inc ecx ;increase the position in ecx dec lo ;nock off a place inc lo2 ;set up secondary counter for latter cmp lo,0 ; are we done yet? jne @B ;if not jump back mov edx, dest ;put address into edx @@: mov al, ;copy byte at address in ecx to al,should be at end of string... dec ecx ;decrease the position of ecx dec lo2 ;count down so we know when where done mov ,al ;move what was in ecx into edx cmp lo2,0 ;are we done yet? jne @B ;if not jump back ret Encrypt endp
Did not try your code,but you are not initializing lo2, if this is not crashing, it will definitly give unpredictable results. The Following code will reverse a string for you.
ReverseStr proc uses edi esi Source:DWORD,Dest:DWORD invoke lstrlen,Source dec eax mov ecx,eax xor edx,edx mov edi,Source mov esi,Dest .while ecx != -1 mov al,byte ptr mov byte ptr,al inc edx dec ecx .endw mov byte ptr,0 return 0 ReverseStr endp
First thing, try initialozing the value of lo2. It's there to stop the loop, not a good thing to use a random value for. ---------------------- "Iíve figured out an alternative to giving up my beer. Basically, we become a family of travelling acrobats."
I don't like it but it's certainly a solution :P bitRAKE
RevStr PROC xStr:DWORD xor ecx,ecx mov eax, xStr L1: push ecx mov cl, test ecx,ecx jne L1 mov eax, xStr L2: pop ecx mov , cl test ecx,ecx jne L2 ret RevStr ENDP
funny whenever i try and invoke either of yours i get an illegal operation.... -brad
Hahaha, I really shouldn't post any code w/o running it :P Forgot to 'inc' the pointer. It just overflows the stack :) This one works:
bitRAKE This message was edited by bitRAKE, on 3/19/2001 12:05:57 AM
RevStr PROC xStr:DWORD xor eax,eax mov ecx, xStr @@: push eax mov al, inc ecx test eax,eax jne @B mov ecx, xStr @@: pop eax mov , al inc ecx test eax,eax jne @B ret RevStr ENDP
This is the standard algo in MASM32.LIB for reversing a string, it has been optimised by Alexander Yackubtchik.
; ######################################################################## revstr proc lpszSource:DWORD,lpszDest:DWORD push edi invoke StrLen,lpszSource mov ecx, lpszSource lea edx, lea ecx, mov edi, lpszDest @@: mov al, dec ecx mov , al inc edi cmp ecx, edx jne @B mov byte ptr ,0 pop edi ret revstr endp ; ########################################################################
Thanx guys, works perfectly! -brad
Without the API call, I think the version I present above is faster and smaller :P
Would it not be faster (especially on long strings) to use something like (pseudo code):
I could actually code this but I am lazy :P Anyway The Svin is better at it than me :D Mirno
invoke strlen source push eax and eax 0x3 (Do single byte writes until eax==0) pop eax shr eax, 2 (Do DWORD read) bswap it write it
It would have to be a very long string, as I have the StrLen function integrated into my routine. You have to make up those cycles. A combined DWORD approach is possible I think, but it would be a large routine. bitRAKE This message was edited by bitRAKE, on 3/19/2001 3:10:21 PM
to bitRAKE 1. You wrote good proc, it uses classic reversing algo wich was popular in algos used for radix 10 based BIN ASCII conversions to reverse result of divisions by 10 2. Your proc can't be compared to the others posted in this thread. LOOK CLOSELY: - All other procs uses to parameters, yours - one - All other procs put the result in different destination, yours reverse bytes in the same memory range. It changing the string source while others use it as a source to formate another string. 3. Usage: When user wants to reverse the same string, or she wants just formate reversed string from another and doesn't care of saving source untached I would recommend use your algo. Runing simple test we can see that it can be almost twice faster. But in the test we comparing the moon with fried eggs. The procs are different. And I can explain why your proc is faster - it use in second part the same range of memory which is getting into memory cache in the first part of proc. To compare in equal condition we shall change your proc so that in put result in different destination: RevStr PROC SourceStr:DWORD,DestStr:DWORD xor eax,eax mov ecx, SourceStr @@: push eax mov al, inc ecx test eax,eax jne @B mov ecx, DestStr @@: pop eax mov , al inc ecx test eax,eax jne @B ret RevStr ENDP Now if we compare it with revstr from M32LIB your proc will be a little bit slower and almost twice slower than itself working with the same memory as for source and destination. As I said - answer is memory cache usage. Apart from fare testing :) I would include your proc in M32LIB as proc for appropriate cases when user needs to reverse the same string in memory,'cause in this particular case your proc wil be faster. The Svin. ret RevStr ENDP
Svin, I never did like playing fair :) For me there have been rare times when I need the string I was reversing, but I certainly shouldn't ignore the needs of others :) I put mine in a macro that tests if source&dest are the same; then uses the appropriate routine :) Did I mention how small it is and the fact that it compresses well :P Nothing quite like self-similar coding :) You do some fairly awesome coding yourself - want to work with me on some libraries? bitRAKE This message was edited by bitRAKE, on 3/21/2001 7:12:28 AM
bitRAKE, Your algo is an interesting idea, there are often instances where modifying the original string is fine if its original form is not needed. About the only problem I can see with it is if you reversed a string that was longer than the amount of stack memory you had available, it would crash but it is rare to reverse a string that long. Nominal stack size in MASM code is 1 meg although you can change it if you require. Standard library stuff must be designed to handle cases of very long strings so a source and destination is necessary but I think your algo is well suited for dedicated applications where the stack limit is never exceeded. Regards, email@example.com
To Hiro: Friend, I tried twice click those code* (I mean in two msgs) and will try again, but it doesn't work in my case! I just got messages that errors ocurred in the script page. To Hutch: Your wish is my command :) Here is another reversing string proc 1. It reverse the same string 2. It doesn't use stack at all 3. It faster than the bitRAKE proc 20-25%. revstr2 proc lpszSource:DWORD invoke StrLen,lpszSource mov ecx, lpszSource lea edx, .while (ecx < edx) dec edx mov al, mov ah, mov ,ah mov ,al inc ecx .endw ret revstr2 endp Please, note: though this revesing algo is twice faster than that presented in revstr, I couldn't use it 'cause revstr supposed to use different range addr as destination. To bitRAKE: Of course, you're wellcome to work with me on some libraries. I'm currently working on alternative proc to FileTimeToSystemTime. As to M32LIB it lacks most useful proc InString case unsencative version. 62 integer conversion routines ect. I have my way to handle it, but haven't found time yet to bring it to M32LIB format. And there is no mathlibrary. The Svin.
What about this for revstr2? (I haven't tested it, and haven't a clue as to how to bench mark it :rolleyes: )
Mirno I keep spotting stupid mistakes, I really am a stupid monkey! This message was edited by Mirno, on 3/21/2001 1:17:52 PM And again :( :mad: This message was edited by Mirno, on 3/21/2001 1:19:06 PM And again (again) :mad: This message was edited by Mirno, on 3/22/2001 10:30:03 AM
revstr2 proc lpszSource:DWORD invoke StrLen,lpszSource .IF eax == 0 ret .ELSEIF eax < 4 mov ecx, lpszSource add eax, ecx dec eax mov dl, mov dh, mov , dh mov , dl ret .ELSE push esi push edi mov edi, eax mov esi, lpszSource add edi, esi sub edi, 4 .REPEAT mov eax, mov edx, bswap eax bswap edx mov , eax mov , edx add esi, 4 sub edi, 4 .UNTIL esi >= edi pop edi pop esi ret revstr2 endp
I really think we should have an Library section on this board where messages of this type could be moved for future reference. I'm not sure what PROCs are needed by MASM, but I'd be glad to help chip away on them - bit by bit you know. I'm working on BB-Tree routines, and related stuff right now for code-completion and high-lighting use in all the IDEs that are being developed for ASM :) bitRAKE
I like BitRAKE's suggestion of a seperate area for library development as it is an important area in assembler design. A standard library makes code development a lot easier and a lot faster yet with published source, it is not a straight jacket that restricts improvements or design freedom. I have written what I have had time to write and optimised some of the modules to get their performance up but there is a limit to what any single person can do and the field is truly enormous to cover the range of things that different people write. Alexander's contribution in modules and optimising has made the MASM32 library a lot better and the more that can be developed, the better it will be for most people as no-one can know all of the code designs and type that are required. The idea of a floating point maths library appeals to me. I added a few very simple integer modules using FP instructions in the last service pack to do basic stuff when interacting with API calls where integer resolution is appropriate but having a dedicated FP library in either REAL8 or REAL10 would be very useful to many people. I have another search algo done for binary search which uses the internal algorithm from the InString algo in the library. It is a first character/BYTE search, branch compare, exit on match or continue to end type algorithm. To do case insensitive search with this algo requires case conversion which works OK but there may be a faster way of doing it. Jeremy Collake has written a set of Boyer Moore search algos which benchmark up OK but they were no faster on average than InString but far more complicated. I have this predjudice against the Boyer Moore family of search algorithms and tend to see them as C based antique junk but if someone has a feel for this style of algorithm, it may be a method of doing searches quickly. What I would like to see is programmers from many different backgrounds writing library modules in their own specialisation complete with commented source and reference material. Games, graphics, maths, system etc.... Regards, firstname.lastname@example.org
...but there is a limit to what any single person can do... I'll help if you like, I can't dedicate more than about 4 hours a week, but if you want to give me a specific task, then I'll gladly take it on. And if you need any VAX/VMS assembler writing or PDP-11... oops I'm showing my age... Umbongo
wow this thread really blew up!! Id love to see a library section... -brad