Initial revision

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@26246 138bc75d-0d04-0410-961f-82ee72b054a4

1 files changed, 133 insertions, 0 deletions

diff --git a/boehm-gc/README.amiga b/boehm-gc/README.amiga
new file mode 100644
index 00000000000..865642be4b4
--- /dev/null
+++ b/boehm-gc/README.amiga
@@ -0,0 +1,133 @@
+
+===========================================================================
+			   Michel Schinz's notes
+===========================================================================
+WHO DID WHAT
+
+The original Amiga port was made by Jesper Peterson. I (Michel Schinz)
+modified it slightly to reflect the changes made in the new official
+distributions, and to take advantage of the new SAS/C 6.x features. I also
+created a makefile to compile the "cord" package (see the cord
+subdirectory).
+
+TECHNICAL NOTES
+
+In addition to Jesper's notes, I have the following to say:
+
+- Starting with version 4.3, gctest checks to see if the code segment is
+  added to the root set or not, and complains if it is. Previous versions
+  of this Amiga port added the code segment to the root set, so I tried to
+  fix that. The only problem is that, as far as I know, it is impossible to
+  know which segments are code segments and which are data segments (there
+  are indeed solutions to this problem, like scanning the program on disk
+  or patch the LoadSeg functions, but they are rather complicated). The
+  solution I have chosen (see os_dep.c) is to test whether the program
+  counter is in the segment we are about to add to the root set, and if it
+  is, to skip the segment. The problems are that this solution is rather
+  awkward and that it works only for one code segment. This means that if
+  your program has more than one code segment, all of them but one will be
+  added to the root set. This isn't a big problem in fact, since the
+  collector will continue to work correctly, but it may be slower.
+
+  Anyway, the code which decides whether to skip a segment or not can be
+  removed simply by not defining AMIGA_SKIP_SEG. But notice that if you do
+  so, gctest will complain (it will say that "GC_is_visible produced wrong
+  failure indication"). However, it may be useful if you happen to have
+  pointers stored in a code segment (you really shouldn't).
+
+  If anyone has a good solution to the problem of finding, when a program
+  is loaded in memory, whether a segment is a code or a data segment,
+  please let me know.
+
+PROBLEMS
+
+If you have any problem with this version, please contact me at
+schinz@alphanet.ch (but do *not* send long files, since we pay for
+every mail!).
+
+===========================================================================
+			  Jesper Peterson's notes
+===========================================================================
+
+ADDITIONAL NOTES FOR AMIGA PORT
+
+These notes assume some familiarity with Amiga internals.
+
+WHY I PORTED TO THE AMIGA
+
+The sole reason why I made this port was as a first step in getting
+the Sather(*) language on the Amiga. A port of this language will
+be done as soon as the Sather 1.0 sources are made available to me.
+Given this motivation, the garbage collection (GC) port is rather
+minimal.
+
+(*) For information on Sather read the comp.lang.sather newsgroup.
+
+LIMITATIONS
+
+This port assumes that the startup code linked with target programs
+is that supplied with SAS/C versions 6.0 or later. This allows
+assumptions to be made about where to find the stack base pointer
+and data segments when programs are run from WorkBench, as opposed
+to running from the CLI. The compiler dependent code is all in the
+GC_get_stack_base() and GC_register_data_segments() functions, but
+may spread as I add Amiga specific features.
+
+Given that SAS/C was assumed, the port is set up to be built with
+"smake" using the "SMakefile". Compiler options in "SCoptions" can
+be set with "scopts" program. Both "smake" and "scopts" are part of
+the SAS/C commercial development system.
+
+In keeping with the porting philosophy outlined above, this port
+will not behave well with Amiga specific code. Especially not inter-
+process comms via messages, and setting up public structures like
+Intuition objects or anything else in the system lists. For the
+time being the use of this library is limited to single threaded
+ANSI/POSIX  compliant or near-complient code. (ie. Stick to stdio
+for now). Given this limitation there is currently no mechanism for
+allocating "CHIP" or "PUBLIC" memory under the garbage collector.
+I'll add this after giving it considerable thought. The major
+problem is the entire physical address space may have to me scanned,
+since there is no telling who we may have passed memory to.
+
+If you allocate your own stack in client code, you will have to
+assign the pointer plus stack size to GC_stackbottom.
+
+The initial stack size of the target program can be compiled in by
+setting the __stack symbol (see SAS documentaion). It can be over-
+ridden from the CLI by running the AmigaDOS "stack" program, or from
+the WorkBench by setting the stack size in the tool types window.
+
+SAS/C COMPILER OPTIONS (SCoptions)
+
+You may wish to check the "CPU" code option is appropriate for your
+intended target system.
+
+Under no circumstances set the "StackExtend" code option in either
+compiling the library or *ANY* client code.
+
+All benign compiler warnings have been suppressed. These mainly
+involve lack of prototypes in the code, and dead assignments
+detected by the optimizer.
+
+THE GOOD NEWS
+
+The library as it stands is compatible with the GigaMem commercial
+virtual memory software, and probably similar PD software.
+
+The performance of "gctest" on an Amiga 2630 (68030 @ 25Mhz)
+compares favourably with an HP9000 with similar architecture (a 325
+with a 68030 I think).
+
+-----------------------------------------------------------------------
+
+The Amiga port has been brought to you by:
+
+Jesper Peterson.
+
+jep@mtiame.mtia.oz.au		(preferred, but 1 week turnaround)
+jep@orca1.vic.design.telecom.au (that's orca<one>, 1 day turnaround)
+
+At least one of these addresses should be around for a while, even
+though I don't work for either of the companies involved.
+