Older blog entries for crhodes (starting at number 23)

16 Jun 2002 (updated 16 Jun 2002 at 10:42 UTC) »
[17:41] <Krystof> It's compiling!
[17:41] <Krystof> make-target-2 is running!
[17:41] <Krystof> WOOOOHOOOOO!
[17:41] <wnewman> ship it. extensive testing is for weenies

Well, that might be a little exuberant; maybe an IRC excerpt isn't the best way of summarizing an achievement. So what have we done? Well, we now have a Common Lisp compiler, written in Common Lisp that can be built from a mostly unrelated Lisp compiler.

To people in the C world, this may not seem unusual. After all, gcc is built initially by vendor C compilers, then by itself. The difference between compiling C and compiling Lisp (well, OK, a difference) is that the act of compilation changes the state of the compiler.

This therefore raises portability issues as soon as you try to model the act of compilation itself. For instance, CMUCL, in its build process, scribbles over its own internal data structures, which is fine, as long as you're not trying to change the representation of those data structures; if you are, you need to find some way of bootstrapping the changes.

As of this week, though, we can state with a small degree of confidence that one can make arbitrary (consistent) changes to the source of SBCL and not have to deal with the bootstrapping question. What does this buy us? Nothing, really, except a small degree of confidence that one can change various representations without having nasty surprises jump out at us. This is not an end-user-visible improvement, really. It does give the maintainers a warm, fuzzy feeling, though.

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.

("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 */

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

14 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!