I posted, recently (here and here), about my VAX and SPARC emulators.
They're now "working", which is to say, they're at just about the lowest level of functionality that I think I can fairly use the word for. The VAX one has done three, I think it is, builds of various 1.4T-based NetBSD trees; the build in progress should bring it up to my latest 1.4T-based source. (The tree I found that actually built was relatively old; I've been updating it in large jumps rather than trying to do it all in a single jump.)
The SPARC emulator, meanwhile, is still chugging along at its own build. It's using almost exactly the same source tree as the lataest VAX build, and, based on progress through the build, it's running slower than the VAX emulator by a factor of somewbere between 5 and 6. This surprises me. I know the VAX, being CISC versus the SPARC's RISC, does more per instruction than a SPARC does, but I didn't know the difference was this large. I'm assuming, mostly without evidence, that most of the time taken by the emulators goes to per-instruction overhead, so that it's a reasonable approximation to assume that it takes the same time for each one to execute an instruction. That's unfair to the VAX, though, because the VAX emulator is emulating the whole thing, whereas the SPARC emulator is doing just userland and thus not paying emulation overhead penalty for syscalls. However, building the world is mostly userland crunching by the compiler.)
They are, however, now running on the same machine, so the underlying hardware differences I wrote about before do not come into it. Fortunately, that machine is multi-core, so to a first approximation the two emulators do not interfere with one another.
I also just today added logarithms to my calculator program. This is notably largely because it's a moderately high-precision calculator, capable of working with numbers of up to 2047 digits in bases up to 255. This meant the usual math library logarithm support is useless, except possibly as an initial approximation if I had algorithms that could use an initial approximation (which I don't).
I still want to find people to playtest my zendo program with. I don't suppose any of you are interested? (In its present form, you'll need a machine running a UNIX-family OS with gcc; to fetch the code yourself you'll need git, though I can also send out ad-hoc copies. For anyone who wants to have a look at the code and has git set up, git://git.rodents-montreal.org/Mouse/games/zendo is the thing to git clone.)