flat assembler
Message board for the users of flat assembler.
Index
> Windows > lstrcat replacement Goto page 1, 2 Next |
Author |
|
LocoDelAssembly 05 Dec 2012, 20:42
To not steal from you the opportunity to do it the efficient way, I'll implement it in the laziest way possible, taking advantage of your lstrlen replacement:
Code: proc lstrcat uses esi edi, lpString1, lpString2 mov edi, [lpString1] stdcall lstrlen, edi add edi, eax mov esi, [lpString2] stdcall lstrlen, esi lea ecx, [eax + 1] rep movsb ret endp |
|||
05 Dec 2012, 20:42 |
|
LocoDelAssembly 05 Dec 2012, 20:57
BTW, if you need full compatibility, you need to add "mov eax, [lpString1]" just before ret.
|
|||
05 Dec 2012, 20:57 |
|
jochenvnltn 05 Dec 2012, 20:59
LocoDelAssembly wrote: To not steal from you the opportunity to do it the efficient way, I'll implement it in the laziest way possible, taking advantage of your lstrlen replacement: Interesting.. thank you ill study this |
|||
05 Dec 2012, 20:59 |
|
mindcooler 05 Dec 2012, 22:40
jochenvnltn wrote: Im trying to write a program in fasm and keep it as small as i can. jochenvnltn wrote: Does anyone know a lstrcat replacement. Because i dont want to imort the API unless there is no other way. These statements are contradictory. Why not use StringCchCat? _________________ This is a block of text that can be added to posts you make. |
|||
05 Dec 2012, 22:40 |
|
AsmGuru62 05 Dec 2012, 22:42
Too many stdcall's!
Code: ; ; INPUT: ; EDI = destination buffer ; ESI = source buffer ; OUTPUT: ; EAX = points to a null terminator in destination buffer ; ( ^^^ in case of more concatenations to follow) ; StrCat: push ecx esi edi xor eax, eax or ecx, -1 repne scasb dec edi .more: lodsb stosb test eax, eax jnz .more lea eax, [edi - 1] pop edi esi ecx ret |
|||
05 Dec 2012, 22:42 |
|
jochenvnltn 06 Dec 2012, 15:52
Dont know what to say.. Works perfect! This i will be using all the time!
You realy are a AsmGuru Code: format pe gui 4.0 include 'win32ax.inc' str1 db 'hello ',0 str2 db 'world!',0 dest dd ? start: mov esi,str2 mov edi,str1 call StrCat invoke MessageBox,0,str1,'caption',MB_OK invoke ExitProcess,0 ; StrCat Replacement ; fuck shit with Too many stdcall's! By AsmGuru62 (.flatassembler.net) ; INPUT: ; EDI = destination buffer ; ESI = source buffer ; OUTPUT: ; EAX = points to a null terminator in destination buffer ; ( ^^^ in case of more concatenations to follow) ; StrCat: push ecx esi edi xor eax, eax or ecx, -1 repne scasb dec edi .more: lodsb stosb test eax, eax jnz .more lea eax, [edi - 1] pop edi esi ecx ret .end start |
|||
06 Dec 2012, 15:52 |
|
f0dder 06 Dec 2012, 16:12
jochenvnltn wrote: Dont know what to say.. Works perfect! This i will be using all the time! 1) adding more bytes to your executable and 2) (most likely) using a slower piece of code than the API version _________________ - carpe noctem |
|||
06 Dec 2012, 16:12 |
|
marcinzabrze12 06 Dec 2012, 17:06
Check this and change to without 'proc / endproc' if you want.
|
|||||||||||
06 Dec 2012, 17:06 |
|
jochenvnltn 06 Dec 2012, 17:51
marcinzabrze12 wrote: Check this and change to without 'proc / endproc' if you want. wow! thank you for this share! it looks very nice.. |
|||
06 Dec 2012, 17:51 |
|
jochenvnltn 06 Dec 2012, 17:58
I just love this code snips! 1000x thank you!
|
|||
06 Dec 2012, 17:58 |
|
marcinzabrze12 06 Dec 2012, 18:52
Please report me if find some bug.
|
|||
06 Dec 2012, 18:52 |
|
jochenvnltn 06 Dec 2012, 22:16
marcinzabrze12 wrote: Please report me if find some bug. hello marcinzabrze12.. No! No bug's whatsoever.. Is you gmail in the source still valid? Ill use that to contact you then.. Agian.. thank you.. |
|||
06 Dec 2012, 22:16 |
|
jochenvnltn 07 Dec 2012, 01:08
f0dder wrote:
Is (most likely) = Definitely? Because i needed this call multiple times in my code, so your gona say it's slower then the original API import? Im not an expert so please prove your point because im still learning .. and yes.. i have nothing better to do for now |
|||
07 Dec 2012, 01:08 |
|
marcinzabrze12 07 Dec 2012, 17:25
@f0dder:
Look at implementation of lstrcatA function (kernel32.dll) in AIDA. lstrcatA is slower than ansiCat (from STRING.INC). ; ----------------------------------------------------------------- If yor code will work on Intel Core i5 or higher than you have specjal assembly instructions "PCMP(x)STR(y)" to do everything with a string data. |
|||
07 Dec 2012, 17:25 |
|
revolution 08 Dec 2012, 04:59
f0dder wrote: 2) (most likely) using a slower piece of code than the API version |
|||
08 Dec 2012, 04:59 |
|
yoshimitsu 08 Dec 2012, 19:14
The WinAPI version is implemented in the easiest way you can think of (loop and check for zero), it's actually pretty slow, but small (keeping kernel32.dll small).
Implementing your own function to save space is not really smart. You're very likely already importing kernel32.dll's functions and adding lstrcat to them takes only a few bytes. If you want speed and a small executable, you should import from msvcrt.dll instead. These functions are optimized for speed and process multiple data at a time. |
|||
08 Dec 2012, 19:14 |
|
marcinzabrze12 09 Dec 2012, 00:37
Quote: Implementing your own function to save space is not really smart I don't need to save space. I need to improve speed. Quote: (loop and check for zero) one JMP on every checked byte - what if you processing 500 KB text file ? For this reason are instructions like movs* scas* ... I looked now in AIDA disasembled code of msvcrt.dll "strlen", "strcmp" ... is not fast and is not that small. |
|||
09 Dec 2012, 00:37 |
|
AsmGuru62 09 Dec 2012, 13:00
If your code has a lot of string concatenations you may want to think of developing
your own string library where you always know the string length, like Pascal does. This way your concatenation code will omit the code searching for null terminator and it will perform even faster. |
|||
09 Dec 2012, 13:00 |
|
f0dder 09 Dec 2012, 13:31
revolution wrote:
marcinzabrze12 wrote: I don't need to save space. I need to improve speed. marcinzabrze12 wrote: I looked now in AIDA disasembled code of msvcrt.dll "strlen", "strcmp" ... is not fast and is not that small. marcinzabrze12 wrote: For this reason are instructions like movs* scas* ... AsmGuru62 wrote: If your code has a lot of string concatenations you may want to think of developing your own string library where you always know the string length, like Pascal does. This way your concatenation code will omit the code searching for null terminator and it will perform even faster. And if you must deal with zero-terminated strings, I'd suggest at least moving to some safer routines than the libc ones... unless you absolutely, entirely and positively know what the input string lengths will be |
|||
09 Dec 2012, 13:31 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.