===========================================================================

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.