From owner-freebsd-current  Thu Nov 28 21:20:13 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id VAA28574
          for current-outgoing; Thu, 28 Nov 1996 21:20:13 -0800 (PST)
Received: from dyson.iquest.net ([198.70.144.127])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA28563
          for <current@freebsd.org>; Thu, 28 Nov 1996 21:20:10 -0800 (PST)
Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id AAA07832; Fri, 29 Nov 1996 00:19:29 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199611290519.AAA07832@dyson.iquest.net>
Subject: Re: users of "ft" tapes, please test!
To: bde@zeta.org.au (Bruce Evans)
Date: Fri, 29 Nov 1996 00:19:29 -0500 (EST)
Cc: bde@zeta.org.au, phk@critter.tfs.com, current@freebsd.org
In-Reply-To: <199611290447.PAA13253@godzilla.zeta.org.au> from "Bruce Evans" at Nov 29, 96 03:47:56 pm
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> >>I have been thinking about un-inlining spls.  This saves 29K out of
> 
> >I generally use the rule of thumb that unless the text-size is
> >smaller as a result, then inlining is wrong.
> 
> A good rule, I think.  Of course it is wrong if the code is in a tight
> loop, but that isn't common.
> 
> I think the inlines for min(), etc. break this rule.  There aren't many
> inlines that follow it.  E.g,. the inline spltty(), which is approximately
> only 2 C instructions (save = cpl; cpl |= tty_imask;) is twice as large
> as the non-inline version.
> 
I built the system with a de-inlined splx() and found an approx 10K savings.
My equiv changes for vm_wait saved approx 4K.  In both cases, I could not
detect a significant speed impact (if anything, it appears that the system
ran faster.)  Note that this is on a P6 -- which has really good caching.
Hope to soon get my P5-166 back up, for P5 testing.

If there is not a significant negative speed impact, I would be tempted to
make the changes.  It would be very suprising to see that an appropriately
coded splvm/splimp/splxxx would be much smaller than the subroutine call...
Have you considered coding the splxxx inlines in tight asm?  Would that help?

John