The TODO list is looking entirely prosaic right now:#
Sat, 17 May 2003 04:24:23 +0000
The TODO list is looking entirely prosaic right now:
- article for Linux User magazine on something to do with CLiki (needs finishing)
- paper for UKUUG conference (needs starting)
- book proposal, revisions to
- try to work out if I want to/have the time to/can afford to go to Metz for the LSM2003, and if so how much of the UKUUG paper I can recycle and how much I need to write fresh.
So obviously this is a good time to spend a week looking at SBCL 64 bit issues. In fact I can't think of a more productive use of time, provided I discount almost anything else involving a computer in some way. As of my most recent checkin, though, we're at the point where
- the runtime support builds
- all the Lisp files build in the crosscompiler
- the initial image can be written out
- the initial image is loaded into the runtime, and starts executing. Even calls functions and stuff
- but dies fairly quickly when we start doing floating point
<dan_b> 0x00000000321b927c in ?? () <dan_b> 0x321B8FE0: MAKE-HASH-TABLE #X321B8FC9 <dan_b> 0x321BB140: HASH-TABLE-COUNT #X321BB129 <Krystof> Cooool <dan_b> this brings back memories <Krystof> yeah, we have been here(tm)
The particular memories I have in mind are from summer/autumn 2000 when I first started the SBCL Alpha port, and I think I was stuck with a problem in this area for some few months. I expect this time it'll be a matter of days or possibly even hours; what's frightening here is the realisation of how long ago those days were and how long I must have spent reading SBCL code since then. If I'd devoted the same amount of time to gcc, I'd probably be rich by now. Or, anyway, richer.
Nobody reported any interesting bugs in the sbcl prerelease last month, so we'll probably go ahead and do a 0.8 this month. Which means code freeze in about three days time, which means it's time to turn my attention to some threading cleanups this weekend. Definitely time to stop messing around with 64 bit support.