barbaras@tekig5.PEN.TEK.COM (Barbara Ann Siefken) (03/24/90)
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. If people have suggestions of how to optimize 68K assembly code, please respond to: barbara Siefken barbaras@tekig5
markw@gvlf1-c.gvl.unisys.com (Mark H. Weber) (03/26/90)
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. > One area to check would be the usage of macros vs. subroutines. A macro is expanded in place each time it is used, so there may be many copies of the same code being generated. A subroutine may be substituted for the macro so that only one copy of the code is generated. Unfortunately there is slightly more overhead in a subroutine call (pushing/popping things from the stack). Generally, macros are used to optimize for high speed, and subroutines are used to optimize for small code size. Hope this helps! Mark -- Mark H. Weber | Internet: markw@GVL.Unisys.COM Unisys - Great Valley Labs | UUCP: ...!uunet!lgnp1!gvlv2!markw Paoli, PA USA (215) 648-7111 | ...!psuvax1!burdvax!gvlv2!markw
kim@mcrware.UUCP (Kim Kempf) (03/27/90)
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....
aburto@marlin.NOSC.MIL (Alfred A. Aburto) (03/28/90)
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. > > barbara Siefken > barbaras@tekig5 ------ Another useful code sequence is to replace CMP and BRANCH loops with a DBF --- this will save a bit of code and make the loop more efficient. The loop range is only word size though --- I was hoping Motorola would extend the range in the 68040, but alas they didn't ... The book by Steve Williams; '68030 Assembly Language Reference', Addison-Wesley, 1989 discusses some code optimizations that you might find useful ..... Al Aburto aburto@marlin.nosc.mil
dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) (03/28/90)
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. I've had the same problem. My limit was 32K and I used more than 33K. The solution I used was to compile my C sources to assembler and then combine all these assembler files plus my own assembler files into one large file and assemble just this one file. This means that you can replace all JMP/JSR by BRA/BSR. Doing so I saved about 4K. Note that this combining is not so easy, as the C compiler tends to generate duplicate labels for different C files. I used a sed script to replace all labels in such a file by an unique name (the file name followed by the original number). -- Dolf Grunbauer Tel: +31 55 433233 Internet dolf@idca.tds.philips.nl Philips Telecommunication and Data Systems UUCP ....!mcsun!philapd!dolf Dept. SSP, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands n n n It's a pity my .signature is too small to show you my solution of a + b = c