I saw this mentioned in a recent SlashDot story and was curious if anyone
knows what VisualDSP does when it encounters this. Duff's Device is an unusual C idiom used to unroll loops. VisualDSP's optimizer is supposed to be smart enough to do good loop unrolling on its own but sometimes you have to disable a broken optimizer to get code out the door. <http://www.lysator.liu.se/c/duffs-device.html> |
Duff's Device
Started by ●March 21, 2005
Reply by ●March 22, 20052005-03-22
On Mon, 21 Mar 2005, Kenneth Porter wrote: > > I saw this mentioned in a recent SlashDot story and was curious if anyone > knows what VisualDSP does when it encounters this. Duff's Device is an > unusual C idiom used to unroll loops. VisualDSP's optimizer is supposed to > be smart enough to do good loop unrolling on its own but sometimes you have > to disable a broken optimizer to get code out the door. > > <http://www.lysator.liu.se/c/duffs-device.html> > Unusual is right. Why put a test in where a count will do fine? Especially on a dsp with hardware overhead built in - loop unrolling hurts a lot more than it helps. If to and from are in dm and pm respectively, you can do the whole thing with 2 instructions plus overhead: i0 = to; i8 = from; m0 = 1; m8 = 1; r0 = dm(i0,m0); lcntr = count, do moveit until lce; moveit: r0 = dm(i0,m0), dm(i8,m8) = r0; dm(i8,m8) = r0; The optimizer will have a much simpler time if the C is simple. In 1983 processors and compilers were pretty dumb, so it may have made sense then. I don't think Duff's Device makes any sense these days. Patience, persistence, truth, Dr. mike |
Reply by ●March 22, 20052005-03-22
I believe, if my understanding is correct, is that "Duff's
Device" was meant to be a portable standard c method of loop unrolling. Someone steeped in the architectural details of a specific processor can often do better in assembly language than a compiler. Item 7 in the posting states the following : * Transformations like this can only be justified by measuring the resulting code. Be careful when you use this thing that you don't unwind the loop so much that you overflow your machine's instruction cache. Don't try to be smarter than an over-clever C compiler that recognizes loops that implement block move or block clear and compiles them into machine idioms. At 08:07 PM 3/21/2005, Mike Rosing wrote: >On Mon, 21 Mar 2005, Kenneth Porter wrote: > > > > > I saw this mentioned in a recent SlashDot story and was curious if anyone > > knows what VisualDSP does when it encounters this. Duff's Device is an > > unusual C idiom used to unroll loops. VisualDSP's optimizer is supposed to > > be smart enough to do good loop unrolling on its own but sometimes you have > > to disable a broken optimizer to get code out the door. > > > > <http://www.lysator.liu.se/c/duffs-device.html> > > > >Unusual is right. Why put a test in where a count will do fine? >Especially on a dsp with hardware overhead built in - loop unrolling hurts >a lot more than it helps. If to and from are in dm and pm respectively, >you can do the whole thing with 2 instructions plus overhead: > > i0 = to; > i8 = from; > m0 = 1; > m8 = 1; > r0 = dm(i0,m0); > lcntr = count, do moveit until lce; >moveit: > r0 = dm(i0,m0), dm(i8,m8) = r0; > dm(i8,m8) = r0; > >The optimizer will have a much simpler time if the C is simple. In 1983 >processors and compilers were pretty dumb, so it may have made sense then. >I don't think Duff's Device makes any sense these days. > >Patience, persistence, truth, >Dr. mike Steve Holle Link Communications, Inc. 1035 Cerise Rd. Billings, MT 59101 |