It was thus said that the Great Hans Franke once stated:
> should I do so on my PC?
> /* Fill a block of memory with 0's. */
> void foofill (start, end)
> {
> char *start, *end; /* memory pointers */
>
> while (start < end) { /* until we reach the end... */
> *start++= 0; /* write 0, incr pointer... */
> }
> }
Um, that should be:
void foofill(char *start,char *end)
{
while (start < end)
{
*start++ = 0;
}
}
BTW: above example is exactly one thing why I hate C.
basicly every compiler will generate a stupid loop, while
in assembly a REP STOSW would do the trick at maximum
speed possible.
True, but if you stick with the ANSI C library call memset(), an ANSI C
copmiler is free to replace the actual call to an inlined version, which on
the 8086 would probably be a REP STOSW. In fact, about the only routines I
still regularly use from ANSI C are the mem*() and str*() routines (the rest
are ... eh).
Also, on modern x86 architectures, using REP STOS* may be *slower* than
using the stupid loop (GCC generated four instructions for the inner loop,
using the sequence that an assembly programmer would use if you can't use
REP STOSW) but again, a compiler (like GCC) can be programmed with such
optimization assumptions built in. I ran the following through GCC:
struct foo
{
int a;
int b;
};
void fillfoo(struct foo *p)
{
memset(p,0,sizeof(struct foo));
}
Guess what? fillfoo() ended up being 4 instructions:
movl 4(%esp), %eax
movl $0, (%eax)
movl $0, 4(%eax)
ret
When I changed struct foo to have an array inside, GCC used "rep stosl" to
do the fill (since I'm using memset() GCC "knows" what I'm trying to
do).
So don't sell the compilers short unless you check the actual generated
output (programs here were compiled using "gcc -c -O4 -S
-fomit-frame-pointer")
-spc (Okay, starting to stray here ... )