faster bcopy using duffs device (source)

[Tom Tkacik]

In article <19491 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>
>Alas, gcc is rather the exception, although this is changing (more
>vendors are discovering gcc!), and it is disappointing how many ...
>
>Just for fun, here is my bcopy-in-C for a 68010, assuming you have a
>compiler that is as smart as gcc.  (In fact, it has been tested with
>gcc, and, at least with the gcc on our Suns, compilers very nicely,
>aside from one #ifdef.  Curiously, the gcc-specific hack is necessary
>only for one of the two loops.)
>
>#ifndef __GNUC__
>			/* for some reason, gcc does not optimise this */
>			*(short *)dst = *(short *)src;
>			dst -= sizeof (short);
>			src -= sizeof (short);
>#else
>			/* so we use a gcc extension */
>			*--(short *)dst = *--(short *)src;
>#endif

Do these two program fragments really do the same thing?
Does not the non-GCC code decrement dst and src after doing the move,
while the GCC code decrements before doing the move.

Could this be why gcc does not optimize the former.
The 68010 does not have a post autoincrement addressing mode.

I think that the gcc code should be
			*(short *)dst-- = *(short *)src--;

which is still not optimizable (at least it should not generate the
code that Chris would like it to :-)).

Or is that gcc-extension doing something I do not see?
What am I missing?  Perhaps a RTFM is in order!
	
I just did that and do not see what extenstion Chris is referring to.
Chris, which is it?
~

-- 
---
Tom Tkacik		GM Research Labs,   Warren MI  48090
uunet!edsews!rphroy!megatron!tkacik
"If you can't stand the bugs, stay out of the roach-motel."  Ron Guilmette