Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!decvax!tektronix!orca!hammer!patcl
From: patcl@hammer.UUCP (Pat Clancy)
Newsgroups: net.arch
Subject: Re: Where are delayed branches handled?
Message-ID: <2239@hammer.UUCP>
Date: Wed, 20-Aug-86 23:41:28 EDT
Article-I.D.: hammer.2239
Posted: Wed Aug 20 23:41:28 1986
Date-Received: Sat, 23-Aug-86 21:58:38 EDT
References: <299@vaxb.calgary.UUCP> <823@jplgodo.UUCP> <624@mips.UUCP>
Reply-To: patcl@hammer.UUCP (Pat Clancy)
Organization: Tektronix, Wilsonville OR
Lines: 28

In article <624@mips.UUCP> mash@mips.UUCP (John Mashey) writes:
>In article <823@jplgodo.UUCP> steve@jplgodo.UUCP (Steve Schlaifer x43171 301/167) writes:
>>An optimizing assembler?  What a disaster that would be.  I want assemblers to
>>leave my code exactly as I wrote it....
>>
>>To answer your question, the compiler is the only place where such
>>optimizations can reasonably be done.
>
>2) The MIPS assembler does this all the time, and it works fine.
>

There's also a more fundamental issue involved in the choice of
where to do reorganizition; namely, the potential interdependence
between register allocation and reorganization opportunities.
This is especially apparent with global (eg.: coloring) allocation
schemes. A particular choice of register assignment will determine
(to some extent) how code may be rearranged to fill delayed
branch, handle interlock, etc. Then, if the rearranged code were
to be run once again through the register allocator, a more
optimal register assignment might be found (since liveness
ranges of values are now different). Then this output from the
allocator might be run through the reorganizer again..., etc.
This kind of feedback approach is impossible if register
allocation and reorganization are done in different programs
(compiler and assembler, respectively).

Pat Clancy
Tektronix