[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Please do not yell at people for trying to help you.
On Fri, Nov 12, 2010 at 06:35:32PM +0000, Eduardo Horvath wrote:
> On Fri, 12 Nov 2010, Thor Lancelot Simon wrote:
> 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
I have modern powerpc, MIPS, and ARM systems sitting on the very desk
I'm typing this on, and I don't buy it.
> 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.
I'm sorry if I'm missing the point, but aren't you complaining about
a design decision that was made at or around the time 4.3BSD was
released? bswap64(), a.k.a. htonq(), the big brother of htonl(). It
hardly seems fair to claim it as an example of how NetBSD only cares
about x86 and amd64 -- which didn't even exist at the time.
Thor Lancelot Simon
"We cannot usually in social life pursue a single value or a single moral
aim, untroubled by the need to compromise with others." - H.L.A. Hart
Main Index |
Thread Index |