On Mon, Mar 29, 2010 at 9:41 PM, Garrett D'Amore <garr...@damore.org> wrote: > On 03/29/10 06:52 PM, Bart Smaalders wrote: >> >> On 03/29/10 15:13, Jason King wrote: >> >>> Speaking of such things, one thing I've been curious ever since >>> reading the various Sparc architecture manuals, is (if I understood >>> and remember them correctly -- it's been a while now), you can load a >>> 16, 32, or 64-bit value and using an appropriate ASI have it do an >>> endian conversion for you (and that this can work for both kernel and >>> user contexts, though perhaps different ASIs might be needed depending >>> on the context). Is there any reason those couldn't/shouldn't be >>> used? >> >> I don't know of any... they're awkward to use in most cases; coding >> some higher level routines may help. > > IIRC, this is *precisely* how ddi_get16 and friends work when they are used > with a handle that indicates little-endian device order. Of course, this is > only useful in the kernel...
Even in the kernel, zfs at the very least could benefit (since it does endian conversion as needed), though there might be other areas as well. ISTR that there are ASI's that can do that from user context as well (I'd need to pull up the sparc ref to be sure). However, for sparc it'd be most useful for the LE_xx macros (since hton* functions are essentially nops), though I'm not sure offhand if they could be rewritten to do inline asm that'd still be compatible (it's not an area of C/asm interaction I've messed with a whole lot) with the current definitions. _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
