On Thu, Mar 15, 2001 at 11:30:23PM +0000, Daniel Barlow wrote:
> :; 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.
That sounds like some of the problems that I've had when I've tried to
clean up the runtime, especially when I was trying to make all the
memory map constants be defined in one place. Repeatedly modified,
haphazardly documented low level C code, one of my favorites.:-| And
with all the 32/64 confusion for the Alpha, it must be even more fun.
> 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.
One reason, perhaps *the* reason, for the increased garbage generation
is that I punted all the object-pooling logic in CMU CL's
src/compiler/alloc.lisp. On X86/GENCGC, doing so caused a noticeable
but not enormous performance hit, and I thought it was worth it to get
rid of a potential source of several kinds of bugs, as well as just to
> 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?
I don't think this is a case where it's reasonable to ask you to break
it up into small diffs.:-| So you can send me (or post, if anyone else
is interested in kibitzing) one enormous diff. I'll review it, at
least the non-src/code/alpha/, non-src/compiler/alpha/ parts. I'll try
to do that in a timely fashion, but if the changes are big enough, it
might take some time. I might just merge the whole thing as is.
Otherwise I may come back with some questions, or requests for
changes. (I don't have an Alpha to test on, so there are some kinds of
changes I won't want to make myself.)
I'd very much prefer that you get it working well enough to bootstrap
itself and pass regression tests before we try to put it into the main
distribution. (I can, if I try, imagine reasons to do otherwise, but I
need to try pretty hard.) If it can already run the compiler well
enough to build PCL, it's probably very nearly there already, but I'd
prefer to make sure.
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C