well i have try unsuccesfuly to do this.... heres some code:
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
does this make any sence at all??? i keep getting an illegal operation when running it... any help would be apreciated.
thanx.
-bradDid 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."
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
bitRAKEfunny 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:
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 AMThis 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
; ########################################################################
Regards,
hutch@pbq.com.auThanx 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):
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
MirnoIt 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,
hutch@pbq.com.au
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: )
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 AMI 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,
hutch@pbq.com.au
...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