headers
Thomas F. Burdick | 2 Aug 2002 00:15
Picon

Mac OS X / Darwin port

I'm about to get a new-to-me iBook, and since I'd be even less likely
to install Linux on a Mac than I would be on a Sun, I'm thinking about
an OS X port of SBCL.  It looks like OpenMCL now works on Darwin, so I
should be able to use that for bootstrapping.  Are there any problems
anyone knows about, that I should be aware of from the outset?

--

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 3 comments |
headers
Daniel Barlow | 2 Aug 2002 12:25

Re: Mac OS X / Darwin port

"Thomas F. Burdick" <tfb <at> OCF.Berkeley.EDU> writes:

> I'm about to get a new-to-me iBook, and since I'd be even less likely
> to install Linux on a Mac than I would be on a Sun, I'm thinking about
> an OS X port of SBCL.  It looks like OpenMCL now works on Darwin, so I
> should be able to use that for bootstrapping.  Are there any problems
> anyone knows about, that I should be aware of from the outset?

SA_SIGINFO signals don't exist - or do exist but don't work (I forget
which) - in OSX 10.1.  It's said that this is fixed in 10.2, but I
don't think I've talked to anyone who's verified this directly

SA_SIGINFO or something equivalently useful (read and write the
register contents from  a signal handler) is essential for SBCL: your
options here are to hope that 10.2 has added the necessary widgetry,
or to borrow the workaround that OpenMCL (which has basically the same
problem) uses

Other than that, probably all you need do is figure out a sensible
memory map.  As the SBCL internals cliki says
<URL:http://ww.telent.net/sbcl-internals/PPC>, it should mostly not be
rocket science

(Unless you want working floating point traps)

-dan

--

-- 

  http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
(Continue reading)

Permalink | Reply | 2 comments |
headers
William Harold Newman | 2 Aug 2002 16:57

off on vacation, dibs on DEFINE-COMPILER-MACRO

I'm off to the American Go Association Congress
  <http://www.usgo.org/congress/index.asp>
and will fairly likely end up being absent from the 'net in that time,
so if it seems as though I've become awfully quiet, you shouldn't be
terribly surprised.

Incidentally, on my handy laptop I have done some work like this
	(I set out to suppress compiler macro expansion when
		(> COMPILATION-SPEED SPEED), but now that I've read
		the DEFINE-COMPILER-MACRO specification, I think that'd
		probably be illegal. So I guess I won't.)
	As far as I can tell from the ANSI spec, it's nonconforming to
		return NIL from COMPILER-MACRO-FUNCTION just because of
		a NOTINLINE declaration. So make
		COMPILER-MACRO-FUNCTION ignore NOTINLINEness.
	made (DEFINE-COMPILER-MACRO (SETF FOO) ...) work
	made COMPILER-MACRO-FUNCTION check for legal function names
	factored out LEGAL-FUN-NAME-OR-TYPE-ERROR to support this
	tiny ANSI-compliance tweak: made
		(SETF (COMPILER-MACRO-FUNCTION FOO NIL) ...) work
but I haven't made proper tests for it yet, and I don't think I will
do so before I go, so it won't get checked in 'til I get back. 
There should at least be time to get it into sbcl-0.7.7 though.:-)

--

-- 
William Harold Newman <william.newman <at> airmail.net>
"06:20:29 <Zhivago> 'speak forth, or hence be considered my mindless zombie minions' might go down better"
  -- <http://tunes.org/~nef/logs/lisp/02.03.13>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Barlow | 3 Aug 2002 19:58

GC refactoring


Ove the last couple of days, fearing that I would soon be required to
understand the workings of gencgc, I put some effort into cleaning up
and refactoring a lot of the code duplicated between gencgc and the
Cheney-based non-generational copying GC.  If you're on the
sbcl-commits mailing list you'll have seen already that I've committed
these changes on a branch.

I haven't done all that could be done to it (there's still a lot of
very similar code in purify that could be factored out), but I have
reached the point where it's substantially shorter (by about 1500
lines, iirc) and still builds and runs on Linux Alpha and x86.  If
people with other systems (in particular, I'm sure we have many users
on x86 BSDs) would liike to try it and tell me whether it compiles and
having compiled actually collects garbage, I'd be very happy.  Style
suggestions would be nice too.  Patches for any remaining bugs would
always be welcome ...

Something like "cvs up -r gc_cleanup_branch_test1" should suffice to
grab the "last believed working" revision.  Thanks.

-dan

--

-- 

  http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources 

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Dejneka | 4 Aug 2002 06:09
X-Face
Picon
Favicon

some PCL defects

Hello,

1. DEFCLASS does not inform compiler about generated functions. For
   example, compiling file with

  (defclass a-class ()
    ((a-class-x)))

  (defun a-class-x (a)
    (with-slots (a-class-x) a
      a-class-x))

  produces

  ; caught STYLE-WARNING:
  ;   undefined function: SB-SLOT-ACCESSOR-NAME::|CLIM-INTERNALS A-CLASS-X slot READER|

2. DEFGENERIC does not check lambda list syntax.

  * (defgeneric gf ("a" #p"b"))
  #<STANDARD-GENERIC-FUNCTION GF (0)>
  * 

3. Examples from CLHS 7.6.5.1 do not signal errors, when they should.

Regards,
Alexey Dejneka

--

-- 
"You've said you removed a bug. Why has the code grown?"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thomas F. Burdick | 5 Aug 2002 00:24
Picon

Re: Mac OS X / Darwin port

Daniel Barlow writes:
 > "Thomas F. Burdick" <tfb <at> OCF.Berkeley.EDU> writes:
 > 
 > > I'm about to get a new-to-me iBook, and since I'd be even less likely
 > > to install Linux on a Mac than I would be on a Sun, I'm thinking about
 > > an OS X port of SBCL.  It looks like OpenMCL now works on Darwin, so I
 > > should be able to use that for bootstrapping.  Are there any problems
 > > anyone knows about, that I should be aware of from the outset?
 > 
 > SA_SIGINFO signals don't exist - or do exist but don't work (I forget
 > which) - in OSX 10.1.  It's said that this is fixed in 10.2, but I
 > don't think I've talked to anyone who's verified this directly

I'd forgotten about that.  POSIX signal handling is one of 10.2's
advertising points, and I verified that they work with someone inside
Apple, so I think I'll plan on only targetting 10.2, and just being
patient until it comes out.

 > SA_SIGINFO or something equivalently useful (read and write the
 > register contents from  a signal handler) is essential for SBCL: your
 > options here are to hope that 10.2 has added the necessary widgetry,
 > or to borrow the workaround that OpenMCL (which has basically the same
 > problem) uses
 > 
 > Other than that, probably all you need do is figure out a sensible
 > memory map.  As the SBCL internals cliki says
 > <URL:http://ww.telent.net/sbcl-internals/PPC>, it should mostly not be
 > rocket science
 > 
 > (Unless you want working floating point traps)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christophe Rhodes | 5 Aug 2002 09:56
Picon
Picon
Favicon

Re: Mac OS X / Darwin port

On Sun, Aug 04, 2002 at 03:24:38PM -0700, Thomas F. Burdick wrote:
> Daniel Barlow writes:
>  > "Thomas F. Burdick" <tfb <at> OCF.Berkeley.EDU> writes:
>  > 
>  > > I'm about to get a new-to-me iBook, and since I'd be even less likely
>  > > to install Linux on a Mac than I would be on a Sun, I'm thinking about
>  > > an OS X port of SBCL.  It looks like OpenMCL now works on Darwin, so I
>  > > should be able to use that for bootstrapping.  Are there any problems
>  > > anyone knows about, that I should be aware of from the outset?
>  > 
>  > SA_SIGINFO signals don't exist - or do exist but don't work (I forget
>  > which) - in OSX 10.1.  It's said that this is fixed in 10.2, but I
>  > don't think I've talked to anyone who's verified this directly
> 
> I'd forgotten about that.  POSIX signal handling is one of 10.2's
> advertising points, and I verified that they work with someone inside
> Apple, so I think I'll plan on only targetting 10.2, and just being
> patient until it comes out.

I think that's a reasonable plan, for what it's worth.  Having suffered
the pain of the most eccentric (signalwise) SBCL port, I wouldn't wish
another similar one on anybody :-)

>  > (Unless you want working floating point traps)
> 
> Unfortunately, I do.  I've been following the LinuxPPC port's problems
> with this, with trepidation.  I guess I'll cross that bridge when I
> get to it :-P

Bah.  Well, with luck Dan's identified the missing link in my absence
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christophe Rhodes | 5 Aug 2002 20:52
Picon
Picon
Favicon

Re: MAP, MERGE and friends

On Mon, Jul 29, 2002 at 11:22:04AM -0400, Raymond Toy wrote:
> >>>>> "Christophe" == Christophe Rhodes <csr21 <at> cam.ac.uk> writes:
> 
> > So, I was getting ready to merge this into CVS, when a little voice said
> > "test it some more". So I decided to try to build it on my x86/Linux
> > laptop. All went swimmingly; it got through genesis; got through
> > cold-init, built PCL and dumped a core. Whereupon I decided to run the
> > tests; and my shiny new sbcl binary hung on startup, never getting into
> > lisp land.
> 
> Don't know if this helps, but I did notice that in one of my attempts
> to make this all work on CMUCL, there were a few calls to
> make-sequence-like.  However, the given sequence was a vector with a
> fill pointer and the length was less than the actual length of the
> vector.  With these checks enabled, this causes a failure, of course.
> 
> Don't remember what I did to fix this, if any.

I don't think it's this; I've got code in make-sequence-like to remove
the length information from the type of the sequence passed to it.  It's
not a straightforward failure, either, sadly; I've now tested my patch
on more system, and (with the uncommenting of the CONCATENATE transform
for strings to compile away calls that are too difficult early in
cold-init, *sigh*) it works on sparc, alpha and ppc; it fails on x86.

This leads me to believe that, in fact, something is going wrong either
in gencgc or in purify. (Or, possibly, both; see below).

Let me elaborate a bit on the symptoms on the x86 (Linux, but I imagine
these to be the same on *BSD... maybe someone motivated could check?).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Daniel Barlow | 5 Aug 2002 21:16

Re: MAP, MERGE and friends

Christophe Rhodes <csr21 <at> cam.ac.uk> writes:

> Compiling without :SB-SHOW, however, leads to different broken
> behaviour; just after the end of first gc in cold-init, we take a path
> through gencgc_handle_wp_violation(), whereupon I get a SIGSEGV in
> vfprintf from the FSHOW statement at the head of that function.

_Without_ :sb-show?  Presumably you defined QSHOW_SIGNALS by hand?

You'll be using the alternate signal stack at that point, as this was
called from the SIGSEGV handler.  Has it overflowed?  info reg esp and
compare with ALTERNATE_SIGNAL_STACK_START (probably 0x58000000) and
SIGSTKSZ.  printf seems to be fairly deeply nested inside glibc, so
this may be a possibility

If you do need to increase the signal stack size, there are - I regret
to admit - two places it needs changing.  

interrupt.c:    sigstack.ss_size = SIGSTKSZ;
validate.c:    ensure_space( (lispobj *) ALTERNATE_SIGNAL_STACK_START,SIGSTKSZ)

(We don't actually need to use a fixed address for this any more
anyway: the call in validate could easily be lost in favour of some
mallocing in undoably_install_low_level_interrupt_handler.  I may fix
this later this month, but please feel free to preempt me if it
uncomplicates your problem)

-dan

--

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christophe Rhodes | 6 Aug 2002 10:44
Picon
Picon
Favicon

Re: MAP, MERGE and friends

On Mon, Aug 05, 2002 at 08:16:37PM +0100, Daniel Barlow wrote:
> Christophe Rhodes <csr21 <at> cam.ac.uk> writes:
> 
> > Compiling without :SB-SHOW, however, leads to different broken
> > behaviour; just after the end of first gc in cold-init, we take a path
> > through gencgc_handle_wp_violation(), whereupon I get a SIGSEGV in
> > vfprintf from the FSHOW statement at the head of that function.
> 
> _Without_ :sb-show?  Presumably you defined QSHOW_SIGNALS by hand?

Yes.

> You'll be using the alternate signal stack at that point, as this was
> called from the SIGSEGV handler.  Has it overflowed?  info reg esp and
> compare with ALTERNATE_SIGNAL_STACK_START (probably 0x58000000) and
> SIGSTKSZ.  printf seems to be fairly deeply nested inside glibc, so
> this may be a possibility

Something weird appears to be happening. Which way is the stack meant to
go on x86?

The fault occurs on the instruction vfprintf+18505:

0x4008fd29 <vfprintf+18497>:	mov    %esp,%ebp
0x4008fd2b <vfprintf+18499>:	sub    $0x20dc,%esp
0x4008fd31 <vfprintf+18505>:	push   %edi
0x4008fd32 <vfprintf+18506>:	push   %esi
0x4008fd33 <vfprintf+18507>:	push   %ebx
0x4008fd34 <vfprintf+18508>:	call   0x4008fd39 <vfprintf+18513>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane