Annotation of OpenXM_contrib/gc/README.amiga, Revision 1.1.1.1
1.1 maekawa 1:
2: ===========================================================================
3: Michel Schinz's notes
4: ===========================================================================
5: WHO DID WHAT
6:
7: The original Amiga port was made by Jesper Peterson. I (Michel Schinz)
8: modified it slightly to reflect the changes made in the new official
9: distributions, and to take advantage of the new SAS/C 6.x features. I also
10: created a makefile to compile the "cord" package (see the cord
11: subdirectory).
12:
13: TECHNICAL NOTES
14:
15: In addition to Jesper's notes, I have the following to say:
16:
17: - Starting with version 4.3, gctest checks to see if the code segment is
18: added to the root set or not, and complains if it is. Previous versions
19: of this Amiga port added the code segment to the root set, so I tried to
20: fix that. The only problem is that, as far as I know, it is impossible to
21: know which segments are code segments and which are data segments (there
22: are indeed solutions to this problem, like scanning the program on disk
23: or patch the LoadSeg functions, but they are rather complicated). The
24: solution I have chosen (see os_dep.c) is to test whether the program
25: counter is in the segment we are about to add to the root set, and if it
26: is, to skip the segment. The problems are that this solution is rather
27: awkward and that it works only for one code segment. This means that if
28: your program has more than one code segment, all of them but one will be
29: added to the root set. This isn't a big problem in fact, since the
30: collector will continue to work correctly, but it may be slower.
31:
32: Anyway, the code which decides whether to skip a segment or not can be
33: removed simply by not defining AMIGA_SKIP_SEG. But notice that if you do
34: so, gctest will complain (it will say that "GC_is_visible produced wrong
35: failure indication"). However, it may be useful if you happen to have
36: pointers stored in a code segment (you really shouldn't).
37:
38: If anyone has a good solution to the problem of finding, when a program
39: is loaded in memory, whether a segment is a code or a data segment,
40: please let me know.
41:
42: PROBLEMS
43:
44: If you have any problem with this version, please contact me at
45: schinz@alphanet.ch (but do *not* send long files, since we pay for
46: every mail!).
47:
48: ===========================================================================
49: Jesper Peterson's notes
50: ===========================================================================
51:
52: ADDITIONAL NOTES FOR AMIGA PORT
53:
54: These notes assume some familiarity with Amiga internals.
55:
56: WHY I PORTED TO THE AMIGA
57:
58: The sole reason why I made this port was as a first step in getting
59: the Sather(*) language on the Amiga. A port of this language will
60: be done as soon as the Sather 1.0 sources are made available to me.
61: Given this motivation, the garbage collection (GC) port is rather
62: minimal.
63:
64: (*) For information on Sather read the comp.lang.sather newsgroup.
65:
66: LIMITATIONS
67:
68: This port assumes that the startup code linked with target programs
69: is that supplied with SAS/C versions 6.0 or later. This allows
70: assumptions to be made about where to find the stack base pointer
71: and data segments when programs are run from WorkBench, as opposed
72: to running from the CLI. The compiler dependent code is all in the
73: GC_get_stack_base() and GC_register_data_segments() functions, but
74: may spread as I add Amiga specific features.
75:
76: Given that SAS/C was assumed, the port is set up to be built with
77: "smake" using the "SMakefile". Compiler options in "SCoptions" can
78: be set with "scopts" program. Both "smake" and "scopts" are part of
79: the SAS/C commercial development system.
80:
81: In keeping with the porting philosophy outlined above, this port
82: will not behave well with Amiga specific code. Especially not inter-
83: process comms via messages, and setting up public structures like
84: Intuition objects or anything else in the system lists. For the
85: time being the use of this library is limited to single threaded
86: ANSI/POSIX compliant or near-complient code. (ie. Stick to stdio
87: for now). Given this limitation there is currently no mechanism for
88: allocating "CHIP" or "PUBLIC" memory under the garbage collector.
89: I'll add this after giving it considerable thought. The major
90: problem is the entire physical address space may have to me scanned,
91: since there is no telling who we may have passed memory to.
92:
93: If you allocate your own stack in client code, you will have to
94: assign the pointer plus stack size to GC_stackbottom.
95:
96: The initial stack size of the target program can be compiled in by
97: setting the __stack symbol (see SAS documentaion). It can be over-
98: ridden from the CLI by running the AmigaDOS "stack" program, or from
99: the WorkBench by setting the stack size in the tool types window.
100:
101: SAS/C COMPILER OPTIONS (SCoptions)
102:
103: You may wish to check the "CPU" code option is appropriate for your
104: intended target system.
105:
106: Under no circumstances set the "StackExtend" code option in either
107: compiling the library or *ANY* client code.
108:
109: All benign compiler warnings have been suppressed. These mainly
110: involve lack of prototypes in the code, and dead assignments
111: detected by the optimizer.
112:
113: THE GOOD NEWS
114:
115: The library as it stands is compatible with the GigaMem commercial
116: virtual memory software, and probably similar PD software.
117:
118: The performance of "gctest" on an Amiga 2630 (68030 @ 25Mhz)
119: compares favourably with an HP9000 with similar architecture (a 325
120: with a 68030 I think).
121:
122: -----------------------------------------------------------------------
123:
124: The Amiga port has been brought to you by:
125:
126: Jesper Peterson.
127:
128: jep@mtiame.mtia.oz.au (preferred, but 1 week turnaround)
129: jep@orca1.vic.design.telecom.au (that's orca<one>, 1 day turnaround)
130:
131: At least one of these addresses should be around for a while, even
132: though I don't work for either of the companies involved.
133:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to README.amiga CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [local] / OpenXM_contrib / gc