- Nov 25, 1997
-
-
dtc authored
-
dtc authored
-
dtc authored
tested in the experimental code and works on both FreeBSD and Linux. Plus a few improvements to the interrupt safety for the x86 port.
-
dtc authored
of no utility and wasn't even being maintained thoroughly. Can now use pseudo atomic in C code. All interrupt contexts are saved, even those that occur when running foreign C code; this may be necessary for reliable stack parsing on some operating systems, e.g. Linux. When the pending interrupt from a GC trigger is processed by interrupt_handle_pending, any other accumulated pending interrupt is also processed even if *interrupts-enabled* is false, breaking the behaviour of the *interrupts-enabled* flag. The best way around this for the x86 port is to call maybe-gc directly from the allocation routines; remove the recently introduced function set_maybe_gc_pending which also had other problems. Note this problem will likely occur on the other ports.
-
pw authored
-
- Nov 23, 1997
- Nov 22, 1997
-
-
dtc authored
calling interrupt_handle_now, else when interrupt_handle_now resets signal mask to that in the signal context it will be masking the interrupts where the intention is to re-enable them. This caused the multi-processing to get stuck working on a particular process with the signals masked. Change may have another benefit: the pending_mask is no longer needed so there is no danger from recursive pending interrupts.
-
- Nov 21, 1997
-
-
dtc authored
RT) so this is set for the first object allocation - help some checks on the x86 port.
-
dtc authored
interrupt_handle_now until after the context SAP object is allocated so that this allocation is not interrupted. May still be some lossage on the non-x86 ports as the GC will not see the object on the C stack until it is moved onto the control stack by the call into lisp.
-
dtc authored
the breakpoint functions have allocated the context SAP object so this allocation is performed without interrupt.
-
- Nov 19, 1997
-
-
dtc authored
GC when it reaches its trigger within pseudo atomic so that maybe_gc is called at the end of pseudo atomic.
-
- Nov 18, 1997
- Nov 17, 1997
-
-
dtc authored
when there is no scavenger hook support (for CGC).
-
- Nov 08, 1997
-
-
dtc authored
* Support for moving code objects on the x86 port. Needed by the GENCGC version which places code objects in the dynamic space which are moved to the read-only space by purify. * Scavenger hook support; available with GENCGC. * Conditional support for scavenging the read-only space when the *scavenge-read-only-space* static symbol is defined. This is currently used with the x86 GENCGC version so that new-genesis can place code objects in the read-only space. * Hooks to GENCGC.
-
dtc authored
-
- Nov 04, 1997
-
-
dtc authored
common binaries to be run on both: * The immediate-stack storage class has been removed, this is unnecessary as the descriptor-stack SC can be used. It may have once been part of some GC stragety to reduce the number of stack slots that needed to be noted for a GC. * The object allocation has been abstracted and cleaned up. This should produce slightly faster smaller code with CGC, and can be compiled to support inline allocation with GENCGC. CGC compiled code will run under GENCGC, and GENCGC binaries that don't use inline allocation will run under CGC. * A random hash is now placed in the unused symbol object slot (the symbol-hash slot). This saves flushing the info cache at each GC, and may have other uses for symbol based hash tables. Should help MP safety. * Common set of static symbols used by both CGC and GENCGC. * Corrections to the stack-ref VOP; now returns lisp objects not unsigned numbers. Required some patches to debug-int. * Inline unsigned/signed byte 32 to bignum allocation enabled. * Support for the x86 xadd instruction applied to instance slot and symbol values - may be handy for some MP code. * Bump up the FASL file version from 1 to 2.
-
- Nov 02, 1997
-
-
dtc authored
-
- Nov 01, 1997
-
-
dtc authored
types. Adds storage classes to the backend for these so they can be stored in registers or on the stack without consing; new primitive types etc. Also adds (simple-array (complex {single,double}-float)) array types to avoid consing and speed vectors operations. All these changes are conditional on the :complex-float feature. More work is needed to exploit these changes: improving the type dispatch in the various function; maybe compiler transforms or more VOPs to handle common functions inline.
-
- Oct 25, 1997
-
-
pw authored
Ok, here are the updated patches to make the same cmucl lisp.core work across OS versions under irix, still by making tzname resolved at runtime (on irix only).
-
- Oct 02, 1997
- Sep 24, 1997
-
-
dtc authored
in the *control-stacks* vector.
-
- Sep 13, 1997
-
-
dtc authored
present in Red Hat Linux v.4.1 which broke the linking.
-
- Sep 08, 1997
-
-
dtc authored
-
- Sep 07, 1997
-
-
dtc authored
registers off the stack to empty it rather than re-initialising the whole NPX state. This has the advantage that the flagged exceptions are preserved (they were just being flushed), and it also a little quicker.
-
- Sep 04, 1997
-
-
dtc authored
-
- Aug 26, 1997
-
-
dtc authored
a throw_to_monitor from continue_p which causes objects to not be printed. From Timothy Miller.
-
- Aug 23, 1997
-
-
pw authored
foreign functions taking floating-point arguments after integer arguments but before the fourth argument (more or less; mips has unusual C calling conventions), and making cmucl work on IRIX 6.2 on the Onyx (where the system page size has changed). I've included the patches below, along with some discussion of the changes and a couple of problems with cmucl's interaction with dynamic loading. Also, there's a misc change to make ioctls work (I'm not sure for what version the released code worked, but it doesn't work on anything I have). The patches do not fix the R10000; cmucl continues to not work on it (O2 and Octane). The fixes make cmucl on the sgi use shared libraries so it can use dlopen et al in load-foreign; this is based on the solaris implementation. The problem with this is that the addresses of foreign variables are included directly in the dumped lisp image (without relocation on loading), which might result in a problem if cmucl is run with newer shared libraries than those it was compiled and dumped with. As far as I can tell, for the SGI at least, this does not affect function calls because the addresses used (and included in the dumped image) are those of stub routines that jump to the actual routines, thus are located in the executable proper rather than in the shared libraries, and so shouldn't be changed by a new version of the shared library. Unfortunately, this is not the case for global variables. Fortunately, there appear to only be two foreign variables used by cmucl in any of its system code winding up in the dumped image: errno and tzname. Apparently, Solaris relocates data references in dsos to match the program, while IRIX relocates data references in the program to match the dso. Thus, on Solaris, you don't need to do anything special for cmucl to work with a newer runtime libc, but on IRIX it gets the wrong value of errno and tzname. Unfortunately, the address of errno is different between irix 6.2, 6.3, and 6.4 (all of which we have to have because SGI doesn't have a single cross-platform OS version yet), which would require a different lisp.core for each machine (you just need to run mk-lisp, not recompile) if it weren't for the hack below. But fortunately again, a lisp compiled for one version seems to be able to run on another version well enough to generate the new lisp.core (presumably the worst that would happen is that error messages could be confusing). It would be really nice to avoid this problem. Perhaps some kind of relocation table could be added to the dumped image format? I don't know enough about the system to know how possible or ridiculous that suggestion is, unfortunately. Is the Solaris behavior guaranteed to be the same in future releases? If not, or if any other platforms have the irix behavior, this might become a more general problem. In the meantime, we use a hack: we *define* errno in undefineds.c rather than just referencing it; this results in warnings from the linker, but it resolves the conflict in favor of the definition in the program, relocating libc to match, thus fixing this problem for errno. The other global variables, tzname et al, can't be fixed this way as easily because they're listed as weak symbols, essentially aliases for the real symbol, so redefining them wouldn't cause libc to reference the new version. Thus, as long as you don't use tzname, there's no problem right now (although there may be if any other library global variables are used in cmucl in the future). The definition of tzname is in a progn preceeded by a comment which says not to use it, so hopefully it's not in fact used and therefore not a problem. These patches have been tested on an R5000 O2 running irix 6.3 and a dual R4400 Onyx running irix 6.2. A previous version of these patches (for 17f) was tested on the onyx when it was running 5.3 (I think, maybe 5.2). The patches here are from the main branch of the CVS tar as of August 13. Incidentally, it was quite painful figuring out how to compile and bootstrap the current sources under the distributed irix 18a binary, even without trying :new-random or :signed-array (which I haven't tried to do yet); it might be nice to put a newer binary up...
-
- Jun 27, 1997
-
-
pw authored
-
- Jun 18, 1997
- Jun 07, 1997
- May 05, 1997
-
-
dtc authored
which are not yet supported; hack for errno; signed-array support.
-
- Apr 21, 1997
-
-
dtc authored
required on the MIPS port where the NFP is a descriptor reg. Correct fix for the sparc is to not have the NFP defined as a BOXED register, it's defined as a non-descriptor register in compiler/sparc/vm.lisp and the GC was scavenging it and picking up bad pointers.
-
- Apr 20, 1997
-
-
dtc authored
-
- Apr 19, 1997
-
-
pw authored
-
- Apr 18, 1997
-
-
dtc authored
-