Annotation of OpenXM_contrib2/asir2000/gc/doc/README.amiga, Revision 1.1
1.1 ! noro 1: ===========================================================================
! 2: Kjetil S. Matheussen's notes (28-11-2000)
! 3: ===========================================================================
! 4: Compiles under SAS/C again. Should allso still compile under other
! 5: amiga compilers without big changes. I haven't checked if it still
! 6: works under gcc, because I don't have gcc for amiga. But I have
! 7: updated 'Makefile', and hope it compiles fine.
! 8:
! 9:
! 10: WHATS NEW:
! 11:
! 12: 1.
! 13: Made a pretty big effort in preventing GCs allocating-functions from returning
! 14: chip-mem.
! 15:
! 16: The lower part of the new file AmigaOS.c does this in various ways, mainly by
! 17: wrapping GC_malloc, GC_malloc_atomic, GC_malloc_uncollectable,
! 18: GC_malloc_atomic_uncollectable, GC_malloc_stubborn, GC_malloc_ignore_off_page
! 19: and GC_malloc_atomic_ignore_off_page. GC_realloc is allso wrapped, but
! 20: doesn't do the same effort in preventing to return chip-mem.
! 21: Other allocating-functions (f.ex. GC_*_typed_) can probably be
! 22: used without any problems, but beware that the warn hook will not be called.
! 23: In case of problems, don't define GC_AMIGA_FASTALLOC.
! 24:
! 25: Programs using more time actually using the memory allocated
! 26: (instead of just allocate and free rapidly) have
! 27: the most to earn on this, but even gctest now normally runs twice
! 28: as fast and uses less memory, on my poor 8MB machine.
! 29:
! 30: The changes have only effect when there is no more
! 31: fast-mem left. But with the way GC works, it
! 32: could happen quite often. Beware that an atexit handler had to be added,
! 33: so using the abort() function will make a big memory-loss.
! 34: If you absolutely must call abort() instead of exit(), try calling
! 35: the GC_amiga_free_all_mem function before abort().
! 36:
! 37: New amiga-spesific compilation flags:
! 38:
! 39: GC_AMIGA_FASTALLOC - By NOT defining this option, GC will work like before,
! 40: it will not try to force fast-mem out of the OS, and
! 41: it will use normal calloc for allocation, and the rest
! 42: of the following flags will have no effect.
! 43:
! 44: GC_AMIGA_ONLYFAST - Makes GC never to return chip-mem. GC_AMIGA_RETRY have
! 45: no effect if this flag is set.
! 46:
! 47: GC_AMIGA_GC - If gc returns NULL, do a GC_gcollect, and try again. This
! 48: usually is a success with the standard GC configuration.
! 49: It is allso the most important flag to set to prevent
! 50: GC from returning chip-mem. Beware that it slows down a lot
! 51: when a program is rapidly allocating/deallocating when
! 52: theres either very little fast-memory left or verly little
! 53: chip-memory left. Its not a very common situation, but gctest
! 54: sometimes (very rare) use many minutes because of this.
! 55:
! 56: GC_AMIGA_RETRY - If gc succeed allocating memory, but it is chip-mem,
! 57: try again and see if it is fast-mem. Most of the time,
! 58: it will actually return fast-mem for the second try.
! 59: I have set max number of retries to 9 or size/5000. You
! 60: can change this if you like. (see GC_amiga_rec_alloc())
! 61:
! 62: GC_AMIGA_PRINTSTATS - Gather some statistics during the execution of a
! 63: program, and prints out the info when the atexit-handler
! 64: is called.
! 65:
! 66: My reccomendation is to set all this flags, except GC_AMIGA_PRINTSTATS and
! 67: GC_AMIGA_ONLYFAST.
! 68:
! 69: If your program demands high response-time, you should
! 70: not define GC_AMIGA_GC, and possible allso define GC_AMIGA_ONLYFAST.
! 71: GC_AMIGA_RETRY does not seem to slow down much.
! 72:
! 73: Allso, when compiling up programs, and GC_AMIGA_FASTALLOC was not defined when
! 74: compilling gc, you can define GC_AMIGA_MAKINGLIB to avoid having these allocation-
! 75: functions wrapped. (see gc.h)
! 76:
! 77: Note that GC_realloc must not be called before any of
! 78: the other above mentioned allocating-functions have been called. (shouldn't be
! 79: any programs doing so either, I hope).
! 80:
! 81: Another note. The allocation-function is wrapped when defining
! 82: GC_AMIGA_FASTALLOC by letting the function go thru the new
! 83: GC_amiga_allocwrapper_do function-pointer (see gc.h). Means that
! 84: sending function-pointers, such as GC_malloc, GC_malloc_atomic, etc.,
! 85: for later to be called like f.ex this, (*GC_malloc_functionpointer)(size),
! 86: will not wrap the function. This is normally not a big problem, unless
! 87: all allocation function is called like this, which will cause the
! 88: atexit un-allocating function never to be called. Then you either
! 89: have to manually add the atexit handler, or call the allocation-
! 90: functions function-pointer functions like this;
! 91: (*GC_amiga_allocwrapper_do)(size,GC_malloc_functionpointer).
! 92: There are probably better ways this problem could be handled, unfortunately,
! 93: I didn't find any without rewriting or replacing a lot of the GC-code, which
! 94: I really didn't want to. (Making new GC_malloc_* functions, and just
! 95: define f.ex GC_malloc as GC_amiga_malloc should allso work).
! 96:
! 97:
! 98: New amiga-spesific function:
! 99:
! 100: void GC_amiga_set_toany(void (*func)(void));
! 101:
! 102: 'func' is a function that will be called right before gc has to change
! 103: allocation-method from MEMF_FAST to MEMF_ANY. Ie. when it is likely
! 104: it will return chip-mem.
! 105:
! 106:
! 107: 2. A few small compiler-spesific additions to make it compile with SAS/C again.
! 108:
! 109: 3. Updated and rewritten the smakefile, so that it works again and that
! 110: the "unnecesarry" 'SCOPTIONS' files could be removed. Allso included
! 111: the cord-smakefile stuff in the main smakefile, so that the cord smakefile
! 112: could be removed too. By writing smake -f Smakefile.smk, both gc.lib and
! 113: cord.lib will be made.
! 114:
! 115:
! 116:
! 117: STILL MISSING:
! 118:
! 119: Programs can not be started from workbench, at least not for SAS/C. (Martin
! 120: Tauchmanns note about that it now works with workbench is definitely wrong
! 121: when concerning SAS/C). I guess it works if you use the old "#if 0'ed"-code,
! 122: but I haven't tested it. I think the reason for MT to replace the
! 123: "#if 0'ed"-code was only because it was a bit to SAS/C-spesific. But I
! 124: don't know. An iconx-script solves this problem anyway.
! 125:
! 126:
! 127: BEWARE!
! 128:
! 129: -To run gctest, set the stack to around 200000 bytes first.
! 130: -SAS/C-spesific: cord will crash if you compile gc.lib with
! 131: either parm=reg or parm=both. (missing legal prototypes for
! 132: function-pointers someplace is the reason I guess.).
! 133:
! 134:
! 135: tested with software: Radium, http://www.stud.ifi.uio.no/~ksvalast/radium/
! 136:
! 137: tested with hardware: MC68060
! 138:
! 139:
! 140: -ksvalast@ifi.uio.no
! 141:
! 142:
! 143: ===========================================================================
! 144: Martin Tauchmann's notes (1-Apr-99)
! 145: ===========================================================================
! 146:
! 147: 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/>
! 148: Modify the `Makefile`
! 149: CC=cc $(ABI_FLAG)
! 150: to
! 151: CC=gcc $(ABI_FLAG)
! 152:
! 153: TECHNICAL NOTES
! 154:
! 155: - `GC_get_stack_base()`, `GC_register_data_segments()` works now with every
! 156: C compiler; also Workbench.
! 157:
! 158: - Removed AMIGA_SKIP_SEG, but the Code-Segment must not be scanned by GC.
! 159:
! 160:
! 161: PROBLEMS
! 162: - When the Linker, does`t merge all Code-Segments to an single one. LD of GCC
! 163: do it always.
! 164:
! 165: - With ixemul.library V47.3, when an GC program launched from another program
! 166: (example: `Make` or `if_mach M68K AMIGA gctest`), `GC_register_data_segments()`
! 167: found the Segment-List of the caller program.
! 168: Can be fixed, if the run-time initialization code (for C programs, usually *crt0*)
! 169: support `__data` and `__bss`.
! 170:
! 171: - PowerPC Amiga currently not supported.
! 172:
! 173: - Dynamic libraries (dyn_load.c) not supported.
! 174:
! 175:
! 176: TESTED WITH SOFTWARE
! 177:
! 178: `Optimized Oberon 2 C` (oo2c) <http://cognac.informatik.uni-kl.de/download/index.html>
! 179:
! 180:
! 181: TESTED WITH HARDWARE
! 182:
! 183: MC68030
! 184:
! 185:
! 186: CONTACT
! 187:
! 188: Please, contact me at <martintauchmann@bigfoot.com>, when you change the
! 189: Amiga port. <http://martintauchmann.home.pages.de>
! 190:
! 191: ===========================================================================
! 192: Michel Schinz's notes
! 193: ===========================================================================
! 194: WHO DID WHAT
! 195:
! 196: The original Amiga port was made by Jesper Peterson. I (Michel Schinz)
! 197: modified it slightly to reflect the changes made in the new official
! 198: distributions, and to take advantage of the new SAS/C 6.x features. I also
! 199: created a makefile to compile the "cord" package (see the cord
! 200: subdirectory).
! 201:
! 202: TECHNICAL NOTES
! 203:
! 204: In addition to Jesper's notes, I have the following to say:
! 205:
! 206: - Starting with version 4.3, gctest checks to see if the code segment is
! 207: added to the root set or not, and complains if it is. Previous versions
! 208: of this Amiga port added the code segment to the root set, so I tried to
! 209: fix that. The only problem is that, as far as I know, it is impossible to
! 210: know which segments are code segments and which are data segments (there
! 211: are indeed solutions to this problem, like scanning the program on disk
! 212: or patch the LoadSeg functions, but they are rather complicated). The
! 213: solution I have chosen (see os_dep.c) is to test whether the program
! 214: counter is in the segment we are about to add to the root set, and if it
! 215: is, to skip the segment. The problems are that this solution is rather
! 216: awkward and that it works only for one code segment. This means that if
! 217: your program has more than one code segment, all of them but one will be
! 218: added to the root set. This isn't a big problem in fact, since the
! 219: collector will continue to work correctly, but it may be slower.
! 220:
! 221: Anyway, the code which decides whether to skip a segment or not can be
! 222: removed simply by not defining AMIGA_SKIP_SEG. But notice that if you do
! 223: so, gctest will complain (it will say that "GC_is_visible produced wrong
! 224: failure indication"). However, it may be useful if you happen to have
! 225: pointers stored in a code segment (you really shouldn't).
! 226:
! 227: If anyone has a good solution to the problem of finding, when a program
! 228: is loaded in memory, whether a segment is a code or a data segment,
! 229: please let me know.
! 230:
! 231: PROBLEMS
! 232:
! 233: If you have any problem with this version, please contact me at
! 234: schinz@alphanet.ch (but do *not* send long files, since we pay for
! 235: every mail!).
! 236:
! 237: ===========================================================================
! 238: Jesper Peterson's notes
! 239: ===========================================================================
! 240:
! 241: ADDITIONAL NOTES FOR AMIGA PORT
! 242:
! 243: These notes assume some familiarity with Amiga internals.
! 244:
! 245: WHY I PORTED TO THE AMIGA
! 246:
! 247: The sole reason why I made this port was as a first step in getting
! 248: the Sather(*) language on the Amiga. A port of this language will
! 249: be done as soon as the Sather 1.0 sources are made available to me.
! 250: Given this motivation, the garbage collection (GC) port is rather
! 251: minimal.
! 252:
! 253: (*) For information on Sather read the comp.lang.sather newsgroup.
! 254:
! 255: LIMITATIONS
! 256:
! 257: This port assumes that the startup code linked with target programs
! 258: is that supplied with SAS/C versions 6.0 or later. This allows
! 259: assumptions to be made about where to find the stack base pointer
! 260: and data segments when programs are run from WorkBench, as opposed
! 261: to running from the CLI. The compiler dependent code is all in the
! 262: GC_get_stack_base() and GC_register_data_segments() functions, but
! 263: may spread as I add Amiga specific features.
! 264:
! 265: Given that SAS/C was assumed, the port is set up to be built with
! 266: "smake" using the "SMakefile". Compiler options in "SCoptions" can
! 267: be set with "scopts" program. Both "smake" and "scopts" are part of
! 268: the SAS/C commercial development system.
! 269:
! 270: In keeping with the porting philosophy outlined above, this port
! 271: will not behave well with Amiga specific code. Especially not inter-
! 272: process comms via messages, and setting up public structures like
! 273: Intuition objects or anything else in the system lists. For the
! 274: time being the use of this library is limited to single threaded
! 275: ANSI/POSIX compliant or near-complient code. (ie. Stick to stdio
! 276: for now). Given this limitation there is currently no mechanism for
! 277: allocating "CHIP" or "PUBLIC" memory under the garbage collector.
! 278: I'll add this after giving it considerable thought. The major
! 279: problem is the entire physical address space may have to me scanned,
! 280: since there is no telling who we may have passed memory to.
! 281:
! 282: If you allocate your own stack in client code, you will have to
! 283: assign the pointer plus stack size to GC_stackbottom.
! 284:
! 285: The initial stack size of the target program can be compiled in by
! 286: setting the __stack symbol (see SAS documentaion). It can be over-
! 287: ridden from the CLI by running the AmigaDOS "stack" program, or from
! 288: the WorkBench by setting the stack size in the tool types window.
! 289:
! 290: SAS/C COMPILER OPTIONS (SCoptions)
! 291:
! 292: You may wish to check the "CPU" code option is appropriate for your
! 293: intended target system.
! 294:
! 295: Under no circumstances set the "StackExtend" code option in either
! 296: compiling the library or *ANY* client code.
! 297:
! 298: All benign compiler warnings have been suppressed. These mainly
! 299: involve lack of prototypes in the code, and dead assignments
! 300: detected by the optimizer.
! 301:
! 302: THE GOOD NEWS
! 303:
! 304: The library as it stands is compatible with the GigaMem commercial
! 305: virtual memory software, and probably similar PD software.
! 306:
! 307: The performance of "gctest" on an Amiga 2630 (68030 @ 25Mhz)
! 308: compares favourably with an HP9000 with similar architecture (a 325
! 309: with a 68030 I think).
! 310:
! 311: -----------------------------------------------------------------------
! 312:
! 313: The Amiga port has been brought to you by:
! 314:
! 315: Jesper Peterson.
! 316:
! 317: jep@mtiame.mtia.oz.au (preferred, but 1 week turnaround)
! 318: jep@orca1.vic.design.telecom.au (that's orca<one>, 1 day turnaround)
! 319:
! 320: At least one of these addresses should be around for a while, even
! 321: though I don't work for either of the companies involved.
! 322:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to README.amiga CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [local] / OpenXM_contrib2 / asir2000 / gc / doc