Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!tut.cis.ohio-state.edu!rutgers!att!alberta!ubc-cs!van-bc!rsoft!mindlink!a218
From: a218@mindlink.UUCP (Charlie Gibbs)
Newsgroups: comp.sys.amiga.tech
Subject: Re: A68k and Manx AS
Message-ID: <221@mindlink.UUCP>
Date: 30 Apr 89 21:51:10 GMT
Organization: MIND LINK! - British Columbia, Canada
Lines: 31

In article <4784@umd5.umd.edu> brett@umd5.umd.edu (Brett Bourbin) writes:
 <...>
>        There was one difference though, the object code size for the
>A68k code was 30% _Smaller_ than that of Manx's AS.  Is there something
>that AS includes in it's .o files that A68k is not?  This coupled with
>the fact I can use BLink instead of LN has made me switch my assembly
>enviorment.

     I've put the following optimization routines into A68k:

        - Bcc is converted to Bcc.S if possible (for backward
            references only - forward references are too hard :-).

        - Backward references within the current CODE section
            are converted to PC-relative if possible (again,
            forward references get ugly).

        - ADD, SUB, and MOVE instructions are converted to
            ADDQ, SUBQ, and MOVEQ if possible.

        - Any operand of the form 0(An) is converted to (An)
            (except for MOVEP, which must have a displacement).

     Some people have complained that this mucks up jump tables,
so my next version will likely have a switch allowing optimization
to be disabled (or I'll add support for operands such as (xxxx).L,
which A68k currently can't handle).  I'm impressed that it shrunk
your object code by 30%.  Thanks for the testimonial.

Charlie_Gibbs@mindlink.UUCP
"Programmers who write small modules have short attention spans."