Older blog entries for crhodes (starting at number 14)

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.

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 2 3)
* (compile 'foo)
* (foo 2 3)

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);
    os_context_t *context = (os_context_t*)void_context;

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


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.

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