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
Lisp news: new asdf version with extra silly functions to help cclan package maintainers build their packages.
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 ...
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
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.
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).
- Problem 1 was that we were getting 0.0 as an answer. This turns
out to be because all the floating point traps were wrong, causing it
to trap, and the trap was set to userspace as a SIGFPE, and we had a
stub handler that just did nothing. So, alter all the fpu trap bits
to refer to the software fp_control word instead of the harddware
fpcr. Write some ffi calls to do the actual get/set
- Now we're getting invalid-operation trap instead of 0.0. This is
because to calculate square roots of single-precision numbers in SBCL,
we coerce to double, call libm, and coerce back. The second coercion
was trapping. Investigation showed that it wasn't using the _s suffix
that enables software completion
- Now we get stupidly wrong answers which differ each time. This
is because the traps are imprecise, meaning they may be delivered some
time later. To find the bogus code, the kernel has to track backwards
from the place it was awoken, looking for it. This has two
implications (well, more than that actually, but two of immediate
relevance) for generated code: if you want software completion, you
can't reuse the registers in any of the code immediately following
(clobbering the input register is a nono too; no cvtts_sui
$f1,$f1) and you can't branch. The 'at risk' part is called the
trap shadow, and there are various rules for working out how long it
might be. And yes, our coercion operation is doing all of these
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
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
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
- (sqrt SINGLE-FLOAT-POSITIVE-INFINITY)
;;; ev67, same cmucl binary and core
- (sqrt SINGLE-FLOAT-POSITIVE-INFINITY)
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
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
Mon, 18 Mar 2002 18:30:47 +0000
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
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
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.
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
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.