Initial revision
This commit is contained in:
Akinori Ito
180
gc/README.amiga
Normal file
180
gc/README.amiga
Normal file
@@ -0,0 +1,180 @@
|
||||
===========================================================================
|
||||
Martin Tauchmann's notes (1-Apr-99)
|
||||
===========================================================================
|
||||
|
||||
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/>
|
||||
Modify the `Makefile`
|
||||
CC=cc $(ABI_FLAG)
|
||||
to
|
||||
CC=gcc $(ABI_FLAG)
|
||||
|
||||
TECHNICAL NOTES
|
||||
|
||||
- `GC_get_stack_base()`, `GC_register_data_segments()` works now with every
|
||||
C compiler; also Workbench.
|
||||
|
||||
- Removed AMIGA_SKIP_SEG, but the Code-Segment must not be scanned by GC.
|
||||
|
||||
|
||||
PROBLEMS
|
||||
- When the Linker, does`t merge all Code-Segments to an single one. LD of GCC
|
||||
do it always.
|
||||
|
||||
- With ixemul.library V47.3, when an GC program launched from another program
|
||||
(example: `Make` or `if_mach M68K AMIGA gctest`), `GC_register_data_segments()`
|
||||
found the Segment-List of the caller program.
|
||||
Can be fixed, if the run-time initialization code (for C programs, usually *crt0*)
|
||||
support `__data` and `__bss`.
|
||||
|
||||
- PowerPC Amiga currently not supported.
|
||||
|
||||
- Dynamic libraries (dyn_load.c) not supported.
|
||||
|
||||
|
||||
TESTED WITH SOFTWARE
|
||||
|
||||
`Optimized Oberon 2 C` (oo2c) <http://cognac.informatik.uni-kl.de/download/index.html>
|
||||
|
||||
|
||||
TESTED WITH HARDWARE
|
||||
|
||||
MC68030
|
||||
|
||||
|
||||
CONTACT
|
||||
|
||||
Please, contact me at <martintauchmann@bigfoot.com>, when you change the
|
||||
Amiga port. <http://martintauchmann.home.pages.de>
|
||||
|
||||
===========================================================================
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user