Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!usc!jarthur!uunet!mcrware!kim
From: kim@mcrware.UUCP (Kim Kempf)
Newsgroups: comp.sys.m68k
Subject: Re: Code too Big to ROM - where do we optimize
Message-ID: <1589@mcrware.UUCP>
Date: 27 Mar 90 00:03:08 GMT
References: <5873@tekig5.PEN.TEK.COM>
Reply-To: kim@mcrware.UUCP (Kim Kempf)
Distribution: usa
Organization: Microware Systems Corp., Des Moines, Iowa
Lines: 35

In article <5873@tekig5.PEN.TEK.COM> barbaras@tekig5.PEN.TEK.COM (Barbara Ann Siefken) writes:
>Our code is too big to ROM.  Are there some assembly language
>statements or processes that are known to take less space if
>done another way?  Is that simplifying the question too much.

My personal favorite optimization that saves two bytes of object code
and a some memory cycles:

	...
	bsr.w foo
    rts
	...

replace with:

	...
	bra.w foo
	...

This may seem obvious to asm hacks, but I'm suprised how often this
can be applied.  A few more off the top of my head (small in themselves,
but they add up in large programs):

	- use 'moveq.l' whenever possible.
	- use 'moveq.l #0,d0' rather than 'clr.l d0'.  It's faster on non-68020.
	- use 'suba.l a0,a0' instead of 'move.l #0,a0'
	- use 'pea <n>.w' instead of 'move.l #<n>,-(sp)' where <n> is
	  less than abs(65535).  This uses the absolute short addressing mode
	  to generate an immediate long constant.

Enjoy.
-- 
----------------
Kim Kempf, Microware Systems Corporation	{sun,uunet}!mcrware!kim
           My employer guffaws at my opinions....