From owner-cvs-all  Fri Jul 27 19: 0: 6 2001
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8486E37B405; Fri, 27 Jul 2001 18:59:58 -0700 (PDT)
	(envelope-from obrien@FreeBSD.org)
Received: (from obrien@localhost)
	by freefall.freebsd.org (8.11.4/8.11.4) id f6S1xw810069;
	Fri, 27 Jul 2001 18:59:58 -0700 (PDT)
	(envelope-from obrien)
Message-Id: <200107280159.f6S1xw810069@freefall.freebsd.org>
From: "David E. O'Brien" <obrien@FreeBSD.org>
Date: Fri, 27 Jul 2001 18:59:58 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/usr.sbin/pkg_install/add main.c src/usr.sbin/pkg_install/lib
         str.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG

obrien      2001/07/27 18:59:58 PDT

  Modified files:
    usr.sbin/pkg_install/add main.c 
    usr.sbin/pkg_install/lib str.c 
  Log:
  Remove s_strl*().  I am not sure what was thought they accomplished.
  
  When reading the code I had to stop, say "ok, what does *these*
  modifications of strl*() do?  Pull out grep.  Oh, not in add/, maybe above
  in ../lib/?  Yep.  So what do they do?  Comments above them are misleading,
  guess I'll have to read the code.  Oh, they just test strl* against the
  size and return the result of the test.  Now I can continue to read the
  code I was.
  
  The uses of s_strl*() then test that result and errx()'s.
  Lets think about the "optimized" code I am removing:
  
  In general the compiler pushes the three args to strl* onto the stack and calls
  s_strl*.  s_strl* has to indirectly access 3 args from the stack.  Then push
  them on the stack a 2nd time for the real strl* call.  s_strl* then pops the
  return from strl* off the stack; or moves it from the register it was returned
  in, to the register where tests can happen.  s_strl* then pops the three
  arguments to strl*.  Perform the test, push the result of the test, or move it
  from the result register to the return value register.  The caller to s_strl*
  now has to either pop the return value of s_strl* or move it from the return
  value register to the test register.  The caller then pops the three args to
  s_strl* off the stack (the same args that s_strl* itself had to pop off after
  the real call to strl*).  The s_strl* caller then performs a simular test to
  what has already been done, and conditionally jumps.  By doing things this way, we've given the compiler optimizer less to work with.
  
  Also, please don't forget the that call to s_strl* has possibly jumped to code
  not in the cache due to being far away from the calling code, thus causing a
  pipeline stall.
  
  So where is the "optimization" from s_strl*?
  It isn't code clarity.
  It isn't code execution speed.  It isn't code size either.
  
  Revision  Changes    Path
  1.43      +19 -19    src/usr.sbin/pkg_install/add/main.c
  1.10      +1 -15     src/usr.sbin/pkg_install/lib/str.c


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message