As I wrote back on New Year's Day, I've been working on a SPARC userland emulator.
It's now to the point where it mostly works for some tasks. I've been using it to rebuild a bunch of software. (It is still a bit buggy. For example, under some circumstances I have not quite figured out the details of, I've seen my shell fail to notice when a child process exits.)
The interesting part at the moment is how disorienting this is to many of my habits. I've used a lot of machines, all the way from quarter-lung things like an hp300 with 5MB of RAM to relatively modern things like multi-core x64 machines running at 2+ GHz. (At one point, years ago, when I described what I was running to one of the NetBSD people, he told me I probably had, simultaneously, examples of the slowest and fastest machines then supported by NetBSD.) In general, the slower machines are (surprise surprise) slower than the fast ones.
But this emulator is upsetting those reactions. It's really sluggish for computational tasks, like compiling (which spends most of its time crunching in userland). My very rough estimate is that it's about two orders of magnitude slower than my SPARCstation-20s at that. (The underlying machine is an Athlon 64 X2 2200, powernow-slowed to 1GHz for heat reasons.)
But some things actually run faster than on the real hardware, notably things that spend most of their time in the kernel. One of the most blatant examples is "rm -r", which runs perceptibly faster than the real thing.
Of course, this is because it's doing very little but trapping to the kernel. Since such operations are handled by the emulator rather than emulating a SPARC kernel, they run much faster than the real thing.
None of this is a surprise, intellectually. The only surprise here for me is the extent to which I feel disoriented; the emulated machine matches neither the reactions I have developed for slow machines nor the ones I have developed for fast machines. I would not have expected that discrepancy to make this much difference.