Older blog entries for crhodes (starting at number 12)

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!

It compiles! It compiles!

SBCL's sparc backend project advances a step. Note that just because it compiles doesn't mean that it actually works, particularly since I don't speak sparc (or any) assembler.

I hope the cmucl people knew what they were doing...

Hooray.

After much struggling, fufie managed to get CLISP CCLANized; after just a little more struggling, I have a powerpc OpenMCL that likewise believes in CCLAN.

And Pierre Mai has really understood the point of PARTITION.

Back to the PhD...

And they did. Thanks, Pierre.

Am I whistling in the wind, though? No vendor comments, no great deal of interest, just a few ripples. Ah well. I think it's a good thing anyway.

Thinking about the specification for PARTITION and friends in Common Lisp. I believe I now have a consistent spec in my mind, so it's now a matter of updating the specification and reference implementation, and announcing this fact to the world.

At which point, of course, someone else will come up with another niggle. Such is life.

CCLAN is live. See google for the announcement. Also please go and file bugs on SourceForge.

Things do seem to be growing, which is encouraging. Now to fix the rest of my life...

Whee! 24 whole packages in cCLan.

I wonder if we are at the start of a revolution. Probably not, but it is fun...

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