Updates from 0.2.1 into 0.2.1-inu-1.5release-0-2-1-inu-1-5

1 files changed, 0 insertions, 180 deletions

diff --git a/gc/README.amiga b/gc/README.amiga
deleted file mode 100644
index 47b1588..0000000
--- a/gc/README.amiga
+++ /dev/null
@@ -1,180 +0,0 @@
-===========================================================================
-			   Martin Tauchmann's notes		(1-Apr-99)
-===========================================================================
-
-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/>
-Modify the `Makefile`
-CC=cc $(ABI_FLAG)
-to
-CC=gcc $(ABI_FLAG)
-
-TECHNICAL NOTES
-
-- `GC_get_stack_base()`, `GC_register_data_segments()` works now with every
-   C compiler; also Workbench.
-
-- Removed AMIGA_SKIP_SEG, but the Code-Segment must not be scanned by GC.
-
-
-PROBLEMS
-- When the Linker, does`t merge all Code-Segments to an single one. LD of GCC
-  do it always.
-
-- With ixemul.library V47.3, when an GC program launched from another program
-  (example: `Make` or `if_mach M68K AMIGA gctest`), `GC_register_data_segments()`
-  found the Segment-List of the caller program.
-  Can be fixed, if the run-time initialization code (for C programs, usually *crt0*)
-  support `__data` and `__bss`.
-
-- PowerPC Amiga currently not supported.
-
-- Dynamic libraries (dyn_load.c) not supported.
-
-
-TESTED WITH SOFTWARE
-
-`Optimized Oberon 2 C` (oo2c) <http://cognac.informatik.uni-kl.de/download/index.html>
-
-
-TESTED WITH HARDWARE
-
-MC68030
-
-
-CONTACT
-
-Please, contact me at <martintauchmann@bigfoot.com>, when you change the
-Amiga port. <http://martintauchmann.home.pages.de>
- 
-===========================================================================
-			   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.
-