RtlFillMemoryUlong

[Dietrich Teickner]

With one inline asm-statement this function would smaler and faster.
And the comment for
  *  ulCount [I] Number of bytes to write
need change.

And one question,
How can I start ntdll_test.exe.so in wine ?

Dietrich

/*************************************************************************
  * RtlFillMemoryUlong   [NTDLL.@]
  *
  * Fill memory with a 32 bit (dword) value.
  *
  * PARAMS
  *  lpDest  [I] Bitmap pointer
  *  ulCount [I] Number of bytes to write
  *  ulValue [I] Value to fill with
  *
  * RETURNS
  *  Nothing.
  */
VOID WINAPI RtlFillMemoryUlong(ULONG* lpDest, ULONG ulCount, ULONG ulValue)
{
   TRACE("(%p,%ld,%ld)\n", lpDest, ulCount, ulValue);

#if 1
   ulCount /= sizeof(ULONG);
  __asm__ __volatile__("rep stosl"
                        :
                        :"D" (lpDest), "c" (ulCount), "a" (ulValue));
#else
   ulCount /= sizeof(ULONG);
   while(ulCount--)
     *lpDest++ = ulValue;
#endif
}

[Mike McCormack]

Dietrich Teickner wrote:
> With one inline asm-statement this function would smaler and faster.

Nobody is really going to notice the difference this brings, almost no 
real code uses Rtl* functions (programs, not Windows dlls), and you're 
making a maintence problem by adding assembly code which depends on gcc/x86.

There's much better ways to optimize Wine.  Macroscopic optimizations, 
such as strategically changing the order of a few functions could give 
us great performance benefit, and not introduce the code management 
problems that platform and compiler specific optimizations have.

Mike

[Rein Klazes]

On Sun, 13 Feb 2005 10:31:12 +0100, you wrote:
> With one inline asm-statement this function would smaler and faster.

You are underestimating what compilers can do.

Filling some Gigabytes with your patch

(gcc 3.4, optimization -O2):

real	0m32.037s
user	0m29.584s
sys	0m0.051s

Original:

real	0m31.471s
user	0m29.004s
sys	0m0.081s

And this works optimized on all supported CPU's.

Rein.