diff options
Diffstat (limited to 'gc/README.amiga')
| -rw-r--r-- | gc/README.amiga | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/gc/README.amiga b/gc/README.amiga new file mode 100644 index 0000000..47b1588 --- /dev/null +++ b/gc/README.amiga @@ -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. + |