1=========================================================================== 2 Kjetil S. Matheussen's notes (28-11-2000) 3=========================================================================== 4Compiles under SAS/C again. Should allso still compile under other 5amiga compilers without big changes. I haven't checked if it still 6works under gcc, because I don't have gcc for amiga. But I have 7updated 'Makefile', and hope it compiles fine. 8 9 10WHATS NEW: 11 121. 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 1072. A few small compiler-spesific additions to make it compile with SAS/C again. 108 1093. 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 117STILL MISSING: 118 119Programs can not be started from workbench, at least not for SAS/C. (Martin 120Tauchmanns note about that it now works with workbench is definitely wrong 121when concerning SAS/C). I guess it works if you use the old "#if 0'ed"-code, 122but 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 124don't know. An iconx-script solves this problem anyway. 125 126 127BEWARE! 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 135tested with software: Radium, http://www.stud.ifi.uio.no/~ksvalast/radium/ 136 137tested with hardware: MC68060 138 139 140-ksvalast@ifi.uio.no 141 142 143=========================================================================== 144 Martin Tauchmann's notes (1-Apr-99) 145=========================================================================== 146 147Works now, also with the GNU-C compiler V2.7.2.1. <ftp://ftp.unina.it/pub/amiga/geekgadgets/amiga/m68k/snapshots/971125/amiga-bin/> 148Modify the `Makefile` 149CC=cc $(ABI_FLAG) 150to 151CC=gcc $(ABI_FLAG) 152 153TECHNICAL 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 161PROBLEMS 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 176TESTED WITH SOFTWARE 177 178`Optimized Oberon 2 C` (oo2c) <http://cognac.informatik.uni-kl.de/download/index.html> 179 180 181TESTED WITH HARDWARE 182 183MC68030 184 185 186CONTACT 187 188Please, contact me at <martintauchmann@bigfoot.com>, when you change the 189Amiga port. <http://martintauchmann.home.pages.de> 190 191=========================================================================== 192 Michel Schinz's notes 193=========================================================================== 194WHO DID WHAT 195 196The original Amiga port was made by Jesper Peterson. I (Michel Schinz) 197modified it slightly to reflect the changes made in the new official 198distributions, and to take advantage of the new SAS/C 6.x features. I also 199created a makefile to compile the "cord" package (see the cord 200subdirectory). 201 202TECHNICAL NOTES 203 204In 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 231PROBLEMS 232 233If you have any problem with this version, please contact me at 234schinz@alphanet.ch (but do *not* send long files, since we pay for 235every mail!). 236 237=========================================================================== 238 Jesper Peterson's notes 239=========================================================================== 240 241ADDITIONAL NOTES FOR AMIGA PORT 242 243These notes assume some familiarity with Amiga internals. 244 245WHY I PORTED TO THE AMIGA 246 247The sole reason why I made this port was as a first step in getting 248the Sather(*) language on the Amiga. A port of this language will 249be done as soon as the Sather 1.0 sources are made available to me. 250Given this motivation, the garbage collection (GC) port is rather 251minimal. 252 253(*) For information on Sather read the comp.lang.sather newsgroup. 254 255LIMITATIONS 256 257This port assumes that the startup code linked with target programs 258is that supplied with SAS/C versions 6.0 or later. This allows 259assumptions to be made about where to find the stack base pointer 260and data segments when programs are run from WorkBench, as opposed 261to running from the CLI. The compiler dependent code is all in the 262GC_get_stack_base() and GC_register_data_segments() functions, but 263may spread as I add Amiga specific features. 264 265Given that SAS/C was assumed, the port is set up to be built with 266"smake" using the "SMakefile". Compiler options in "SCoptions" can 267be set with "scopts" program. Both "smake" and "scopts" are part of 268the SAS/C commercial development system. 269 270In keeping with the porting philosophy outlined above, this port 271will not behave well with Amiga specific code. Especially not inter- 272process comms via messages, and setting up public structures like 273Intuition objects or anything else in the system lists. For the 274time being the use of this library is limited to single threaded 275ANSI/POSIX compliant or near-complient code. (ie. Stick to stdio 276for now). Given this limitation there is currently no mechanism for 277allocating "CHIP" or "PUBLIC" memory under the garbage collector. 278I'll add this after giving it considerable thought. The major 279problem is the entire physical address space may have to me scanned, 280since there is no telling who we may have passed memory to. 281 282If you allocate your own stack in client code, you will have to 283assign the pointer plus stack size to GC_stackbottom. 284 285The initial stack size of the target program can be compiled in by 286setting the __stack symbol (see SAS documentaion). It can be over- 287ridden from the CLI by running the AmigaDOS "stack" program, or from 288the WorkBench by setting the stack size in the tool types window. 289 290SAS/C COMPILER OPTIONS (SCoptions) 291 292You may wish to check the "CPU" code option is appropriate for your 293intended target system. 294 295Under no circumstances set the "StackExtend" code option in either 296compiling the library or *ANY* client code. 297 298All benign compiler warnings have been suppressed. These mainly 299involve lack of prototypes in the code, and dead assignments 300detected by the optimizer. 301 302THE GOOD NEWS 303 304The library as it stands is compatible with the GigaMem commercial 305virtual memory software, and probably similar PD software. 306 307The performance of "gctest" on an Amiga 2630 (68030 @ 25Mhz) 308compares favourably with an HP9000 with similar architecture (a 325 309with a 68030 I think). 310 311----------------------------------------------------------------------- 312 313The Amiga port has been brought to you by: 314 315Jesper Peterson. 316 317jep@mtiame.mtia.oz.au (preferred, but 1 week turnaround) 318jep@orca1.vic.design.telecom.au (that's orca<one>, 1 day turnaround) 319 320At least one of these addresses should be around for a while, even 321though I don't work for either of the companies involved. 322 323