home *** CD-ROM | disk | FTP | other *** search
- 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
-