134 lines
5.7 KiB
Plaintext
134 lines
5.7 KiB
Plaintext
|
|
===========================================================================
|
|
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.
|
|
|