Annotation of OpenXM_contrib2/asir2000/gc/README.amiga, Revision 1.1
1.1 ! noro 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:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>