Skip to content
  1. Sep 01, 2012
    • Raymond Toy's avatar
      Clean up RCS ids · eeab7066
      Raymond Toy authored
       * Get rid of the RCS Header stuff.  They're meaningless in git.
       * Add public domain comment to some of the files if the only comment
         was the RCS header.
      eeab7066
  2. Nov 04, 2011
  3. Oct 10, 2010
  4. Nov 12, 2008
  5. Jun 18, 2004
  6. Oct 13, 2003
  7. Jan 28, 2002
    • pmai's avatar
      Added specialised port to NetBSD (1.5.2) on x86. Since the code-base · 4ea11535
      pmai authored
      was already cleaned up with the OpenBSD port, this doesn't require
      massive changes.
      
      Since current NetBSD is ELF-based by default, we don't make use of the
      ELF feature, or in other words:  The presence of the NetBSD feature
      implies ELF, since there is no support for non-ELF NetBSD.
      4ea11535
  8. Dec 06, 2001
    • pmai's avatar
      Added specialised port to OpenBSD (2.9). Many parts of the original · 195461c1
      pmai authored
      code which were previously conditionalized on :FreeBSD, are now
      conditionalized on :BSD instead, with the :BSD feature now implying a
      4.4BSD(lite2) derived OS.  This should make future BSD-ports easier.
      FreeBSD and OpenBSD are differentiated by having either :FreeBSD or
      :OpenBSD on the features list.
      
      Currently the OpenBSD port does not have working ELF support, because
      OpenBSD 2.9 is still non-ELF by default.  So don't put ELF on the
      features list when building for OpenBSD, or fix the code to work
      correctly in this case instead.
      195461c1
  9. Feb 22, 1999
  10. Feb 20, 1999
    • pw's avatar
      Changes for Linux running on Alpha. · 25b808fb
      pw authored
      From: Julian Dolby <dolby@csag-226-8.UCSD.EDU>
      
        Enclosed below are diffs against the cvs repository as of Feb 12;
      aside from minor changes like using different include files
      (e.g. validate.h instead of x86-validate.h in Linux-os.c) and adding
      alpha-linux specifics unix-glibc2.lisp, there are two code changes.
      
       The first is to signal handling. I had to put the POSIX-SIGS
      ifdefs into places used by alpha but not by x86, and I ifdef'ed out
      most of the linux #define kludges for signals for alpha linux, since
      alpha linux uses OSF/1 signals rather than linux ones.
      
       The second is that the trick of or'ing 2 into the reg_ALLOC address
      to cause faults does not work on alpha linux since the kernel traps
      and handles the unaligned access; I did not find a way to change that
      kernel behavior, so I changed the code to or (1<<63) into the address
      to cause a seg fault, and then check, in the seg fault handler, to see
      if the high-order address bits are set.
      
       One change I made is to the memory layout (lisp/alpha-validate.h and
      compiler/alpha/parms.lisp); that change is not needed to make lisp run
      on alpha linux, but is there because I wanted more heap space.
      25b808fb
  11. 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
  12. Jan 21, 1997
  13. Mar 27, 1994
  14. Feb 11, 1994
  15. Jan 13, 1993
  16. Jul 28, 1992