On Fri, 12 Nov 2010, Thor Lancelot Simon wrote: > The claim that NetBSD only cares about x86 is even more absurd. NetBSD > supports a huge array of architectures, usually in both their modern and > ancient implementations. We'll run on everything from R2000 to the newest > multicore 64-bit MIPS processors; a similar range of support exists for > ARM, powerpc, and many other processor and system families. We have not > done as good a job keeping up with SPARC or the death-rattle models of 68k > but we certainly haven't ripped SPARC or 68k support out either -- nor does > anyone intend to do so.
While support for other platforms are not being dropped, there does seem to be an implicit assumption that everyone is running on x86 (or more specifically amd64) and code should be optimized for performance on that architecture. Even "modern" architectures that are not amd64 are suffering. Take, for example, the simple act of byte swapping network data. x86 has a bswap instruction. SPARC and PowerPC architectures have a multiplexer on the load/store. (Don't know about MIPS, don't remember about ARM.) In order to swap a 64-bit value in registers you need to issue a series of shift, mask, and or instrutions, usually about 8 of them, most of which are depenent (cannot be issued in parallel on a superscalar machine). The macro NetBSD uses here is bswap64(). This maps very well to the x86 instruction, but is really not usable for any machine that does the swapping in the load/store path. Instead we could use something like load_be64()/load_le64()/store_be64()/store_le64() which could be mapped to a reverse-endian load/store instruction on architetures that support it and bswap on x86. Instead, in most cases, things that are not x86 need to jump though hoops to pretend to be x86. At least that't the way things look to me. BTW, I'm trying very hard not to yell and keep hyperbole to a minimum. Eduardo
