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

Annotation of OpenXM_contrib2/asir2000/gc5.3/README.amiga, Revision 1.1.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>