Older blog entries for crhodes (starting at number 18)

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...

I get a prompt!

csr21@caligula:/var/tmp/sbcl$ uname -a
Linux caligula 2.4.6 #1 SMP Sun Sep 30 16:40:07 BST 2001 sparc64 unknown
csr21@caligula:/var/tmp/sbcl$ src/runtime/sbcl --core output/cold-sbcl.core
[ much debugging output ]
* (defun foo (x y) (* x y))
FOO
* (foo 2 3)
6
* (compile 'foo)
FOO, NIL, NIL
* (foo 2 3)
12

Hmm. Still some work to be done, then.

No real movement on vectorization of CL user code, though I am confident that it can be done(tm), and also that I can(tm) do it.

On the plus side, SPARC/Linux support for SBCL is moving. I've found the sigcontext by grovelling about on the stack:

static void
sigsegv_handler(int signal, siginfo_t *info, void* void_context)
{
#ifdef sparc
  os_context_t *context = (os_context_t*)(&void_context+37);
#else
    os_context_t *context = (os_context_t*)void_context;
#endif
...
}
Yuuuuuuurk.

We're definitely executing lisp code now... it should now only be a matter of time.

You want a vectorizing Common Lisp compiler? Read this.

On the minus side, no-one is either telling me "Yes, this is a bug in the sparc-linux kernel" or "No, you've made a silly assumption here" about my SA_SIGINFO woes. This is quite annoying, as it means that dan can race ahead with his PPC port, so anyone who tells me "Mail to this address and you'll get a response" or, better, "Tell me what the problem is and I'll fix it" will earn my gratitude for whole minutes!

Hmm. Is the third argument to my SA_SIGINFO signal handler a pointer to a ucontext?

According to gdb, it's 0x0. This isn't likely to be good. My code works as expected on x86 and ppc, so I think I'm going to blame the sparc64 kernel. Grr.

Oh well. Time to branch out into other SBCL improvements anyway. Vectorizing lisp compilers, here we come!

9 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!