🚀 go-pugleaf

Colin B Maharaj wrote:

> 
> /*
> 
> Had some spare time and was playing around
> a bit with some code optimization. I was
> wondering if this is faster and just as
> safe as IntToStr.

Colin, why don't you also subscribe to the delphi.language.basm group?
You'll find that these things have been answered and wrapped into the
FastCode project already. That project is primarily in Delphi, but your
assembler knowledge could surely help. It can't be too hard to turn the
few C++ specific parts into Delphi, so both Delphi and BCB can use them.
-- 
Rudy Velthuis [TeamB]        http://rvelthuis.de

"Guard against the impostures of pretended patriotism."
 -- George Washington

Colin B Maharaj wrote:

> I was wondering if this is faster and just as
>safe as IntToStr.

Ummm, No.
IntToStr returns a new AnsiString.
Your function relies on the user supplying a sufficiently large char
array so you don't accidentally overflow it.

It is, however, as safe as itoa.

>My little speed test says it is twice as fast
>as itoa and 3 time as fast as IntToStr,
>however itoa does hex and this does not!

Hex is even faster. Just write an itoh()

>Question is, do I need to be pushing any
>registers on the stack to save and restore
>on exit?

EAX
ECX
EDX
Those are the only "free" registers.
All others must be preserved.

>I think by wrapping it in a C function, I will
>not have to worry about enter/exit ASM code (?)

Compile it and look at the cpu view to see if the compiler added the
stackframe code.
I think if it were pure asm, no C code inside, you would want to take
care of things, but only if your code requires it.

I wonder if dividing by 100 instead of 10, and using AAM to get the 2
digit result would be any faster

So, you write to string in reverse order, then strrev()
Another way is to push the digits onto stack, then pop/store to
string.

Bob Gonder wrote:

>I wonder if dividing by 100 instead of 10, and using AAM to get the 2
>digit result would be any faster
>
>Another way is to push the digits onto stack, then pop/store to
>string.

Hmmm.....
	push	ebx
	xor	ecx, ecx
divloop:
	xor	edx, edx
	inc	ecx
	div	100
	xchg	eax, edx
	aam
	xchg	ah, al
	shl	eax, 16
	mov	ebx, eax
	mov	eax, edx
	xor	edx, edx
	div	100
	xchg	eax, edx
	aam
	xchg	ah, al
	mov	bx, ax
	or	ebx, '0000'
	push	ebx
	test	edx, edx
	mov	eax, edx
	jnz	divloop
	
afterdivloop
	pop	eax
	stosd
	loop	afterdivloop

Problem is it has up to 3 leading zeros.
Threre are also better ways to do the "pop stosd loop"

Bob Gonder wrote:

> So, you write to string in reverse order, then strrev()

The beautiful thing about this, is that internally
strrev requires that it knows the beginning and end
of a string that it's going to reverse.

And this is exactly what you have when you do the
conversion, the start and end of the resulting 'string'.
So the strrev type code, in ASM, is the natural path.

I was trying to do another method without reversing
using logarithms, but I have not figured it out yet and
somehow I feel the log 10 will take up too much cycles.
And then you cannot log zero or a negative number so
it gets more complex (more preconditions)

> Another way is to push the digits onto stack, then pop/store to
> string.

Then you will need to find a way to keep track of how
much popping required, maybe this might less elegant
but who knows.