From owner-cvs-sys  Fri Dec  6 21:42:07 1996
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id VAA08614
          for cvs-sys-outgoing; Fri, 6 Dec 1996 21:42:07 -0800 (PST)
Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA08543;
          Fri, 6 Dec 1996 21:41:54 -0800 (PST)
Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1])
          by spinner.DIALix.COM (8.8.4/8.8.4) with ESMTP id NAA27541;
          Sat, 7 Dec 1996 13:40:34 +0800 (WST)
Message-Id: <199612070540.NAA27541@spinner.DIALix.COM>
To: Bruce Evans <bde@zeta.org.au>
cc: toor@dyson.iquest.net, cvs-all@freefall.freebsd.org,
        CVS-committers@freefall.freebsd.org, cvs-sys@freefall.freebsd.org,
        dyson@freefall.freebsd.org
Subject: Re: cvs commit: src/sys/i386/include endian.h 
In-reply-to: Your message of "Sat, 07 Dec 1996 16:29:42 +1100."
             <199612070529.QAA16289@godzilla.zeta.org.au> 
Date: Sat, 07 Dec 1996 13:40:33 +0800
From: Peter Wemm <peter@spinner.DIALix.COM>
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Bruce Evans wrote:
> Not now.  None did.  The inlines and macros can be treated as a library
> and cpu-dependent ones can be chosen in the places that use them.
> This is unwieldy for the ntoh* functions since they are used a lot.
> Bswap is the only generally useful instruction in ix86's that isn't
> always available, so there are unlikely to be more cases like this
> for ix86's.

Just as a thought, is it possible to handle the illegal instruction
trap on the i386 and emulate the bswap instruction?  Then we could just
use bswap everywhere and be done with it.  Obviously this would be a
penalty on the i386 (I wonder how much?), but it'd simplify the
environment on the "current" mainstream cpu's.  Perhaps this would
also be worth doing for invlpg() and other instructions?  It would
eliminate a runtime overhead for testing cpu_class on >= i486 cpu's
kinda like how we handle the %ds pop in returning to user - rather than
test for bogus values, we simply do it and IF it fails, then take the
time to pick up the bits.

Please forgive my "crackpot" ideas..  I've just woken up and the coffee
has not had a chance to kick in yet. :-)
 
> Bruce

Cheers,
-Peter