This diff contains the changes needed to gcc-2.1 (should work for later
versions as well, as most changes can be achieved by clever setting of
provided macros, only very few changes are needed to the non-target
specific source files) to provide base relative code generation. 

What does it do? The provided -fpic mode is rather Sun specific, and it
doesn't make much sense on a non-VM system like AmigaDOS (although
providing a message passing multitasking kernel, it doesn't feature virtual
memory and/or protected memory). The thing used here uses the following
technique:


Normal model:

+--------+--------------+
|        |              |   DATA/BSS space are treated like they were directly
|	 |              |   accessible from TEXT, absolute addressing can be 
|  TEXT  |  DATA & BSS  |   used, with the linker doing relocation to the 
|        |              |   variable runtime address of the executable.
|	 |              |
+--------+--------------+


Base relative model:

+--------+   +--------------+
|        |   |              |  Every access to DATA/BSS from TEXT must go by
|	 | B |              |  indirection on a register pointing at the
|  TEXT  |-->|  DATA & BSS  |  DATA/BSS region. This is the so called base
|        |   |              |  relative register (A4 in the AmigaDOS case).
|	 |   |              |
+--------+   +--------------+



Advantages to the base relative approach are:
- if working with 16bit offsets into DATA/BSS space, instructions are
  shorter than in absolute addressing mode.
- the shorter instructions are faster as well.
- by having the whole DATA/BSS space accessed only by indirection, it can
  easily be moved or replaced at runtime, providing a way to implement
  fork(2)-like operations even on a non-VM system.
- using this feature of relocation, programs can be made reentrant by just
  giving each new instance of the program its own DATA/BSS region.

Limitations of this approach:
- one register is permanently allocated to access DATA/BSS, and is not
  available for other purposes.
- additional support is required in the assembler (to generate special
  relocation information) and in the linker (to handle offsets instead of
  addresses).
- if using addressing like:
    movel a4@(_foo:W),d0
  to access the contents of variable `foo', then there is an upper limit
  of 64K for the size of DATA/BSS.
  There would be a solution to rewrite the above instruction into two
  instructions when compiling in `large data' mode (something similar to
  -fPIC versus -fpic), but I couldn't get gcc to output correct code for
  this situation, so I didn't include the (obviously wrong) code into
  this diff.


Information to the included diff
--------------------------------
The provided diff is *not* the complete diff to generate an AmigaDOS gcc.
It does however contain the complete current AmigaDOS target-specific
files (in the config/ directory). The additional patches are limited to
providing base relative support. I did this to facilitate incorporating 
these changes into non-Amiga environments, just hope I didn't corrupt
the diffs by editing the other stuff out...

If you want to implement this on a different m68k OS, take a look at the
pic/baserel related macros defined in config/amiga.h, use the function
read_only_operand() at the end of config/amiga.c, and try to setup
corresponding changes in your configuration files.

If you happen to understand more of gcc's interna than I (which is
easily possible ;-)), please take a look at my kludge in expr.c. The
problem is that internal calls to library functions have to be
qualified as well by ENCODE_SECTION_INFO(), but I didn't know how to
twiddle the existing data into a correct argument to ENCODE_SECTION_INFO(),
so I just inlined my specific action there. I'd like to see a clean
solution, but I'm not able to provide one.

I'm very open to suggestions, enhancements, bug reports, etc. I'd be
particularly interested if some kind soul finds out how to get RTL
evalutation to not convert the 

    gen_rtx (PLUS, Pmode, pic_offset_table_rtx, orig);

into an indirect addressing operand (pic-reg@(orig)), but to leave it
as an addition. The pic-reg@(orig) form is just not suitable for use
on a mc68000 if more than 64K should be addressable.



You can reach me as
<wild@nessie.cs.id.ethz.ch> or <wild@amiga.physik.unizh.ch>

-Markus Wild
