NetWinder Office Server

If you haven't seen RISC assembly code before, it may be strange to see so many operands on a single line. After all, CISCers are used to simple syntax like MOV A,B (or MOV B,A). RISC technology, by comparison, allows you to specify several operands on a single line as well as communicate more than just the usual relative, absolute and immediate addressing information. Although many hackers these days avoid learning assembly code (ESR recommends C, Python, Perl and LISP in his advice on how to be a hacker), it is difficult to appreciate operating system design without such knowledge. Of course, someone has to know it or nothing could get implemented. When porting Linux to a new platform (such as StrongARM), assembly code is more important than is usually the case.

One fault of Linux that Tanenbaum criticized (not the least politely) back in 1992 was that Linux was platform-specific, that is, a monolithic kernel for Intel 386. Today, Linux has been ported to several hardware platforms, and the kernel is more modular. We need to be familiar enough with assembly code to be able to do the porting and debugging work, and we must not get too dependent on it, lest we write too much platform-specific code. The idea is, Linux is superior to any hardware platform, so we use a cross-platform assembler (meaning C) for the code and limit our involvement with the specifics of the chips. (This way, when the x86 dies, Linux lives.) Nevertheless, RISC chips are simple, with only a few instructions, yet one can do so much on a single instruction. RISC technology, particularly in the context of parallel processing, is affiliated with the microkernel, and hopefully we will see more of both in the future. In the meantime, let's get back to the chip.

The StrongARM SA-110 has the following features:

The SA-110 has no math coprocessor. The chip performs extremely well on tasks where the instructions and data can be entirely cached and no floating-point operations are involved. Tasks involving too much code and data to make use of the cache become slow, and floating-point operations grind the chip to a halt. While some of these differences have to do with how well the Linux kernel and gcc jive with the chip set, without an FPU, a chip is disadvantaged (but the StrongARM excels at floating-point emulation, if you code specifically for it). If you check out the benchmarks (see Table 1), you can see how scattered the results are. I would not rest too much on them; the machine is quite perky, despite its typically lower than K6/233 scores. My favorite benchmark, the chess test, has NetWinder evaluating between 17 and 19 thousand positions every second (about one million per minute). Rebel.com expects to have 600MHz StrongARMs soon, and if the micro-architecture techniques get seriously improved (low power consumption and desire to avoid pipeline stalls make speculative execution and multiple branch prediction respectively impractical, though unique qualities of ARM could make other tricks possible) and the processor visits the debugger, future NetWinders should be much faster. (But then again, how much processor power do you need for e-mail, web, file, print, FTP and TELNET services?) The machine in question has 64MB of memory (34.8MB free), with most services turned on. As for disk access, Table 2 shows what Bonnie reports.

Table 1

Table 2

As you can see, the results are sporadic, with the processor scoring lower than a K6/233 in many cases and the disk drive operating much slower than a typical desktop hard drive. In spite of the low benchmarks, the machine has never lagged on me and does its tasks quite well. This is probably one case where the benchmarks don't mean very much, unless you plan on using the NetWinder for crunching numbers and maintaining huge databases. The chip set is fun to use, and I think hackers who are interested in the StrongARM might like to take a look at these machines, as well as anyone who wants a simple machine for use as a server.