ASM Community

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

:):):):):):)

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

I don't like it but it's certainly a solution :P bitRAKE

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:

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

bitRAKE This message was edited by bitRAKE, on 3/19/2001 12:05:57 AM

Thanx guys, works perfectly! -brad

Would it not be faster (especially on long strings) to use something like (pseudo code):

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

I could actually code this but I am lazy :P Anyway The Svin is better at it than me :D Mirno

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

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, hutch@pbq.com.au

What about this for revstr2? (I haven't tested it, and haven't a clue as to how to bench mark it :rolleyes: )

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

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

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, hutch@pbq.com.au

wow this thread really blew up!! Id love to see a library section... -brad