UpdateString: destructive insert
- netmaestro
- PureBasic Bullfrog
- Posts: 8433
- Joined: Wed Jul 06, 2005 5:42 am
- Location: Fort Nelson, BC, Canada
Re: UpdateString: destructive insert
It says that if you use ebx the c++ compiler will have to preserve it for you, which implies it needs preserved. It can be assumed then that it will need preserved everywhere. The reference I quoted is simply giving the wrong impression.
BERESHEIT
Re: UpdateString: destructive insert
Yes it's for C++ but Windows uses that ABI, so any software on Windows needs to stick to that ABI. Otherwise there would be major incompatiblity with DLL's and stuff.Demivec wrote:That's a helpful reference but it deals with C++ inline assembly. How does that relate to PureBasic's inline assembly?netmaestro wrote:Thorium pointed me to an x64 registers page. Have a look here:
http://msdn.microsoft.com/en-us/library/k1a8ss06.aspx
- netmaestro
- PureBasic Bullfrog
- Posts: 8433
- Joined: Wed Jul 06, 2005 5:42 am
- Location: Fort Nelson, BC, Canada
Re: UpdateString: destructive insert
@wilbert: Yes I failed to consider the case where the operands fall through each other, my mistake. Your solution seems elegant enough and is also very economical in clocks. With Procedure changed to ProcedureDLL it tailbites up with no problem (just ascii for now), passes fairly exhaustive testing and is now in my production library. Thanks for your help.
BERESHEIT
Re: UpdateString: destructive insert
I'm on 64-bit so I can't test the 32-bit assembly, but it would be interesting if someone could compare the speed of the assembly to this version:
Also I can confirm that EBX needs to be preserved.
Code: Select all
Macro UpdateString2(target, source, pos)
CopyMemory(source, target+pos-1, MemoryStringLength(source))
EndMacro
- netmaestro
- PureBasic Bullfrog
- Posts: 8433
- Joined: Wed Jul 06, 2005 5:42 am
- Location: Fort Nelson, BC, Canada
Re: UpdateString: destructive insert
Not quite apples to apples as there are two differences:it would be interesting if someone could compare the speed of the assembly to this version:
-assembly version returns the number of successfully replaced chars (impossible with a macro)
-assembly version contains a safety check for length and will never write past the end of the target string
Anyway, with those differences in mind, here is the result of this test (debugger off, of course):
Code: Select all
s=ElapsedMilliseconds()
For i=1 To 100000000
updatestring2(@"hello world!", @"girls", 6)
Next
t=ElapsedMilliseconds()
MessageRequester("", Str(t-s))
Assembly version: 904 ms (wilbert's last version, not my original)
BERESHEIT