From owner-freebsd-current  Wed Sep 11 15:42:34 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id PAA09140
          for current-outgoing; Wed, 11 Sep 1996 15:42:34 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA09128
          for <current@FreeBSD.ORG>; Wed, 11 Sep 1996 15:42:29 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA13505; Thu, 12 Sep 1996 08:37:16 +1000
Date: Thu, 12 Sep 1996 08:37:16 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199609112237.IAA13505@godzilla.zeta.org.au>
To: bde@zeta.org.au, dyson@dyson.iquest.net
Subject: Re: patch for Cyrix/Ti 486SLC/DLC CPU bug
Cc: current@FreeBSD.ORG, dg@Root.COM, kato@eclogite.eps.nagoya-u.ac.jp
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>>[invlpg]
>It is unreasonable (IMO) but unavoidable if the system doesn't provide
>a needed service.  It is difficult to imagine a machine independent
>reason to do a pmap_update (but I guess that it might be possible.)
>So, to kind-of answer your comment -- I will put it in cpufunc, but
>the only module that should normally need it would be pmap.c???

cpufunc was supposed to be for "access to special i386 instructions".
It is now clear that the right way to do this is usually to encapsulate
_single_ instructions in inline functions and write C code to combine
the functions.  The instructions are very machine-dependent and
shouldn't be given sortof-machine-independent names.  There are several
exceptions to this:

disable_intr()/enable_intr(): should be named cli()/sti() and maybe
	renamed in another layer.
ffs()/fls(): machine-independent interface; implement in another file.
	(Only) machine-dependent implementations as inline functions
	of machine-independent interfaces need to be included in
	<systm.h>.
loadandclear(): the primitive should be xchgl().
PC98 i/o functions: should never have been here.  cpufunc.h is supposed
	to have only i386 primitives.
pmap_update(): should be built out of primitives to read and write %cr3.
	Primitives to access other %cr's might as well be here too.
	At least ddb should be able to display and set them all;
	however, perhaps this should be implemented by having extern
	functions for all the cpu primitives - then the debugger wouldn't
	need special code for them.  I'd like to do this using compiler
	magic - perhaps use a file cpufunc.c that just #includes cpufunc.h,
	and compile it with -fkeep-inline-functions.
	Names for read/write/rd/wr/r/w/load/store should be more consistent.
setbits(): should be named orl().

Bruce