Re: MIPS gas relaxation still doesn't work

[Dominic Sweetman <dom at algor dot co dot uk>]

Alexandre,

> I know the problem that branch relaxation [aka delay-slot filling by
> the assembler] is intended to solve: it's a
> work around for a long-standing bug in the compiler.  In that it
> apparently assumes that the expansion of certain macros is shorter
> than they actually are, so it ends up not doing branch shortening in
> some necessary situations.  This gets even worse with mips16, in which
> we don't do branch shortening, and the assembler doesn't do branch
> relaxation.

This true - but it isn't why it's there.  Getting the assembler
involved goes back to the early 1980s roots of the MIPS project:

o It saved putting novel and interesting code into compilers.  A safe
  and quick hack to the assembler probably catches more than half the
  delay slots available; anything other than very clever compiler work
  might do little better.  Nobody should forget that most 
  'commercial' compilers are even more ghastly than gcc.

o It concealed the deeply unfamiliar and counter-intuitive "delay
  slot" from the assembler programmer.

o At the time, MIPS' assembler was related to a DoD initiative to
  write mission-critical software via a
  slightly-higher-than-machine-language assembly code - a kind of
  "what if Ada doesn't work?" project.  As such, there was good reason
  to get the *compiler* to target assembler language.

The first GCC ports for MIPS were quick hacks using the MIPS
assembler. They made liberal use of what were effectively macro
instructions.  RISC CPUs were kind of new, and back-end coders quailed
at a machine which had no register-to-register move and where even the
nop is an alias.  More pernicious, as you say, is the use of macros
such as "la" or even "lw" which expand different ways...

Which got a whole lot worse when gcc/gas was hacked again for position
independent code and the bulk of that work was done in the assembler.

> But while you're trying to paper over the problem, others are
> rewriting the mips back end so as to not make use of macros, such that
> instruction lengths will be more accurate and then branch shortening
> will (hopefully) work correctly.

Other pressures, unfortunately, operate the other way; you could
generate substantially better position-independent MIPS code if you
were prepared to avoid committing the final instruction sequence until
the link which produced the executable or shared object...

But getting the assembler macros out of the compiler is a long-overdue
reform.

Algorithmics (now part of MIPS) have been chiselling away at this for
a long while, but opportunistically rather than as a focussed problem.
Moreover, our limited resource + the poor state of standard gcc
releases (at least up to two years ago) meant that producing a decent
usable compiler always took us so long that by the time it worked our
codebase was too old to facilitate changes going back.  We do have a
lot of useful changes for MIPS, and aim to resynchronise to 3.x and 
make a substantial attempt to get those changes back into the main
source trees, perhaps in 6 months time.

Meanwhile, do you have some sense of a plausible team and a schedule
for this reform in the 3.1.x codebase?

-- 
Dominic Sweetman
MIPS Technologies (formerly Algorithmics Ltd)
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205
http://www.algor.co.uk