david@sun.uucp (David DiGiacomo) (04/24/87)
In article <875@nrcvax.UUCP> ihm@minnie.UUCP (Ian Merritt) writes: >Yeah, but try coding up your tight bitblit using bitfield instructions >on the '020. I think you will find that it is MUCH shorter and faster >than the 68000 version. Shorter yes, faster -- probably not. Using the bitfield instructions cuts instruction count at the expense of memory cycles. Since the 68020 always has an I cache it's reasonable to burn a few extra instructions to minimize memory accesses. However, the biggest disadvantage of the bitfield instructions is that it's impossible to use them effectively from C. The current Sun bitblt (libpixrect.a:mem_rop.o) is close to 26K of object code -- there's no way I could have written that in assembly language! Aside from clock rate, data bus width, and the I cache, the 68020's biggest advantage over the 68010 for bitblt is its barrel shifter. On the 68010 a 16 bit bitblt is generally better than a 32 bit version because the reduced average shift count makes up for the increased instruction count. I agree with the other posters that the 386 doesn't have enough registers for bitblt. The 10 registers I get with the Sun 680x0 compiler are almost enough, although I could make good use of 6-10 more. (It always bugs me that architecture and compiler people ignore graphics code when deciding how to build systems...) -- David DiGiacomo, Sun Microsystems, Mt. View, CA sun!david david@sun.com
jdg@elmgate.UUCP (Jeff Gortatowsky) (04/27/87)
In article <17320@sun.uucp> david@sun.uucp (David DiGiacomo) writes: > >However, the biggest disadvantage of the bitfield instructions is that >it's impossible to use them effectively from C. The current Sun bitblt >(libpixrect.a:mem_rop.o) is close to 26K of object code -- there's no >way I could have written that in assembly language! >David DiGiacomo, Sun Microsystems, Mt. View, CA sun!david david@sun.com One thing that always makes me grin is the way some folks look down (pun intended) at assembler. 26k of assembly code is not that uncommon for a library or application written in assembly. Further had you coded your routines in assembly, it *may* have been significantly less than 26k. Maintaining the code is another story all together. How *WELL* written assembler is maintainable. One think that irk's me. If my Sun is FAST now, just think how fast it could have............(or buggy, umm.. well then again I'm using 3.2, so much for that! :^) ). I've always liked to get my code working in C, then recode the low level stuff into assembler. Things like pixrects.......... -- Jeff Gortatowsky {seismo,allegra}!rochester!kodak!elmgate!jdg Eastman Kodak Company These comments are mine alone and not Eastman Kodak's. How's that for a simple and complete disclaimer?