boehm-gc/README.amiga

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