Skip to content
Snippets Groups Projects
  1. Apr 12, 2000
  2. Nov 11, 1999
  3. Sep 16, 1999
  4. Feb 22, 1999
  5. Feb 20, 1999
    • pw's avatar
      Remove a cast that was inserted for Alpha/Linux but generated a compiler · 6dbd1a2f
      pw authored
      error on FreeBSD/x86. More investigation needed on Alpha/Linux side.
      6dbd1a2f
    • 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
  6. Feb 02, 1999
  7. May 01, 1998
  8. Jan 05, 1998
  9. Nov 25, 1997
    • dtc's avatar
      Ignore the foreign_function_call_active flag on the x86 port. It was · c308db4d
      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.
      c308db4d
  10. Nov 22, 1997
    • dtc's avatar
      Have interrupt_handle_pending reset the signal context sigmask before · 7de331b5
      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.
      7de331b5
  11. Nov 21, 1997
    • dtc's avatar
      Delay the re-enabling of interrupts in interrupt_internal_error and · f851310c
      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.
      f851310c
  12. Nov 19, 1997
  13. Mar 16, 1997
  14. Feb 18, 1997
  15. Feb 05, 1997
  16. Jan 21, 1997
  17. Oct 24, 1994
  18. Jul 05, 1994
  19. Mar 27, 1994
  20. Jan 13, 1993
  21. Sep 08, 1992
  22. Jul 28, 1992
  23. Mar 22, 1992
  24. Mar 08, 1992
  25. Nov 07, 1991
  26. Oct 22, 1991
  27. Sep 27, 1991
  28. May 24, 1991
  29. May 05, 1991
  30. Apr 27, 1991
  31. Mar 14, 1991
  32. Feb 16, 1991
  33. Jan 28, 1991
  34. Jan 08, 1991
  35. Dec 18, 1990
Loading