Article 34263 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!rutgers!cs.utexas.edu!uunet!munnari.oz.au!metro!sunb.ocs.mq.edu.au!laurel.ocs.mq.edu.au!mglew From: mglew@laurel.ocs.mq.edu.au (Michael Glew) Newsgroups: comp.sys.amiga.programmer Subject: REPORT: 68k Optimizations Message-ID: <211dmq$suk@sunb.ocs.mq.edu.au> Date: 2 Jul 93 13:37:30 GMT Sender: mglew@laurel.ocs.mq.edu.au (Michael Glew) Organization: Geotech Analytical Services, Macquarie University Lines: 313 NNTP-Posting-Host: laurel.ocs.mq.edu.au X-Location: Sydney, Australia X-Phone-Home: +61 2 808 2675 as promised here is the report - individual copies will be sent out shortly... ----cut-here-----8<------------ ........................................................................... : : : A S S E M B L E R O P T I M I Z A T I O N S : : : :.........................................................................: ASP68K PROJECT by mglew@laurel.ocs.mq.edu.au (Michael Glew) --------------------------------------------------------------------------- C O N T R I B U T O R S --------------------------------------------------------------------------- Frans Bouma, David Carson, Nicolas Dade, Andy Duplain, Steven Eker, Calle Englund, Alexander Fritsch, Charlie Gibbs, Kurt Haenen, Kjetil Jacobsen, Olav Kalgraf, Dave Mc Mahan, Lindsay Meek, Gunnar Rxnning, Peter Simons. --------------------------------------------------------------------------- I N T R O D U C T I O N --------------------------------------------------------------------------- A while back, I was quite interested to find that there was an electronic magazine called "how to code" that included lots of interesting hints and tips of coding. In the fifth edition, there was a list of optimizations that really got be thinking. "What if there was a proggy that you could put an assembler program through, that would speed it up, taking out all the stupid things output by compilers, and over-tired coders?" 8). I started combing the networks, and came across one such program, called the "SELCO Source Optimizer". It only had four optimizations, so I set to writing my own. Step one was to collect as many optimization ideas as I could. I posted to Usenet and got an impressive response, and the contributors are listed above. I promised a report on the optimizations recieved, and here it is. My aim now is to write a program to make these optimizations, and to distribute it. Contributers will recieve a copy of the final archive, to thank them for their time and energy. Further contributions will be welcomed, so rather than making changes yourself tell me what you want changed, and i'll distribute it with the next update. --------------------------------------------------------------------------- O P T I M I Z A T I O N S --------------------------------------------------------------------------- Note:- EACT = effective address calculation time m? = memory operand dx = data register ds = data register (scratch) ax = address register #n = immediate operand ?? = address label * = anything .x = any size bcc = branch commands Opt = optimization Case = notes about where optimization is valid Speed = are clock periods saved? (*=increase) Size = are bytes saved? (*=increase) ----------------------------------------------------------------------------- Opt Notes Speed Size 000 010 ------------------------------+-----------------------+---+---+-------------- move.x #0,m? -> clr.x m? | | N | | Y ------------------------------+-----------------------+---+---+---- move.l #n,dx -> moveq #n,dx | if -128<=n<=127 | Y | | Y ------------------------------+-----------------------+---+---+---- move.l #0,ax -> sub.w ax,ax | | Y | | N ------------------------------+-----------------------+---+---+---- move.w #0,ax -> sub.w ax,ax | | Y | | N ------------------------------+-----------------------+---+---+---- clr.l dx -> moveq #0,dx | | Y | | N ------------------------------+-----------------------+---+---+---- cmp.x #0,m? -> tst.x m? | | Y | | Y ------------------------------+-----------------------+---+---+---- cmp.x #0,dx -> tst.x dx | | Y | | Y ------------------------------+-----------------------+---+---+---- add.x #n,* -> addq.x #n,* | if 1<=n<=8 | Y | | Y ------------------------------+-----------------------+---+---+---- sub.x #n,* -> subq.x #n,* | if 1<=n<=8 | Y | | Y ------------------------------+-----------------------+---+---+---- jmp ?? -> bra.w ?? | label within $8000 | Y | | Y ------------------------------+-----------------------+---+---+---- jmp ?? -> jmp ??(pc) | same section behind pc| Y | | Y ------------------------------+-----------------------+---+---+---- jsr ?? -> bsr.w ?? | label within $8000 | Y | | Y ------------------------------+-----------------------+---+---+---- jsr ?? -> jsr ??(pc) | same section behind pc| Y | | Y ------------------------------+-----------------------+---+---+---- bsr ?? -> bra ?? | next opcode is rts | Y | | Y ------------------------------+-----------------------+---+---+---- jsr * -> jmp * | next opcode is rts | Y | | Y ------------------------------+-----------------------+---+---+---- asl.x #1,dy -> add.x dy,dy | | Y | | ------------------------------+-----------------------+---+---+---- lsl.x #1,dy -> add.x dy,dy | | Y | | ------------------------------+-----------------------+---+---+---- asl.w #2,dy -> add.w dy,dy | | Y | | add.w dy,dy | | | | ------------------------------+-----------------------+---+---+---- asl.b #2,dy -> add.b dy,dy | | Y | | add.b dy,dy | | | | ------------------------------+-----------------------+---+---+---- lsl.w #2,dy -> add.w dy,dy | | Y | | add.w dy,dy | | | | ------------------------------+-----------------------+---+---+---- lsl.b #2,dy -> add.b dy,dy | | Y | | add.b dy,dy | | | | ------------------------------+-----------------------+---+---+---- mulu #n,dx -> lsl #m,dx | n is 2^m, 2..2^8 | Y | Y | Y ------------------------------+-----------------------+---+---+---- muls #n,dx -> asl #m,dx | n is 2^m, 2..2^8 | Y | Y | Y ------------------------------+-----------------------+---+---+---- divu #n,dx -> lsr #m,dx | n is 2^m, 2..2^8 | Y | Y | Y ------------------------------+-----------------------+---+---+---- add.l #n,ax -> lea n(ax),ax | $ffff8000<=n<=$7fff | Y | | Y ------------------------------+-----------------------+---+---+---- add.w #n,ax -> lea n(ax),ax | $ffff8000<=n<=$7fff | Y | | ? ------------------------------+-----------------------+---+---+---- lea n(ax),ax -> addq.w #n,ax | if 1<=n<=8 | Y | | Y ------------------------------+-----------------------+---+---+---- lea n(ax),ax -> subq.w #-n,ax | if -8<=n<=-1 | Y | | Y ------------------------------+-----------------------+---+---+---- $0000nnnn.l -> $nnnn.w | if concerned with ax | | and 0<=nnnn<=$7fff | Y | Y | Y ------------------------------+-----------------------+---+---+---- move.l #n,ax -> lea n,ax | | Y | | N ------------------------------+-----------------------+---+---+---- move.l ax,ay -> lea n(ax),ay | | Y | | Y add.l #n,ay | | | | ------------------------------+-----------------------+---+---+---- move.x ??,* -> move.x ??(pc),*| same section behind pc| Y | Y | Y ------------------------------+-----------------------+---+---+---- lea ??,* -> lea ??(pc),* | same section behind pc| Y | Y | Y ------------------------------+-----------------------+---+---+---- *(ax,dx.l)* -> *(ax,dx.w)* | if 0<=dx<=$7fff | Y | Y | ? ------------------------------+-----------------------+---+---+---- movem.x @,* move.x @,* | @ = a single register | Y | Y | Y ------------------------------+-----------------------+---+---+---- move.l (ax),-(sp) -> pea (ax) | | Y | Y | N ------------------------------+-----------------------+---+---+---- move.l ??,-(sp) -> pea ?? | | Y | Y | N ------------------------------+-----------------------+---+---+---- *0(ax)* -> *(ax)* | | Y | Y | Y ------------------------------+-----------------------+---+---+---- mulu #0,dx -> moveq #0,dx | | Y | Y | Y ------------------------------+-----------------------+---+---+---- muls #0,dx -> moveq #0,dx | | Y | Y | Y ------------------------------+-----------------------+---+---+---- mulu #1,dx -> swap dx; | status flags wrong | Y | Y | N clr.w dx; swap dx | | | | ------------------------------+-----------------------+---+---+---- muls #1,dx -> swap dx; | status flags wrong | Y | Y | * clr.w dx; swap dx; ext.l dx | | | | ------------------------------+-----------------------+---+---+---- move.l (n.w,ax),dy -> | '020+ -> '000 command | - | - | Y move.l n(ax),dy | | | | ------------------------------+-----------------------+---+---+---- move.l (bd.x,ax),dy -> | '020+ opt | - | - | Y move.l bd.x,dy | | | | ------------------------------+-----------------------+---+---+---- *n.l* -> *n.w* | $ffff8000<=n<=$7fff | Y | Y | Y ------------------------------+-----------------------+---+---+---- move.l #n,dx -> moveq #m,dx; |$ff80ffff<=n<=$fffeffff| Y | Y | Y swap dx | $1000<=n<=$7f0000 | | | ------------------------------+-----------------------+---+---+---- move.l #n,dx -> moveq #m,dx; | $80<=n<=$ff | Y | Y | Y neg.b dx | | | | ------------------------------+-----------------------+---+---+---- move.l #n,dx -> moveq #m,dx; | $ffff<=n<=$ff81 | Y | Y | Y neg.w dx |$ffff0080<=n<=$ffff0001| | | ------------------------------+-----------------------+---+---+---- move.b #$ff,* -> st * | | Y | Y | Y ------------------------------+-----------------------+---+---+---- add.x #n,* -> subq.x #-n,* | -8<=n<=-1 | Y | Y | Y ------------------------------+-----------------------+---+---+---- sub.x #n,* -> addq.x #-n,* | -8<=n<=-1 | Y | Y | Y ------------------------------+-----------------------+---+---+---- sub.l #n,ax -> lea -n(ax),ax | $ffff8000<=n<=$7fff | Y | | Y ------------------------------+-----------------------+---+---+---- sub.w #n,ax -> lea -n(ax),ax | $ffff8000<=n<=$7fff | Y | | Y ------------------------------+-----------------------+---+---+---- bcc.w ?? -> bcc.s ?? | label within $80 | Y | Y | Y ------------------------------+-----------------------+---+---+---- addq.l #n,ax -> addq.w #n,ax | | | | ------------------------------+-----------------------+---+---+---- mulu #n,dx -> moveq #m,ds | n is 2^m, m>8 | Y | Y | Y lsl.w ds,dx | | | | ------------------------------+-----------------------+---+---+---- muls #n,dx -> moveq #m,ds | n is 2^m, m>8 | Y | Y | Y asl.w ds,dx | | | | ------------------------------+-----------------------+---+---+---- divu #n,dx -> moveq #m,ds | n is 2^m, m>8 | Y | Y | Y lsr.w ds,dx | | | | ------------------------------+-----------------------+---+---+---- nop -> ; | remove nops | Y | Y | Y ------------------------------+-----------------------+---+---+---- muls #3,dx -> move.l dx,ds | | Y | Y | * add.l dx,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- mulu #3,dx -> move.l dx,ds | | Y | Y | * add.l dx,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- muls #4,dx -> add.l dx,dx | | Y | Y | N add.l dx,dx | | | | ------------------------------+-----------------------+---+---+---- mulu #4,dx -> add.l dx,dx | | Y | Y | N add.l dx,dx | | | | ------------------------------+-----------------------+---+---+---- muls #5,dx -> move.l dx,ds | | Y | Y | * add.l dx,dx | | | | add.l dx,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- mulu #5,dx -> move.l dx,ds | | Y | Y | * add.l dx,dx | | | | add.l dx,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- muls #6,dx -> add.l dx,dx | | Y | Y | * move.l dx,ds | | | | add.l ds,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- mulu #6,dx -> add.l dx,dx | | Y | Y | * move.l dx,ds | | | | add.l ds,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- muls #7,dx -> move.l dx,ds | | Y | Y | * asl.l #3,dx | | | | sub.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- mulu #7,dx -> move.l dx,ds | | Y | Y | * lsl.l #3,dx | | | | sub.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- muls #9,dx -> move.l dx,ds | | Y | Y | * asl.l #3,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- mulu #9,dx -> move.l dx,ds | | Y | Y | * lsl.l #3,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- muls #10,dx -> add.l dx,dx | | Y | Y | * move.l dx,ds | | | | asl.l #2,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- mulu #10,dx -> add.l dx,dx | | Y | Y | * move.l dx,ds | | | | lsl.l #2,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- muls #11,dx -> move.l dx,ds | | Y | Y | * add.l dx,dx | | | | add.l dx,ds | | | | asl.l #3,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- mulu #11,dx -> move.l dx,ds | | Y | Y | * add.l dx,dx | | | | add.l dx,ds | | | | lsl.l #3,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- muls #12,dx -> add.l dx,dx | | Y | Y | * add.l dx,dx | | | | move.l dx,ds | | | | add.l dx,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- mulu #12,dx -> add.l dx,dx | | Y | Y | * add.l dx,dx | | | | move.l dx,ds | | | | add.l dx,dx | | | | add.l ds,dx | | | | ------------------------------+-----------------------+---+---+---- --------------------------------------------------------------------------- C O N C L U S I O N --------------------------------------------------------------------------- There are the optimizations i've come up with so far. If you could check what i've done, and report any errors, that would make this list better. I only have so much time to spend on this, and many hands make light work. Also, stats (and more optimizations) for 68020+ CPU's would be welcomed. Currently this list is only for simple peephole optimization stuff, but I will hopefully get around to more extensive optimizations. Pipeline optimization is on the way, so look out. Any info on the 68020+ pipelines would be appreciated. =========================================================================== EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF EOF =========================================================================== Article 34273 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!ogicse!network.ucsd.edu!swrinde!cs.utexas.edu!utnut!torn!news.ccs.queensu.ca!qucdn!leek From: LEEK@QUCDN.QueensU.CA Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Message-ID: <93183.141255LEEK@QUCDN.QueensU.CA> Date: 2 Jul 93 18:12:55 GMT Article-I.D.: QUCDN.93183.141255LEEK References: <211dmq$suk@sunb.ocs.mq.edu.au> Distribution: world Organization: Queen's University at Kingston Lines: 19 >that really got be thinking. "What if there was a proggy that you could >put an assembler program through, that would speed it up, taking out all >the stupid things output by compilers, and over-tired coders?" 8). I [long list of optimizations deleted] >nop -> ; | remove nops | Y | Y | Y I hope you can provide some ways to turn off optimization in some section of the assembly file. Sometime there are instructions such as nops that are intentionally inserted in I/O routines (or whatever) to slow things down a bit... I think nop also has some side effects - mainly timing in higher CPU that have caches. In risc chips these instructions are actually use to help schedule thing in pipelines/ branches. Reorganizing or replacing instructions on Risc chips (Higher CPU ?) might not be a good idea. K. C. Lee Elec. Eng. Grad. Student Article 34278 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!gaia.ucs.orst.edu!umn.edu!spool.mu.edu!uwm.edu!caen!nic.umass.edu!ymir.cs.umass.edu!atkin From: atkin@cs.umass.edu (Marc Atkin) Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Date: 2 Jul 1993 22:01:19 GMT Organization: University of Massachusetts/Amherst Lines: 85 Distribution: world Message-ID: <212b7fINNskl@ymir.cs.umass.edu> References: <211dmq$suk@sunb.ocs.mq.edu.au> NNTP-Posting-Host: freya.cs.umass.edu In article [...] mglew@laurel.ocs.mq.edu.au (Michael Glew) writes: >........................................................................... >: : >: A S S E M B L E R O P T I M I Z A T I O N S : >: : >:.........................................................................: > Careful! Some of these optimizations assume high words are zero or infuence flags in different ways. Here are some problematic cases: >------------------------------+-----------------------+---+---+---- >mulu #n,dx -> lsl #m,dx | n is 2^m, 2..2^8 | Y | Y | Y >------------------------------+-----------------------+---+---+---- >muls #n,dx -> asl #m,dx | n is 2^m, 2..2^8 | Y | Y | Y >------------------------------+-----------------------+---+---+---- After mulu all 32 bits of dx are valid. This may not be the case with lsl and asl! >------------------------------------------------------------------- >divu #n,dx -> lsr #m,dx | n is 2^m, 2..2^8 | Y | Y | Y >------------------------------+-----------------------+---+---+---- I hope you mean lsr.l. These two statement will give different results if the result does not fit in a word! (lsr works, divu will signal an overflow.) >------------------------------+-----------------------+---+---+---- >lea n(ax),ax -> addq.w #n,ax | if 1<=n<=8 | Y | | Y >------------------------------+-----------------------+---+---+---- >lea n(ax),ax -> subq.w #-n,ax | if -8<=n<=-1 | Y | | Y >------------------------------+-----------------------+---+---+---- Do addq.w and subq.w do sign-extension to long-word? Use addq.l and subq.l, they have the same execution times! >------------------------------+-----------------------+---+---+---- >movem.x @,* move.x @,* | @ = a single register | Y | Y | Y >------------------------------+-----------------------+---+---+---- movem doesn't change flags, move does! I use that fact a lot in my programs. >------------------------------+-----------------------+---+---+---- >bcc.w ?? -> bcc.s ?? | label within $80 | Y | Y | Y >------------------------------+-----------------------+---+---+---- Isn't this the same thing? >------------------------------+-----------------------+---+---+---- >addq.l #n,ax -> addq.w #n,ax | | | | >------------------------------+-----------------------+---+---+---- Why? These commands have the same space needs and execution times >------------------------------------------------------------------ >mulu #n,dx -> moveq #m,ds | n is 2^m, m>8 | Y | Y | Y > lsl.w ds,dx | | | | >------------------------------+-----------------------+---+---+---- >muls #n,dx -> moveq #m,ds | n is 2^m, m>8 | Y | Y | Y > asl.w ds,dx | | | | >------------------------------+-----------------------+---+---+---- >divu #n,dx -> moveq #m,ds | n is 2^m, m>8 | Y | Y | Y > lsr.w ds,dx | | | | >------------------------------+-----------------------+---+---+---- These are (I think) the correct formulation of the previous mulu command optimizations. The problem is determining ds, which has to be a free register! >------------------------------------------------------------------- >nop -> ; | remove nops | Y | Y | Y >------------------------------+-----------------------+---+---+---- Sometimes nops are put there on purpose. Marc Atkin // U of Massachusetts // " Goosnargh. " at Amherst \\ // atkin@cs.umass.edu \X/ Article 34295 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!rutgers!cs.utexas.edu!sdd.hp.com!saimiri.primate.wisc.edu!doug.cae.wisc.edu!pochanay From: pochanay@cae.wisc.edu (Adisak Pochanayon) Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Message-ID: <1993Jul3.004759.18991@doug.cae.wisc.edu> Date: 3 Jul 93 05:47:59 GMT References: <211dmq$suk@sunb.ocs.mq.edu.au> <212b7fINNskl@ymir.cs.umass.edu> Organization: College of Engineering, Univ. of Wisconsin--Madison Lines: 29 In article <212b7fINNskl@ymir.cs.umass.edu> atkin@cs.umass.edu (Marc Atkin) writes: >In article [...] mglew@laurel.ocs.mq.edu.au (Michael Glew) writes: >>------------------------------+-----------------------+---+---+---- >>lea n(ax),ax -> addq.w #n,ax | if 1<=n<=8 | Y | | Y >>------------------------------+-----------------------+---+---+---- >>lea n(ax),ax -> subq.w #-n,ax | if -8<=n<=-1 | Y | | Y >>------------------------------+-----------------------+---+---+---- > >Do addq.w and subq.w do sign-extension to long-word? Use addq.l and >subq.l, they have the same execution times! > Yes, use add.w and sub.w as they DO AUTOMATICALLY SIGN EXTEND. You will not notice a speed up for values 1-8 (which is when you can use the "quick" forms) but for values 32K thru -32K the add.w and sub.w are much faster. Even add.w dx,ax is faster than add.l dx,ax . "dx" will auto sign-extend in the first case. The .w forms are faster than the .l forms considerably. > >>------------------------------+-----------------------+---+---+---- >>bcc.w ?? -> bcc.s ?? | label within $80 | Y | Y | Y >>------------------------------+-----------------------+---+---+---- > >Isn't this the same thing? > Nope! bcc.s takes two bytes while bcc.w takes four bytes. However bcc.w has a range of +-32K and bcc.s has +-128 bytes. adisak pochanayon pochanay@cae.wisc.edu Article 34302 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!rutgers!gatech!howland.reston.ans.net!noc.near.net!uunet!mcsun!ieunet!tcdcs!maths.tcd.ie!dwmalone From: dwmalone@maths.tcd.ie (David Malone) Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Message-ID: <1993Jul3.204141.2965@maths.tcd.ie> Date: 3 Jul 93 20:41:41 GMT References: <211dmq$suk@sunb.ocs.mq.edu.au> <212b7fINNskl@ymir.cs.umass.edu> Organization: Dept. of Maths, Trinity College, Dublin, Ireland. Lines: 13 atkin@cs.umass.edu (Marc Atkin) writes: >>------------------------------------------------------------------- >>nop -> ; | remove nops | Y | Y | Y >>------------------------------+-----------------------+---+---+---- >Sometimes nops are put there on purpose. Is there any reason but timing and self altering code to put in 'nop' ? I was under the impression that these were no-no's anyway. David Malone. Article 34305 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!umn.edu!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!spool.mu.edu!nigel.msen.com!caen!nic.umass.edu!ymir.cs.umass.edu!atkin From: atkin@cs.umass.edu (Marc Atkin) Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Date: 3 Jul 1993 22:05:38 GMT Organization: University of Massachusetts/Amherst Lines: 44 Message-ID: <214vriINNb08@ymir.cs.umass.edu> References: <211dmq$suk@sunb.ocs.mq.edu.au> <212b7fINNskl@ymir.cs.umass.edu> <1993Jul3.204141.2965@maths.tcd.ie> NNTP-Posting-Host: freya.cs.umass.edu In article [...] dwmalone@maths.tcd.ie (David Malone) writes: > >Is there any reason but timing and self altering code to put in 'nop' ? >I was under the impression that these were no-no's anyway. > > David Malone. Well, here's is an example of when I occasionally use 'nops': I have a bunch of code modules that all branch to one label when they are finished (this happens in 'case' statements, for example). Let's call this label 'exit'. Then we have the following situation: module1: [code] bra.s exit module2: [code] bra.s exit module3: [code] bra.s exit nop exit: [more code] Why is the nop before 'exit'? Because you can't have a bra.s with zero distance. Why don't I just remove the last 'bra.s exit'? Well, I might want to add more modules later and it would be easy to forget to add the 'bra.s' again. I realize that this might be viewed as a contrived example, but it does exist. A good optimizer/assembler might be able to remove 'bra.s' statements with zero branching distance, but mine (Devpac 3.02) doesn't; it just complains about them. Marc Atkin // "I suspect that the problem is that you have too U of Massachusetts // many paper clips up your nose." at Amherst \\ // - "Reg" (from "Dirk Gently's atkin@cs.umass.edu \X/ Holistic Detective Agency") Article 34304 of comp.sys.amiga.programmer: Newsgroups: comp.sys.amiga.programmer Path: news.csos.orst.edu!gaia.ucs.orst.edu!umn.edu!spool.mu.edu!wupost!uhog.mit.edu!uw-beaver!rrogers From: rrogers@cs.washington.edu (Richard Rogers) Subject: Re: REPORT: 68k Optimizations Message-ID: <1993Jul3.221042.11257@beaver.cs.washington.edu> Sender: news@beaver.cs.washington.edu (USENET News System) Organization: Computer Science & Engineering, U. of Washington, Seattle References: <211dmq$suk@sunb.ocs.mq.edu.au> <212b7fINNskl@ymir.cs.umass.edu> <1993Jul3.204141.2965@maths.tcd.ie> Date: Sat, 3 Jul 93 22:10:42 GMT Lines: 18 In article <1993Jul3.204141.2965@maths.tcd.ie> dwmalone@maths.tcd.ie (David Malone) writes: >atkin@cs.umass.edu (Marc Atkin) writes: > > >>>------------------------------------------------------------------- >>>nop -> ; | remove nops | Y | Y | Y >>>------------------------------+-----------------------+---+---+---- > >>Sometimes nops are put there on purpose. > >Is there any reason but timing and self altering code to put in 'nop' ? >I was under the impression that these were no-no's anyway. > > David Malone. Pipeline synchronization may require nops. This is only an issue for the higher end CPUs. Article 34373 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!umn.edu!news-feed-1.peachnet.edu!darwin.sura.net!haven.umd.edu!uunet!pipex!sunic!seunet!piraya!overdose!Mark_Cassidy From: Mark_Cassidy@wize.bbs.bad.se (Mark Cassidy) Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Message-ID: Date: Sun, 4 Jul 93 21:53:32 +0200 References: <93183.141255LEEK@QUCDN.QueensU.CA> Sender: BadNet@piraya.bad.se Reply-To: Mark_Cassidy@wize.bbs.bad.se (Mark Cassidy) Distribution: world Organization: Wize Productions, Odense, Denmark OD-Comment-To: Internet_Gateway Lines: 24 In a message of < 2-Jul-93 20:12> Internet Gateway (2:230/27647.10183) wrote: IG> branches. Reorganizing or replacing instructions on Risc chips IG> (Higher CPU ?) might not be a good idea. A few more cents here. Replacing NOP instructions is never a good idea. One might as well assume thata NOP in an assembler source is INTENDED to be there. >--- The NOP instruction does not begin execution until all pending bus cycles have completed. This synchronizes the pipeline and prevents instruction overlap. >--- ______________________ / / E-mail: wizz@wize.bbs.bad.se / Wize Productions DK / FidoNet: 2:230/611.0 /_____________________/ FServ Development Site | --*-- | --- Article 34380 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!rutgers!cs.utexas.edu!math.ohio-state.edu!darwin.sura.net!news-feed-1.peachnet.edu!umn.edu!doug.cae.wisc.edu!pochanay From: pochanay@cae.wisc.edu (Adisak Pochanayon) Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Message-ID: <1993Jul5.174428.23717@doug.cae.wisc.edu> Date: 5 Jul 93 22:44:27 GMT References: <93183.141255LEEK@QUCDN.QueensU.CA> Organization: College of Engineering, Univ. of Wisconsin--Madison Lines: 27 In article Mark_Cassidy@wize.bbs.bad.se (Mark Cassidy) writes: >Replacing NOP instructions is never a good idea. One might as well assume >thata NOP in an assembler source is INTENDED to be there. > >>--- >The NOP instruction does not begin execution until all pending bus cycles have >completed. This synchronizes the pipeline and prevents instruction overlap. >>--- > Well, there are very few times you actually want to do this but I can name a few. 1) When using coprocessor instructions such as '881,'882, or '040 FPU to make sure the COPROC instructions have completed before trying to get the results. 2) Flushing CACHEs on the CPU. 3) Rebooting the machine (yep the "allowed" method requires NOP's). I guess these are important enough to warrant not removing NOP's unless you really know what they do but for 99% of the code out there, NOP's aren't necessary... You certainly shouldn't use them for timing purposes :( Whack! Bad EuroHackers... BAD!!! adisak pochanayon pochanay@cae.wisc.edu Article 34388 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!gaia.ucs.orst.edu!umn.edu!news-feed-2.peachnet.edu!gatech!swrinde!elroy.jpl.nasa.gov!decwrl!waikato.ac.nz!comp.vuw.ac.nz!zephyr.grace.cri.nz!maths!peterm Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Message-ID: From: peterm@maths.grace.cri.nz (Peter McGavin) Date: 6 Jul 93 16:30:15 References: <211dmq$suk@sunb.ocs.mq.edu.au> <212b7fINNskl@ymir.cs.umass.edu><1993Jul3.204141.2965@maths.tcd.ie> Organization: Applied Maths, Industrial Research Ltd, NZ. NNTP-Posting-Host: kea.grace.cri.nz In-reply-to: mks@cbmvax.cbm.commodore.com's message of 5 Jul 93 11:58:22 GMT Lines: 26 dwmalone@maths.tcd.ie (David Malone) writes: >atkin@cs.umass.edu (Marc Atkin) writes: > > >>>------------------------------------------------------------------- >>>nop -> ; | remove nops | Y | Y | Y >>>------------------------------+-----------------------+---+---+---- > >>Sometimes nops are put there on purpose. > >Is there any reason but timing and self altering code to put in 'nop' ? >I was under the impression that these were no-no's anyway. The last time I used a NOP was when I wanted 2 different function pointers pointing to the same routine. I started the routine with: func1: nop func2: whatever ... then assigned func1 to the first pointer and func2 to the other one. The 2 pointers had to compare as being different, as part of the algorithm, even though they really pointed to the same routine. -- Peter McGavin. (peterm@maths.grace.cri.nz) Article 34408 of comp.sys.amiga.programmer: Newsgroups: comp.sys.amiga.programmer Path: news.csos.orst.edu!gaia.ucs.orst.edu!umn.edu!spool.mu.edu!howland.reston.ans.net!torn!nott!bnrgate!bnr.co.uk!uknet!mcsun!sunic!kitten.umdc.umu.se!cs.umu.se!dvljrt From: dvljrt@cs.umu.se (Joakim Rosqvist) Subject: Re: REPORT: 68k Optimizations Message-ID: Sender: dvljrt@cs.umu.se Organization: Dept. of Computing Science, Umea Univ., 901 87 UMEA SWEDEN References: <211dmq$suk@sunb.ocs.mq.edu.au> Date: Tue, 6 Jul 1993 17:12:02 GMT Lines: 81 >------------------------------+-----------------------+---+---+---- >move.l #0,ax -> sub.w ax,ax | | Y | | N >------------------------------+-----------------------+---+---+---- >move.w #0,ax -> sub.w ax,ax | | Y | | N >------------------------------+-----------------------+---+---+---- Make that "Y" on size as well. >------------------------------+-----------------------+---+---+---- >asl.w #2,dy -> add.w dy,dy | | Y | | > add.w dy,dy | | | | >------------------------------+-----------------------+---+---+---- >asl.b #2,dy -> add.b dy,dy | | Y | | > add.b dy,dy | | | | >------------------------------+-----------------------+---+---+---- >lsl.w #2,dy -> add.w dy,dy | | Y | | > add.w dy,dy | | | | >------------------------------+-----------------------+---+---+---- >lsl.b #2,dy -> add.b dy,dy | | Y | | > add.b dy,dy | | | | >------------------------------+-----------------------+---+---+---- And those require more bytes. >------------------------------+-----------------------+---+---+---- >add.w #n,ax -> lea n(ax),ax | $ffff8000<=n<=$7fff | Y | | ? >------------------------------+-----------------------+---+---+---- No "?". Same size. >lea n(ax),ax -> addq.w #n,ax | if 1<=n<=8 | Y | | Y >------------------------------+-----------------------+---+---+---- >lea n(ax),ax -> subq.w #-n,ax | if -8<=n<=-1 | Y | | Y >------------------------------+-----------------------+---+---+---- No Y for speed. Both versions are 8 cycles. >------------------------------+-----------------------+---+---+---- >*(ax,dx.l)* -> *(ax,dx.w)* | if 0<=dx<=$7fff | Y | Y | ? >------------------------------+-----------------------+---+---+---- No diff at all. Same size and same cycle count. >------------------------------+-----------------------+---+---+---- >mulu #1,dx -> swap dx; | status flags wrong | Y | Y | N > clr.w dx; swap dx | | | | Status flags are affected the same on 68000. Dunno with other CPU's. >------------------------------+-----------------------+---+---+---- >muls #1,dx -> swap dx; | status flags wrong | Y | Y | * > clr.w dx; swap dx; ext.l dx | | | | >------------------------------+-----------------------+---+---+---- Yuck! make that: muls #1,dx -> ext.l dx; Shorter, faster and flags are affected the same on 68000. >------------------------------+-----------------------+---+---+---- >nop -> ; | remove nops | Y | Y | Y >------------------------------+-----------------------+---+---+---- lea a(pc),a0 move #$70ff,(a0) ;opcode for "moveq #-1,d0" nop a: moveq #0,d0 If you remove the "nop" from the code above, d0 will be 0 instead of -1. /Joakim Rosqvist, dvljrt@cs.umu.se Article 34386 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!umn.edu!spool.mu.edu!olivea!gossip.pyramid.com!pyramid!cbmvax!mks From: mks@cbmvax.cbm.commodore.com (Michael Sinz) Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Message-ID: Date: 5 Jul 93 11:58:22 GMT References: <211dmq$suk@sunb.ocs.mq.edu.au> <212b7fINNskl@ymir.cs.umass.edu> <1993Jul3.204141.2965@maths.tcd.ie> Reply-To: mks@cbmvax.cbm.commodore.com (Michael Sinz) Organization: Commodore, West Chester, PA Lines: 26 dwmalone@maths.tcd.ie (David Malone) writes: >atkin@cs.umass.edu (Marc Atkin) writes: > > >>>------------------------------------------------------------------- >>>nop -> ; | remove nops | Y | Y | Y >>>------------------------------+-----------------------+---+---+---- > >>Sometimes nops are put there on purpose. > >Is there any reason but timing and self altering code to put in 'nop' ? >I was under the impression that these were no-no's anyway. In some cases a NOP can increase the speed of a program! Yes, it can. For example, if you have a major loop (one the runs many times) putting a CNOP 0,4 before the loop point (where it loops back on itself) can make the loop much faster on 68020 and up systems. (Unless the loop fits in the cache, in which case it will make no difference other than the possible NOP before the loop which is very little) Also, NOPs sync any pipelines and the like. On the 68040, they are required in some cases to make sure things you have "written" really did get written. -- Michael Sinz - mks@cbmvax.commodore.com - Recovering Commodore Engineer Director of Development - SCALA Inc. USA. - No Clone Zone - Amiga Required Article 34421 of comp.sys.amiga.programmer: Newsgroups: comp.sys.amiga.programmer Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!umn.edu!doug.cae.wisc.edu!pochanay From: pochanay@cae.wisc.edu (Adisak Pochanayon) Subject: Re: REPORT: 68k Optimizations Organization: College of Engineering, Univ. of Wisconsin--Madison Date: 6 Jul 93 15:31:58 CDT Message-ID: <1993Jul6.153159.9715@doug.cae.wisc.edu> References: <211dmq$suk@sunb.ocs.mq.edu.au> Lines: 20 > > lea a(pc),a0 > move #$70ff,(a0) ;opcode for "moveq #-1,d0" > nop >a: moveq #0,d0 > >If you remove the "nop" from the code above, d0 will be 0 instead of -1. >/Joakim Rosqvist, dvljrt@cs.umu.se Only true on a 68000. On a 68020+, even with the NOP, you can not be sure what the value will be. On an '040, I'd be willing to guess that 99 times out of 100 it's 0 even with the NOP. The above is self modifying code which is a no-no without cache flushing before attempting to execute it. It's a euro-hacker thing that often causes code to fail on 68020+ machines. adisak Article 34464 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!gaia.ucs.orst.edu!umn.edu!spool.mu.edu!howland.reston.ans.net!wupost!wuarchive!not-for-mail From: umueller@wuarchive.wustl.edu (Urban Mueller) Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Date: 7 Jul 1993 20:00:22 +0100 Organization: Washington University in St. Louis, MO USA Lines: 31 Message-ID: <21f6g6$m1t@wuarchive.wustl.edu> References: <211dmq$suk@sunb.ocs.mq.edu.au> <212b7fINNskl@ymir.cs.umass.edu> <1993Jul3.204141.2965@maths.tcd.ie> NNTP-Posting-Host: wuarchive.wustl.edu In article <1993Jul3.204141.2965@maths.tcd.ie> dwmalone@maths.tcd.ie (David Malone) writes: >atkin@cs.umass.edu (Marc Atkin) writes: > > >>>------------------------------------------------------------------- >>>nop -> ; | remove nops | Y | Y | Y >>>------------------------------+-----------------------+---+---+---- > >>Sometimes nops are put there on purpose. > >Is there any reason but timing and self altering code to put in 'nop' ? >I was under the impression that these were no-no's anyway. Most jump tables require NOPs. Useless example: jmp (table,pc,d0.w*4) table clr.w (a0)+ nop clr.w (a0)+ clr.l (a0)+ exit This construct clears 8 bytes if d0 is 0, 6 bytes if d0 is 1 and 0 bytes if d0 is 0. Of yourse I'd use something faster than nop nowadays, e.g. moveq #0,d0, but code that uses NOPs for instruction alignment most certainly still exists. -Urban Mueller Article 34681 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!ogicse!psgrain!agora!nesbbx!matrix!Jesse_Michael From: Jesse_Michael@matrix.rain.com (Jesse Michael) Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Message-ID: Date: 10 Jul 93 11:07:24 GMT Article-I.D.: matrix.Jesse_Michael.0485 Distribution: world Organization: The Matrix BBS +1-503-684-5516 Lines: 26 In a message dated Fri 9 Jul 93 14:10, umueller@wuarchive.wustl.edu (Urban Mueller) wrote: UM> This construct clears 8 bytes if d0 is 0, 6 bytes if d0 is 1 and 0 bytes UM> if d0 is 0. Now what does it do when d0 is 0? :^) UM> Of yourse I'd use something faster than nop nowadays, e.g. UM> moveq #0,d0, but code that uses NOPs for instruction alignment most UM> certainly still exists. Wait a minute. moveq #0,d0 is _faster_ than nop?!? What processor is _this_ on? :^) -Jesse -- Via DLG Pro v0.995 --- Haze of Epsilon / Check out Epsilon for the best in NTSC demos! Ok, so if you compare us to groups like Andromeda and Melon Dezign then we're lame, but what the hell do you expect from us lazy Americans?!? :^) Article 34682 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!rutgers!gatech!howland.reston.ans.net!ux1.cso.uiuc.edu!uwm.edu!ogicse!psgrain!agora!nesbbx!Robert_Barton From: Robert_Barton@nesbbx.rain.COM (Robert_Barton) Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Message-ID: Date: 11 Jul 93 13:48:38 GMT References: Followup-To: comp.sys.amiga.programmer Organization: NESBBX Bulletin Board System Lines: 14 X-NewsSoftware: BBX-UMB 0.33a beta (July 05, 1993) In , Jesse_Michael@matrix.rain.com (Jesse Michael) writes: > In a message dated Fri 9 Jul 93 14:10, umueller@wuarchive.wustl.edu (Urban > Mueller) wrote: > UM> Of yourse I'd use something faster than nop nowadays, e.g. > UM> moveq #0,d0, but code that uses NOPs for instruction alignment most > UM> certainly still exists. > > Wait a minute. moveq #0,d0 is _faster_ than nop?!? > What processor is _this_ on? :^) On the 68000 and 68010 they both take 4 cycles. Article 34683 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!rutgers!uwm.edu!ogicse!psgrain!agora!nesbbx!matrix!Jesse_Michael From: Jesse_Michael@matrix.rain.com (Jesse Michael) Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Message-ID: Date: 12 Jul 93 08:27:54 GMT Organization: The Matrix BBS +1-503-684-5516 Lines: 21 In a message dated Sun 11 Jul 93 7:01, Robert_Barton@nesbbx.rain.COM (Robert_Barton) wrote: R> In , Jesse_Michael@matrix.rain.com R> J> Wait a minute. moveq #0,d0 is _faster_ than nop?!? R> J> What processor is _this_ on? :^) R> On the 68000 and 68010 they both take 4 cycles. Yeah, that's what I thought. [I've got a _lot_ of the 68000 cycle times memorized... :^)] -Jesse -- Via DLG Pro v0.995 --- Haze of Epsilon / Check out Epsilon for the best in NTSC demos! Ok, so if you compare us to groups like Andromeda and Melon Dezign then we're lame, but what the hell do you expect from us lazy Americans?!? :^) Article 34691 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!rutgers!gatech!howland.reston.ans.net!xlink.net!rz.uni-karlsruhe.de!rz.uni-karlsruhe.de!ry41 From: ry41@rz.uni-karlsruhe.de (Bernhard Moellemann) Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Message-ID: <21u1lf$qep@nz12.rz.uni-karlsruhe.de> Date: 13 Jul 93 10:09:51 GMT References: Organization: University of Karlsruhe, Germany Lines: 14 NNTP-Posting-Host: tp72.rz.uni-karlsruhe.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In article , Jesse_Michael@matrix.rain.com (Jesse Michael) writes: >Wait a minute. moveq #0,d0 is _faster_ than nop?!? > >What processor is _this_ on? :^) On 68020 and higher NOP flushes the Pipelines. The refill may take some cycles. -------- Bernhard Mvllemann Chairman of the Nessy-Fan-Club // internet=zza@rz.uni-karlsruhe.de FIDO? still alive? IRC=ZZA // nessynet=008 Lifenet=77:7700/11.42 greetings to my Marsupilami \\ // 2000/500 Technical Reference Manual: "A1000, the original Amiga" \X/ Article 34755 of comp.sys.amiga.programmer: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!umn.edu!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!agate!ames!olivea!gossip.pyramid.com!pyramid!cbmvax!mks From: mks@cbmvax.cbm.commodore.com (Michael Sinz) Newsgroups: comp.sys.amiga.programmer Subject: Re: REPORT: 68k Optimizations Message-ID: Date: 14 Jul 93 20:50:18 GMT References: Reply-To: mks@cbmvax.cbm.commodore.com (Michael Sinz) Organization: Commodore, West Chester, PA Lines: 29 Jesse_Michael@matrix.rain.com (Jesse Michael) writes: >In a message dated Fri 9 Jul 93 14:10, umueller@wuarchive.wustl.edu (Urban >Mueller) wrote: > > UM> This construct clears 8 bytes if d0 is 0, 6 bytes if d0 is 1 and 0 >bytes > UM> if d0 is 0. > >Now what does it do when d0 is 0? :^) > > UM> Of yourse I'd use something faster than nop nowadays, e.g. > UM> moveq #0,d0, but code that uses NOPs for instruction alignment most > UM> certainly still exists. > >Wait a minute. moveq #0,d0 is _faster_ than nop?!? > >What processor is _this_ on? :^) 68030 with an FPU operation happening or a 68040 and the pipeline somewhat full. On the other processors they are the same speed but the moveq has side-effects. No side-effects with a move.l a0,a0... -- Mike -- Michael Sinz - mks@cbmvax.commodore.com - Recovering Commodore Engineer Director of Development - SCALA Inc. USA. - No Clone Zone - Amiga Required