boehm-gc/README.amiga

   1 ===========================================================================
   2                            Martin Tauchmann's notes             (1-Apr-99)
   3 ===========================================================================
   4
   5 Works now, also with the GNU-C compiler V2.7.2.1. <ftp://ftp.unina.it/pub/amiga/geekgadgets/amiga/m68k/snapshots/971125/amiga-bin/>
   6 Modify the `Makefile`
   7 CC=cc $(ABI_FLAG)
   8 to
   9 CC=gcc $(ABI_FLAG)
  10
  11 TECHNICAL NOTES
  12
  13 - `GC_get_stack_base()`, `GC_register_data_segments()` works now with every
  14    C compiler; also Workbench.
  15
  16 - Removed AMIGA_SKIP_SEG, but the Code-Segment must not be scanned by GC.
  17
  18
  19 PROBLEMS
  20 - When the Linker, does`t merge all Code-Segments to an single one. LD of GCC
  21   do it always.
  22
  23 - With ixemul.library V47.3, when an GC program launched from another program
  24   (example: `Make` or `if_mach M68K AMIGA gctest`), `GC_register_data_segments()`
  25   found the Segment-List of the caller program.
  26   Can be fixed, if the run-time initialization code (for C programs, usually *crt0*)
  27   support `__data` and `__bss`.
  28
  29 - PowerPC Amiga currently not supported.
  30
  31 - Dynamic libraries (dyn_load.c) not supported.
  32
  33
  34 TESTED WITH SOFTWARE
  35
  36 `Optimized Oberon 2 C` (oo2c) <http://cognac.informatik.uni-kl.de/download/index.html>
  37
  38
  39 TESTED WITH HARDWARE
  40
  41 MC68030
  42
  43
  44 CONTACT
  45
  46 Please, contact me at <martintauchmann@bigfoot.com>, when you change the
  47 Amiga port. <http://martintauchmann.home.pages.de>
  48
  49 ===========================================================================
  50                            Michel Schinz's notes
  51 ===========================================================================
  52 WHO DID WHAT
  53
  54 The original Amiga port was made by Jesper Peterson. I (Michel Schinz)
  55 modified it slightly to reflect the changes made in the new official
  56 distributions, and to take advantage of the new SAS/C 6.x features. I also
  57 created a makefile to compile the "cord" package (see the cord
  58 subdirectory).
  59
  60 TECHNICAL NOTES
  61
  62 In addition to Jesper's notes, I have the following to say:
  63
  64 - Starting with version 4.3, gctest checks to see if the code segment is
  65   added to the root set or not, and complains if it is. Previous versions
  66   of this Amiga port added the code segment to the root set, so I tried to
  67   fix that. The only problem is that, as far as I know, it is impossible to
  68   know which segments are code segments and which are data segments (there
  69   are indeed solutions to this problem, like scanning the program on disk
  70   or patch the LoadSeg functions, but they are rather complicated). The
  71   solution I have chosen (see os_dep.c) is to test whether the program
  72   counter is in the segment we are about to add to the root set, and if it
  73   is, to skip the segment. The problems are that this solution is rather
  74   awkward and that it works only for one code segment. This means that if
  75   your program has more than one code segment, all of them but one will be
  76   added to the root set. This isn't a big problem in fact, since the
  77   collector will continue to work correctly, but it may be slower.
  78
  79   Anyway, the code which decides whether to skip a segment or not can be
  80   removed simply by not defining AMIGA_SKIP_SEG. But notice that if you do
  81   so, gctest will complain (it will say that "GC_is_visible produced wrong
  82   failure indication"). However, it may be useful if you happen to have
  83   pointers stored in a code segment (you really shouldn't).
  84
  85   If anyone has a good solution to the problem of finding, when a program
  86   is loaded in memory, whether a segment is a code or a data segment,
  87   please let me know.
  88
  89 PROBLEMS
  90
  91 If you have any problem with this version, please contact me at
  92 schinz@alphanet.ch (but do *not* send long files, since we pay for
  93 every mail!).
  94
  95 ===========================================================================
  96                           Jesper Peterson's notes
  97 ===========================================================================
  98
  99 ADDITIONAL NOTES FOR AMIGA PORT
 100
 101 These notes assume some familiarity with Amiga internals.
 102
 103 WHY I PORTED TO THE AMIGA
 104
 105 The sole reason why I made this port was as a first step in getting
 106 the Sather(*) language on the Amiga. A port of this language will
 107 be done as soon as the Sather 1.0 sources are made available to me.
 108 Given this motivation, the garbage collection (GC) port is rather
 109 minimal.
 110
 111 (*) For information on Sather read the comp.lang.sather newsgroup.
 112
 113 LIMITATIONS
 114
 115 This port assumes that the startup code linked with target programs
 116 is that supplied with SAS/C versions 6.0 or later. This allows
 117 assumptions to be made about where to find the stack base pointer
 118 and data segments when programs are run from WorkBench, as opposed
 119 to running from the CLI. The compiler dependent code is all in the
 120 GC_get_stack_base() and GC_register_data_segments() functions, but
 121 may spread as I add Amiga specific features.
 122
 123 Given that SAS/C was assumed, the port is set up to be built with
 124 "smake" using the "SMakefile". Compiler options in "SCoptions" can
 125 be set with "scopts" program. Both "smake" and "scopts" are part of
 126 the SAS/C commercial development system.
 127
 128 In keeping with the porting philosophy outlined above, this port
 129 will not behave well with Amiga specific code. Especially not inter-
 130 process comms via messages, and setting up public structures like
 131 Intuition objects or anything else in the system lists. For the
 132 time being the use of this library is limited to single threaded
 133 ANSI/POSIX  compliant or near-complient code. (ie. Stick to stdio
 134 for now). Given this limitation there is currently no mechanism for
 135 allocating "CHIP" or "PUBLIC" memory under the garbage collector.
 136 I'll add this after giving it considerable thought. The major
 137 problem is the entire physical address space may have to me scanned,
 138 since there is no telling who we may have passed memory to.
 139
 140 If you allocate your own stack in client code, you will have to
 141 assign the pointer plus stack size to GC_stackbottom.
 142
 143 The initial stack size of the target program can be compiled in by
 144 setting the __stack symbol (see SAS documentaion). It can be over-
 145 ridden from the CLI by running the AmigaDOS "stack" program, or from
 146 the WorkBench by setting the stack size in the tool types window.
 147
 148 SAS/C COMPILER OPTIONS (SCoptions)
 149
 150 You may wish to check the "CPU" code option is appropriate for your
 151 intended target system.
 152
 153 Under no circumstances set the "StackExtend" code option in either
 154 compiling the library or *ANY* client code.
 155
 156 All benign compiler warnings have been suppressed. These mainly
 157 involve lack of prototypes in the code, and dead assignments
 158 detected by the optimizer.
 159
 160 THE GOOD NEWS
 161
 162 The library as it stands is compatible with the GigaMem commercial
 163 virtual memory software, and probably similar PD software.
 164
 165 The performance of "gctest" on an Amiga 2630 (68030 @ 25Mhz)
 166 compares favourably with an HP9000 with similar architecture (a 325
 167 with a 68030 I think).
 168
 169 -----------------------------------------------------------------------
 170
 171 The Amiga port has been brought to you by:
 172
 173 Jesper Peterson.
 174
 175 jep@mtiame.mtia.oz.au           (preferred, but 1 week turnaround)
 176 jep@orca1.vic.design.telecom.au (that's orca<one>, 1 day turnaround)
 177
 178 At least one of these addresses should be around for a while, even
 179 though I don't work for either of the companies involved.
 180