lstrcpy vs szCopy

[jj2007]

jj, glad to see you play with simd stuff  :bg

Bad news: I have given up. SSE2 is just too slow, see my postings above for the P4 and below for the Core2... :wink

Code Select Expand

Source len=512
712      clocks for szCopyXMM
1098     clocks for szCopy
641      clocks for MbCopy
745      clocks for MbCopyD

Source len=63
210      clocks for szCopyXMM
201      clocks for szCopy
107      clocks for MbCopy
106      clocks for MbCopyD

MbCopy does not need any of these strange new registers ;-)

[NightWare]

23 bytes, works on a 386

ebx isn't necessary  :wink

Code Select Expand

align 16
simplecopy proc dest:DWORD, src:DWORD
mov ecx,src
mov edx,dest
sub edx,ecx
@@: mov al,[ecx]
mov [ecx+edx],al
inc ecx
test al,al
jnz @b
ret
simplecopy endp

[jj2007]

23 bytes, works on a 386

ebx isn't necessary  :wink

Sinsi, how dare you waste 3 bytes without any need??? :dazzled:

It's cute, and competitive, too - same timings as the library szCopy. While implementing this, I stumbled over a very odd behaviour of the chr$ macro. It's on line 190 of the attached source:

Code Select Expand

  Invoke Main
.listall

  print chr$(13,10,9, " --------------",13,10)
;  MsgBox 0, str$(eax), offset txHi, MB_OK
  MsgBox 0, str$(eax), chr$("Hello"), MB_OK ; GARBAGE instead of Hello

.nolist


The title of the MsgBox contains the test string, not "Hello". Excerpt from the list file:

Code Select Expand

00000000                   1 .data
00000024                   1 *_TEXT ENDS
00000804                   1 *_DATA SEGMENT
                           1 *ASSUME CS:ERROR
00000804  48656C6C6F00     1 ??001C db "Hello",0
00000000                   1 .code
0000080A                   1 *_DATA ENDS
00000024                   1 *_TEXT SEGMENT
                           1 *ASSUME CS:FLAT
                           invoke MessageBoxA,0,reparg(ADDR ??001B),reparg(OFFSET ??001C),MB_OK
= A                       1 quot SUBSTR <ADDR ??001B>,1,1
                           1 .data
                           1 ??001D db ADDR ??001B,0       
                           1 .code
                           1 EXITM <ADDR ??001D>     
                           invoke MessageBoxA,0,ADDR ??001B,reparg(OFFSET ??001C),MB_OK
= O                       1 quot SUBSTR <OFFSET ??001C>,1,1
                           1 .data
                           1 ??001E db OFFSET ??001C,0       
                           1 .code
                           1 EXITM <ADDR ??001E>     
00000024                   invoke MessageBoxA,0,ADDR ??001B,OFFSET ??001C,MB_OK
00000024  6A00             * push MB_OK
00000026  6800000000       * push OFFSET ??001C
0000002B  6800000000       * push offset ??001B
00000030  6A00             * push 0


I tried with ml 6.14, ml 9.0 and JWasm, and they all show the same behaviour. Any clue what could cause this? I thought nothing was more straightforward than chr$()...

[attachment deleted by admin]

[sinsi]

But jokes apart: Did you change puter? Your previous timings look a lot different

Sorry jj, those timings were on my real computer (q6600), not the athlon.

Sinsi, how dare you waste 3 bytes without any need???

It was the beer goggles...

NightWare: very clever. heh, I hate you.

[MichaelW]

The title of the MsgBox contains the test string, not "Hello".

It works correctly for me using MASM32 v9 or v10, ML 6.14, 6.15, or 7.00.

[NightWare]

NightWare: very clever. heh, I hate you.

well, in fact here (if i remember well) a small correction is necessary => Jdoe : very clever  :wink

[jj2007]

The title of the MsgBox contains the test string, not "Hello".

It works correctly for me using MASM32 v9 or v10, ML 6.14, 6.15, or 7.00.

Odd. Very odd. Even the executable works?? Thanks for testing, Michael...

This is what I get at the bottom - everything after OK has no right to be there:

Source len=7
35       clocks for szCopyXMM
23       clocks for simplecopy
23       clocks for simplecopyNW
24       clocks for szCopy
21       clocks for crt_strcpy
19       clocks for MbCopy
22       clocks for MbCopyD
--- OK ---
gHhIiJjKkLlMMNnOoPpQqRrSsTtUuVvWwXxYyZz Now I Know My ABC's, Won't You Come

Sample String 01234 56789 ABCDEF AaBbCcDdEeFfGgHhIiJjKkLlMMNnOoPpQqRrSsTtUuV
xYyZz Now I Know My ABC's, Won't You Come Play


(On Windows XP SP2, Celeron M)

[sinsi]

Yep, garbage here too (ml614,615,7,8)

[jj2007]

Yep, garbage here too (ml614,615,7,8)

So it's not just me...
Thanks, I was about to throw my puter into the garbage. :green

[sinsi]

String1 length=1024
String2 length=16*32

Buffer overrun?

[MichaelW]

Even the executable works??

I didn't test the EXE, I just tested the few lines of code that you posted with the expectation that the problem was somehow the combination of macros. Now that I do test the complete code, I get garbage, but it's obviously part of the test string. If I pad the end of the data section with:

pad db 200 dup(0)

Then the problem goes away, so something is overwriting the message box title.

[jj2007]

If I pad the end of the data section with:

pad db 200 dup(0)

Then the problem goes away, so something is overwriting the message box title.

Thanxalot, Sinsi & Michael. That was a typical noob error - I somehow assumed that since the MsgBox comes last in the code, it could not have been overwritten by "previous" code. Plain wrong, of course - since the .data of the MsgBox title was set before running the code.
I keep learning... :bg

[askm]

Lives depend on correct and speedy code

everyday. I need not elaborate.

Let those lives diminshed due to code not do

so in vain. QA.

[donkey]

Lives depend on correct and speedy code

everyday. I need not elaborate.

Let those lives diminshed due to code not do

so in vain. QA.

>>> heart monitor - Beep,beep,beep... <<<

Get the patients readouts, stat

>>>Indexing files - Please wait<<<<

We need those damn readouts

>>>Indexing files - Please wait<<<<

Use task manager to shut down the damn indexing program !!!

>>>The process is being debugged, access denied<<<

>>> heart monitor - Beeeeeeeeeeeeeee... <<<

I hope my life never depends on Windows  :eek

[sinsi]

I'm sure I read in a MS EULA that it wasn't to be used in 'nuclear reactor control systems' or 'hospital intensive care systems'