Path: utzoo!attcan!uunet!mcsun!hp4nl!philapd!ssp11!dolf
From: dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer)
Newsgroups: comp.sys.m68k
Subject: Re: Code too Big to ROM - where do we optimize
Message-ID: <705@ssp11.idca.tds.philips.nl>
Date: 28 Mar 90 08:18:01 GMT
References: <5873@tekig5.PEN.TEK.COM> <1352@marlin.NOSC.MIL>
Organization: Philips Information Systems, Apeldoorn, The Netherlands
Lines: 19

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