[BACK]Return to README.amiga CVS log [TXT][DIR] Up to [local] / OpenXM_contrib2 / asir2000 / gc

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>