Older blog entries for crhodes (starting at number 22)

mwh: if you think valgrind doesn't like Python's memory allocator, well, try running it on CMUCL or SBCL...

Killing that process was fairly essential.

It's perhaps somewhat surprising how far a compiler can go with a broken model of floating-point control. Far enough to compile itself through three releases, anyway.

Still, it's fixed now. And the massed hordes of sbcl/powerpc/floating-point users can sleep safe in their beds.

So. One nasty SBCL bootstrap bug gone. Or at least worked-around; a proper solution will abstract the horribleness into a cross-compiler-aware MAKE-LOAD-FORM-SAVING-SLOTS.

wnewman: The bad news is that there's at least one more such bug, of similar complexity and larger impact. It's slightly odd that the ANSI J13 committee, in its wisdom, decided to make the return value from BYTE be of implementation-dependent nature. But, the world being what it is, we have to deal with it, and currently we're not.

Busy busy busy. Writing and helping to maintain a compiler is fun, but it also tends to hurt my brain. As a consequence of this maintenance work (and porting SBCL to Solaris) I still haven't had the necessary time to sit down and think about and start playing with using all the nice SIMD instructions on the x86 and ppc architectures to get sbcl to vectorize code. Maybe I'll take a sabbatical, after another three or four years of research in theoretical cosmology...

Still. We live in interesting times, given dan's threading thoughts, experimental Unicode support, and all sorts of advances from the cmucl camp, too.

OK. Now I'm scared.

No pressure. And this is of course completely compatible with my PhD studies. In mathematics. Erk. Still, my musical life will of course remain unaffected.

Bounce bounce bounce.

That's 120k of gzipped patch that I'm glad I'm not solely responsible for any more. SBCL on SPARC/Linux is alive.

The forward port is almost there.

There are one or two too many “issues” in there for my comfort, but at least it builds. It should be downhill from here on. Then, back to improving code-generation via bug-fixing and maintenance code... oh, and doing some PhD work.

Right. We're there.

*(list(lisp-implementation-type)(lisp-implementation-version)(machine-type))
("SBCL" "0.6.13" "SPARC")

It passes most of the tests. It runs. It compiles files. What more do you want? Well, a certain amount of code clean-up and a forward port to 0.7.1, but apart from that...

Thank you, wnewman and dan. I've learnt a lot. Some of that I didn't want to know...

Right. GC is now sorted(tm).

Point the first: sizeof(sigset_t) is all very well, but if you're dealing with kernel sigsets you will scribble over lots of other data, such as what's in your registers. How did this ever work?

Point the second: spot the stupid mistake...

#define READ_ONLY_SPACE_END LISPOBJ(268435456) /* 0x10000000 */
#define READ_ONLY_SPACE_START LISPOBJ(268435456) /*
0x10000000 */

Oops.

Now, we have some endianness issues to resolve, and then we might have two extra platforms to run our lisp compiler on.

OK, multiplication now works. Unfortunately that's the only bug fixed recently. We're still a way away from having a Lisp compiler on SPARC/Linux; currently the problem seems to be in garbage-collection-land.

Oh, for a nice high-level project...