diff options
Diffstat (limited to '')
| -rw-r--r-- | gc/doc/README.amiga | 322 |
1 files changed, 322 insertions, 0 deletions
diff --git a/gc/doc/README.amiga b/gc/doc/README.amiga new file mode 100644 index 0000000..730dce3 --- /dev/null +++ b/gc/doc/README.amiga @@ -0,0 +1,322 @@ +=========================================================================== + Kjetil S. Matheussen's notes (28-11-2000) +=========================================================================== +Compiles under SAS/C again. Should allso still compile under other +amiga compilers without big changes. I haven't checked if it still +works under gcc, because I don't have gcc for amiga. But I have +updated 'Makefile', and hope it compiles fine. + + +WHATS NEW: + +1. + Made a pretty big effort in preventing GCs allocating-functions from returning + chip-mem. + + The lower part of the new file AmigaOS.c does this in various ways, mainly by + wrapping GC_malloc, GC_malloc_atomic, GC_malloc_uncollectable, + GC_malloc_atomic_uncollectable, GC_malloc_stubborn, GC_malloc_ignore_off_page + and GC_malloc_atomic_ignore_off_page. GC_realloc is allso wrapped, but + doesn't do the same effort in preventing to return chip-mem. + Other allocating-functions (f.ex. GC_*_typed_) can probably be + used without any problems, but beware that the warn hook will not be called. + In case of problems, don't define GC_AMIGA_FASTALLOC. + + Programs using more time actually using the memory allocated + (instead of just allocate and free rapidly) have + the most to earn on this, but even gctest now normally runs twice + as fast and uses less memory, on my poor 8MB machine. + + The changes have only effect when there is no more + fast-mem left. But with the way GC works, it + could happen quite often. Beware that an atexit handler had to be added, + so using the abort() function will make a big memory-loss. + If you absolutely must call abort() instead of exit(), try calling + the GC_amiga_free_all_mem function before abort(). + + New amiga-spesific compilation flags: + + GC_AMIGA_FASTALLOC - By NOT defining this option, GC will work like before, + it will not try to force fast-mem out of the OS, and + it will use normal calloc for allocation, and the rest + of the following flags will have no effect. + + GC_AMIGA_ONLYFAST - Makes GC never to return chip-mem. GC_AMIGA_RETRY have + no effect if this flag is set. + + GC_AMIGA_GC - If gc returns NULL, do a GC_gcollect, and try again. This + usually is a success with the standard GC configuration. + It is allso the most important flag to set to prevent + GC from returning chip-mem. Beware that it slows down a lot + when a program is rapidly allocating/deallocating when + theres either very little fast-memory left or verly little + chip-memory left. Its not a very common situation, but gctest + sometimes (very rare) use many minutes because of this. + + GC_AMIGA_RETRY - If gc succeed allocating memory, but it is chip-mem, + try again and see if it is fast-mem. Most of the time, + it will actually return fast-mem for the second try. + I have set max number of retries to 9 or size/5000. You + can change this if you like. (see GC_amiga_rec_alloc()) + + GC_AMIGA_PRINTSTATS - Gather some statistics during the execution of a + program, and prints out the info when the atexit-handler + is called. + + My reccomendation is to set all this flags, except GC_AMIGA_PRINTSTATS and + GC_AMIGA_ONLYFAST. + + If your program demands high response-time, you should + not define GC_AMIGA_GC, and possible allso define GC_AMIGA_ONLYFAST. + GC_AMIGA_RETRY does not seem to slow down much. + + Allso, when compiling up programs, and GC_AMIGA_FASTALLOC was not defined when + compilling gc, you can define GC_AMIGA_MAKINGLIB to avoid having these allocation- + functions wrapped. (see gc.h) + + Note that GC_realloc must not be called before any of + the other above mentioned allocating-functions have been called. (shouldn't be + any programs doing so either, I hope). + + Another note. The allocation-function is wrapped when defining + GC_AMIGA_FASTALLOC by letting the function go thru the new + GC_amiga_allocwrapper_do function-pointer (see gc.h). Means that + sending function-pointers, such as GC_malloc, GC_malloc_atomic, etc., + for later to be called like f.ex this, (*GC_malloc_functionpointer)(size), + will not wrap the function. This is normally not a big problem, unless + all allocation function is called like this, which will cause the + atexit un-allocating function never to be called. Then you either + have to manually add the atexit handler, or call the allocation- + functions function-pointer functions like this; + (*GC_amiga_allocwrapper_do)(size,GC_malloc_functionpointer). + There are probably better ways this problem could be handled, unfortunately, + I didn't find any without rewriting or replacing a lot of the GC-code, which + I really didn't want to. (Making new GC_malloc_* functions, and just + define f.ex GC_malloc as GC_amiga_malloc should allso work). + + + New amiga-spesific function: + + void GC_amiga_set_toany(void (*func)(void)); + + 'func' is a function that will be called right before gc has to change + allocation-method from MEMF_FAST to MEMF_ANY. Ie. when it is likely + it will return chip-mem. + + +2. A few small compiler-spesific additions to make it compile with SAS/C again. + +3. Updated and rewritten the smakefile, so that it works again and that + the "unnecesarry" 'SCOPTIONS' files could be removed. Allso included + the cord-smakefile stuff in the main smakefile, so that the cord smakefile + could be removed too. By writing smake -f Smakefile.smk, both gc.lib and + cord.lib will be made. + + + +STILL MISSING: + +Programs can not be started from workbench, at least not for SAS/C. (Martin +Tauchmanns note about that it now works with workbench is definitely wrong +when concerning SAS/C). I guess it works if you use the old "#if 0'ed"-code, +but I haven't tested it. I think the reason for MT to replace the +"#if 0'ed"-code was only because it was a bit to SAS/C-spesific. But I +don't know. An iconx-script solves this problem anyway. + + +BEWARE! + +-To run gctest, set the stack to around 200000 bytes first. +-SAS/C-spesific: cord will crash if you compile gc.lib with + either parm=reg or parm=both. (missing legal prototypes for + function-pointers someplace is the reason I guess.). + + +tested with software: Radium, http://www.stud.ifi.uio.no/~ksvalast/radium/ + +tested with hardware: MC68060 + + +-ksvalast@ifi.uio.no + + +=========================================================================== + 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. + |