Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.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: <239@mindlink.UUCP>
Date: 7 May 89 22:39:43 GMT
Organization: MIND LINK! - British Columbia, Canada
Lines: 58

In article <8979@polya.Stanford.EDU>
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes:

>If you have memory available, it's not *that* difficult.  Simply maintain
>a list of `candidate' branches during the first pass.  A branch is a
>candidate if --> it's not already short and there isn't too much unmoveable
>code between it and it's target.  Now, simply run multiple passes over
>your branch list in *memory*, changing any appropriate ones to short, until
>it can no longer be done.  Now go back and update your symbol table.

     This sounds similar to a suggestion given to me by Bruce Dawson of
CygnusEd Pro fame.  Actually, it wouldn't even need that much memory;
since short branches can only span 128 bytes, I could kick candidates
off the end of the table once I've gone more than that far without
determining that I can convert it to short.  The largest I'd have to
make the table (assuming a whole bunch of consecutive forward Bcc
instructions) is 32 entries, since candidates would each take 4 bytes.
I'd probably want another table of pointers to symbol table entries
that would have to be adjusted, though.  That one could need up to 64
entries, assuming a bunch of consecutive labeled 2-byte instructions.
Still small potatoes, memory-wise.

     Of course, if I hit a SECTION directive I'd have to throw the
table away, so cases like

                SECTION myprog,CODE
                BRA     foo
                SECTION myprog,DATA
                DC.B    'gratuitous data section'
                SECTION myprog,CODE
        foo:

wouldn't get optimized, but I can't see this happening too often.

     The one fly in the ointment is CNOP.  Here's a case that would
break things:

                CNOP    0,4
                BRA     foo
                CNOP    0,4
        foo:

In this case, changing the BRA to BRA.S would not cause foo to move
because of the second CNOP.  So I can't just adjust symbol table
entries.  What I could do, though, is to jump back in the source
file and reprocess things starting at the Bcc that has to be adjusted.
But then there's the problem of going into and out of INCLUDEs,
macros, etc.   Maybe I should just wipe the table if I encounter a
CNOP, like I'll have to do with SECTION.

     Thanks for helping me think things through.  Just writing this
message has helped put things straight in my mind.

>tom

Charlie_Gibbs@mindlink.UUCP
"The terms 'undefined' and 'unspecified' have been given definitions."
        -- revision to the IEEE 1003.1 POSIX Standard