diary at Telent Netowrks

Araneida works with asdf#

Sat, 02 Mar 2002 02:18:11 +0000

Araneida works with asdf. Total porting time required: about ten minutes (I had to do other fixes to make it work with sbcl 0.7 as well, but they needed doing anyway).

Created an experimental non-vendor-aligned cClan archive network. See mail to cclan-list and node creation instructions. So far it has one and a half sites (ftp.linux.org.uk and sourceforge, the latter in a client-only role) and dummy files, but we'll get some content up soon. Probably db-sockets/araneida/cliki, at a guess ...

Something odd happened to the new sourceforge mail archive#

Wed, 06 Mar 2002 01:14:10 +0000

Something odd happened to the new sourceforge mail archive interface and I don't know what. The latest messages available in it seem to be getting gradually older and older

Oh well

Lisp news: new asdf version with extra silly functions to help cclan package maintainers build their packages. New ftx13

Non-lisp news: passed my driving test, yesterday (i.e. Monday) morning. Some theories claim that this means I am no longer eligible to hack on SBCL.

Tomorrow, I hope, vendor-neutral cclan packages for Araneida, db-sockets, possibly also cliki. The plan requires getting some work done too, so we'll see ...

Still alive#

Tue, 12 Mar 2002 01:09:10 +0000

Still alive. Not entirely sure how much difference that makes.

I took the weekend off. Due to a combination of friends round on Saturday night, Dune on Sunday night, and finding all the Philip Pullman books were on special offer in Borders on Friday evening, I got no computer time all weekend other than a swift email check. On the other hand, I hoovered the carpets downstairs, which must be worth something.

Having just finished getting a bunch of work done (as referred to in previous entry), it might be time to look at some of that lisp stuff again. I've somehow managed to page my free projects TODO list out of main memory, though, and can't remember what I had lined up. So, we'll see if anyone complains.

So, SBCL#

Thu, 14 Mar 2002 03:46:44 +0000

So, SBCL. The order of events looks like (1) alpha fp fixes, (2) ppc forward port, (3) threads. As all of these need too much time spent rebuilding SBCL, we may get some cclan/asdf stuff done in the gaps.

More than you wanted to know about Alpha floating point ... and, probably, more than is actually true. I'm not an expert; I may have made bits of this up.

Alpha floating point is IEEE754-compliant. Kind of. Alpha floating point is IEEE754-compliant, if you ask it to be, but not necessarily entirely implemented in hardware. If you want it to handle infinities or denormals or the other difficult stuff, sometimes you'll get a trap to the operating system and the kernel has to fix up the answer. For each instruction, you get a choice of fast/correct tradeoffs: you can elect to deal with infinities correctly or not, and you can elect to handle inexact traps. Or, indeed, not.

It's common for a FPU to have some kind of status word. On the x86, for example, you can use this to say which exceptions you want to get traps for (an exception is a very lightweight thing if you don't trap it: just set a status bit and carry on with a default value. A trap usually involves a trip through the kernel), which exceptions have happened, how to round answers (tip: setting this away from the default mode may cause libm to do things it wasn't expecting. So, in normal use, don't). The Alpha has two. One's hardware and the other's per-process in software (and you need a syscall to get/set it). The hardware one doesn't correspond to IEEE exceptions either.

So, the immediate cause of the flurry of Alpha floating point work was that it failed on (sqrt single-float-positive-infinity).

I hope it's working correctly now. It passes tests, anyway, for what that's worth. If you don't know much about FP and are vaguely interested in it, google for ``William Kahan''. He's dead cool.

Non-geek activities: I bought a headphone adapter for my guitar amp the other day. At last I can practice late at night with it turned up :-)

Lloyds TSB just phoned me up to arrange an account review#

Thu, 14 Mar 2002 19:16:56 +0000

Lloyds TSB just phoned me up to arrange an account review. I haven't had an account with them for several months, having closed it due to their complete indifference, insincere form letters, rapacious charges, and general unhelpfulness. If I'd known then that they would do this afterwards, I could have added "basic incompetence" to that list.

Courtesy of the Compaq Testdrive programme, I tested infinities in CMUCL on Digital Unix. CMUCL 18a, because that was the latest version I could find

So, if the CMUCL people used an ev6 or later, that would explain why they haven't seen a problem with this, and reassure me that they haven't dealt with it using some deep magic that I am too dumb to understand. All's well that ends well, I guess. Nobody on cmucl-imp answered my questions, but I don't know if they have any Alpha hackers working on it these days. There's no Alpha 18c or 18d, which I would view as an indication against

So, do you want the good news or the - no wait, good news is all#

Sat, 16 Mar 2002 04:07:34 +0000

So, do you want the good news or the - no wait, good news is all there is right now. Good news or no news, I guess. Sorry.

SBCL PPC forward port progressed, uh, forwards. Most of it was renaming, and most of the renaming had already been done (thanks, Christophe). The only part requiring actual thought was that it wouldn't compile branches to targets more than 32k away. Disturbingly, this looks like a problem shared by CMUCL in its PPC and MIPS backends, unless they've done something magic I don't understand. Mail to cmucl-imp called for, tomorrow. Granted, it's not a bug that shows often, I expect - it's rare that a single function has a branch target more than 32k distant. Anyway, there's now additional magic in emit-conditional-branch: instead of emit-back-patch (which emits variable numbers but a fixed length of instructions) it has to emit-chooser. This lets us have different forms for when the branch is short and when it exceeds 32k, in which case we code a one-instruction jump with an inversion of the test condition, then an unconditional branch to the proper target: we turn

beq .far_away
stuff
.far_away

into

bne .skip
b .far_away
.skip
stuff
.far_away

and ditto for other conditions. I just looked in on the progress of the native compilation and it had got all the way to second genesis. Admittedly at that point it had crashed with a segmentation fault, but it looks like it had simply run out of memory. 64Mb is not enough for anyone. So, edited some numbers and I need to crosscompile again in the morning.

All being well, this means I have to start trying to remember what state I left my MP efforts in. Or time out and play with asdf for a while longer, but I seem to be on an SBCL roll right now and might as well get on with it.

Non-geek activities: ahh, that'd be the no news, I guess

revision 1.368#

Mon, 18 Mar 2002 18:30:47 +0000

revision 1.368
date: 2002/03/18 17:56:09;  author: dan_b;  state: Exp;  lines: +1 -1
        Merge PPC port
        ... new directories src/compiler/ppc, src/assembly/ppc
        ... other new files
        ... new clause in genesis for PPC fixups
        ... new files in runtime, PPC conditionals added in other .[ch] files
        Small Makefile cleanups in runtime
        ... actually use the dependency information
        ... regenerate depends on source changes
        We don't actually use sigreturn() in any present port: conditionals
        changed to make this obvious

You read it here third.

I think the only thing I miss having moved out of London is#

Wed, 20 Mar 2002 00:22:06 +0000

I think the only thing I miss having moved out of London is Primrose Hill. There really aren't many places around here to look down on the world from at night.

lemonodor has been#

Wed, 20 Mar 2002 06:30:46 +0000

lemonodor has been having trouble with multiprocessing in CMUCL, and comes to the conclusion that it is `just barely "production quality"'. For the record, the site that served you this page is running on the pretty similar SBCL (you wouldn't guess) using Araneida, and doesn't even use MP, instead hooking into the same event loop as SBCL uses for IO at the top-level. It does have Apache in front of the CL web server to act as a proxy, which tends to avoid most of the "slow/malicious client" problems.

Of course a lot of it comes down to traffic volume. telent.net only gets 1000 hits a day or so, evenly spread through 24 hours, though the other site I'm using Araneida for gets maybe 2-3 times that, concentrated around GMT lunchtimes and evenings. That site is limited by database access speed (and some really quite suboptimal queries in places don't help). ApacheBench has made it do 40-50 requests/second without hurting, but that's not exactly a real-world load.

SBCL MP will of course solve all the problems of the world if only I can get as far as implementing it ...

The last few days have been spent on SBCL MP#

Sat, 23 Mar 2002 17:16:49 +0000

The last few days have been spent on SBCL MP. So far I've managed to build a runtime which (a) still only has one thread, and (b) suffers random memory corruption. Way to go...

I think when this month ends it may be time to start a new page#

Wed, 27 Mar 2002 18:23:20 +0000

I think when this month ends it may be time to start a new page and confuse google again.

SBCL MP proceeds. No more random memory corruption (it wasn't all that random anyway, to be honest, it just looked random), thread switch primitives adapted from the previous foray (in other words, they ought to work but bitrot may have done nasty things), a trivially simple scheduler which amounts to "run the next process which was blocked on a read() or write() call" (we actually use non-blocking IO and a poll() loop, so would have blocked is more accurate) "or if none, the next process in the ready-process list", and the necessary hackery in fd-streams to make processes go to sleep when they block instead of hooking up to the serve-event mechanism to do output later. It's going to be easier to rip out serve-event and reimplement it using threads than it is to make threads coexist nicely with the present serve-event.

Testing it is yet to happen. Um, yeah... When it again reaches the point of completely compiling, I can carry on hacking it using chill and redefining things in the running lisp.

Hmm#

Fri, 29 Mar 2002 22:46:50 +0000

Hmm. Bits of it work, too. We can create a new process, switch to it, run something, and switch back. Debugging it is a bind, though: the debugger depends for corect operation on many of the bits we're tampering with.

After a comment on IRC, I found Edsger Dijkstra's How do we tell truths that might hurt.

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.

We can run two threads printing "aaaa" and "bbbb"#

Sat, 30 Mar 2002 01:07:50 +0000

We can run two threads printing "aaaa" and "bbbb". Woo.

Unfortunately we can't start a third, because we're starting them from the toplevel, which is running in the idle thread, which is not getting scheduled because we're never idle because the other two threads are running

Or something.

Note to non-lispers: you may be used to the noun process meaning "unix process with its own address space and stuff". Due to its long tradiiton of ignoring^Wdespising Unix, Lisp often uses the term to mean what Unix people would call a thread. Neither side is about to give up, I suspect. (I tend to use either depending on how who I'm talking to and how much sleep I've had lately)

Oh, got some cyling done today too: the weather was too nice not to. Unfortunately I broke the mounting for my cycle computer after the first 18 seconds, so I have basically no idea how fast I was going for the rest of it. Probably not very.

FTX13 this month will be either late or not happening#

Sat, 30 Mar 2002 10:14:18 +0000

FTX13 this month will be either late or not happening. Late because I won't have much of a network this weekend, possibly not happening because of lack of interest. Lack of interest especially from most of the projects it mentions, and I'm bored of doing it all myself when I could be hacking.

⟪Feb 2002 Apr 2002⟫