From: Daniel B. <da...@no...> - 2001-03-15 23:28:41
|
:; uname -a Linux glodfish.telent.net 2.2.19pre7 #2 Sun Jan 28 23:03:43 GMT 2001 alpha unknown :; ls -l output/sbcl.core -rw-rw-r-- 1 dan dan 21282816 Mar 15 22:43 output/sbcl.core The bug that was holding everything up for the past six weeks elapsed turned out to be a bad register declaration in the var-alloc vop. We can't store random bits of bignums in descriptor registers. Most of the reason it took six weeks was that I decided it would help to remove all the gcc warnings in gc.c, and in the process managed to turn several pointer subtractions into integer subtractions. Duh. Off-by-multiple-of-4 errors; not what you need. There are some gaps worthy of note, yet: 1) All it's actually done at this point is get through the make.sh script: I haven't run the tests nor run any kind of applications. 2) Floating point is quite possibly about as completely broken as it can be while still being consistent with (1). floating-point-modes is a do-nothing stub, for one ... 3) It's based on 0.6.10.8, so needs CVS updating again. 4) Breakpoints (at least function-end breakpoints) are broken, I can predict with reasonable degree of certainty. "sigreturn() is unimplemented and will fail" 5) (Longer-term) GC, though working, is the original stop© hemispace Cheney thing, and it is _slow_. I think the sbcl compiler propably generates more ephemeral garbage than cmucl did; to be honest I don't have much of a feel for it though, as most of what I've ever done with cmucl on this machine is use it as a host for porting sbcl. What I will do now: tar up my current sources and put them somewhere grabbable on telent.net in case of catastrophe. What we need to sort out next: when I've synced up to CVS, this is going to be a big diff. How do you want to manage it? -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources |