I am not sure if it is mandatory or not but in all C compiler I have seen
the switch-case was compiled either to series of if..goto or optimised in
the similar manner, like jump tables or checking range and a goto if there
was more than one case in series describing an entire range of literals.

If you just do a

do {
  *to++ = *from++;
} while(...)

or as in more common form

while(...) {
  *to++ = *from++;
}

then at every character you should execute a GOTO instruction + do the
condition in the while statement. With this Duff's device what you do is to
bulk copy the characters -- in that example 8 chars a time. And as you
cannot grantee that your string has a round number length you need to do
that extra effort to copy the remainders of chars. You can save a lot of
cycles if your string is long.

Tamas


On Mon, Jun 29, 2009 at 3:37 PM, Olin Lathrop <olin_piclist@embedinc.com>wrote:

> Marcel Birthelmer wrote:
> > Here's the example from Wikipedia (slightly modified for (my)
> > readabilitiy):
> >
> >         register n=(count+7)/8;
> > switch(count%8){
> > case 0: do{ *to = *from++;
> > case 7: *to = *from++;
> > case 6: *to = *from++;
> > case 5: *to = *from++;
> > case 4: *to = *from++;
> > case 3: *to = *from++;
> > case 2: *to = *from++;
> > case 1: *to = *from++;
> > }while(--n>0);
> > }
>
> Hmm.  This seems rather dangerous to me.  It's definitely making some
> assumptions about how the particular compiler implements things.  It's also
> not clear this is really a win in machine code.  While the C source code
> looks compact and possibly efficient at first glance, it could expand into
> more than hoped.
>
> The first thing that makes me wonder is what the effect is of entering a DO
> loop in the middle.  Since in this case the decision is performed at the
> end, maybe it's OK.  Does the C definition really promise that no hidden
> initialization or whatever be written by the compiler at the beginning of
> the DO?  I expect not, but am not a C whiz.  I can see most compilers
> probably don't do anything special there, but I still suspect this is
> compiler-specific code.
>
> As for efficiency, the initial jump into the loop may not be so great.
> Compilers typically use a jump table or successive IFs to jump to the
> selected case.  The tradeoff depends on the number of cases and the
> overhead
> of indexing into a jump table in the underlying machine language.  Eight
> cases is probably enough to result in a jump table, but even that can have
> significant overhead depending on the machine.  If you were writing this in
> PIC assembler, you'd probably notice that each case is the same length and
> do a relative jump forward by a multiple of the case size.  I rather doubt
> a
> compiler writer would have bothered to check for the special instance of
> all
> cases being the same size and sequential and then computing the relative
> jump offset directly.
>
> So while Duff's device may look cute in C, I don't think it's something you
> really want to put in your code.  You're better off with a loop that does
> blocks of 8 transfers followed by a loop or SWITCH that does the remaining
> fraction.  Depending on the overhead of indexing into a jump table and what
> the remaining fraction turns out to be at run time, it's not clear whether
> a
> loop or a SWITCH would be faster for the remaining transfers.
>
> > C's default fall-through in case statements has long been its most
> > controversial single feature; Duff observed that "This code forms some
> > sort of argument in that debate, but I'm not sure whether it's for or
> > against."[1]
>
> I've met Tom Duff, and he's a smart guy.  This shows that even he isn't so
> sure this is a good thing to recommend.  I think he was working on a PDP-11
> at the time.  He probably knew enough about the instruction set and his
> particular compiler to know it would work well in his case.
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



-- 
http://www.mcuhobby.com
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist