Skip to content
Snippets Groups Projects
  1. Nov 18, 1997
  2. Nov 17, 1997
  3. Nov 08, 1997
    • dtc's avatar
      * Support for the complex-float array types. · 31d977b5
      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.
      31d977b5
    • dtc's avatar
      GENCGC support. · 27ece61a
      dtc authored
      27ece61a
  4. Nov 04, 1997
    • dtc's avatar
      Merge in changes to the x86 backend from the gencgc branch, allowing · 725ab9ee
      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.
      725ab9ee
  5. Nov 02, 1997
  6. Nov 01, 1997
    • dtc's avatar
      Improved support for (complex single-float) and (complex double-float) · 4c3b1bb6
      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.
      4c3b1bb6
  7. Oct 25, 1997
    • pw's avatar
      From: Timothy Miller <tsm@cs.brown.edu> · 9a08b1c8
      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).
      9a08b1c8
  8. Oct 02, 1997
  9. Sep 24, 1997
  10. Sep 13, 1997
  11. Sep 08, 1997
  12. Sep 07, 1997
  13. Sep 04, 1997
  14. Aug 26, 1997
  15. Aug 23, 1997
    • pw's avatar
      I just finished making load-foreign work on SGIs, along with fixing calling of · efd9aa3b
      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...
      efd9aa3b
  16. Jun 27, 1997
  17. Jun 18, 1997
  18. Jun 07, 1997
  19. May 05, 1997
  20. Apr 21, 1997
    • dtc's avatar
      Backout a prior patch which skipped the scavenging of the NFP. This is · e965fc3f
      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.
      e965fc3f
  21. Apr 20, 1997
  22. Apr 19, 1997
  23. Apr 18, 1997
  24. Apr 13, 1997
  25. Apr 09, 1997
    • dtc's avatar
      New value for the :pure option of defstruct, :substructure. Purify · 3d400aaa
      dtc authored
      will place the instance in the static space but still move the
      substructure lists and arrays to the RO space. This is needed for
      compact-info environments which cache the last name in the instance
      which needs to be scavenged, but the hash arrays can still be placed
      in the RO space (the cache name was not being scavenge which could
      cause a false hit if very unlucky). Shall uses this new option in
      compiler/globaldb.lisp after people have had a chance to bootstrap in
      this new support.
      3d400aaa
  26. Apr 01, 1997
    • dtc's avatar
      Support for some specialised signed array types: (signed-byte 8), · d5d4504f
      dtc authored
      (signed-byte 16), (signed-byte 30), (signed-byte 32).  These patches
      include the general support and the x86 backend support; more to
      follow. The important changes are conditional on the :signed-array
      feature so shouldn't affect the source without this feature. This work
      has been driven by Raymond Toy.
      d5d4504f
  27. Mar 19, 1997
  28. Mar 16, 1997
  29. Mar 15, 1997
  30. Mar 10, 1997
  31. Feb 27, 1997
  32. Feb 22, 1997
    • dtc's avatar
      Use a separate stack for alien value allocation on the x86. It had · 1975d13a
      dtc authored
      been sharing the control stack with the compiler which could cause
      trouble (pushes and pops out of order, holes in arguments built up on
      the stack, exposed stack that can be written over on interrupt, etc)
      
      Assigned a static symbol, x86::*alien-stack*, and by default set it to
      the old C stack. A program many rebind this if it needs more room or
      wants the allocation elsewhere.
      
      The *alien-stack* is saved with the dynamic environment so is restored
      with a non-local exist. It's not save on function entry/exit so you
      need to take care to match an allocation with a deallocation.
      
      Makes use of new VOPs which are already in place.
      
      Backout an old alien stack deallocation hack.
      1975d13a
    • pw's avatar
      6d8260e5
  33. Feb 19, 1997
Loading