From owner-freebsd-current@FreeBSD.ORG Mon Apr 21 14:15:02 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F30FE37B401; Mon, 21 Apr 2003 14:15:01 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id F090D43FAF; Mon, 21 Apr 2003 14:15:00 -0700 (PDT) (envelope-from das@freebsd.org) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.5) with ESMTP id h3LLEujC005548; Mon, 21 Apr 2003 14:14:56 -0700 (PDT) (envelope-from das@freebsd.org) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.5/Submit) id h3LLEecB005547; Mon, 21 Apr 2003 14:14:40 -0700 (PDT) (envelope-from das@freebsd.org) Date: Mon, 21 Apr 2003 14:14:40 -0700 From: David Schultz To: Bruce Evans Message-ID: <20030421211440.GA5507@HAL9000.homeunix.com> Mail-Followup-To: Bruce Evans , Robert Watson , current@freebsd.org, David O'Brien References: <20030420192319.GB4963@HAL9000.homeunix.com> <20030421102341.GA3482@HAL9000.homeunix.com> <20030421231756.H11214@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030421231756.H11214@gamplex.bde.org> cc: Robert Watson cc: current@freebsd.org Subject: Re: HEADS UP: UFS2 now the default creation type on 5.0-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 21:15:02 -0000 On Mon, Apr 21, 2003, Bruce Evans wrote: > On Mon, 21 Apr 2003, David Schultz wrote: > > > The cgbase hack should only limit the size of the filesystem, not > > the disk location. It occurs to me that with a little more > > hackery, we can avoid the limitation entirely. If we revert to > > the 64-bit cgbase() and un-inline it, boot2 goes from 19 bytes > > available to -9 bytes. Add a kludge to factor out a few 64-bit > > multiply-adds and we're back to 3 bytes available. (I'm sure > > there are cleaner ways to save 9 bytes.) An untested unpolished > > diff follows. > > I played with similar changes, but didn't finish them. > > > Index: ufsread.c > > =================================================================== > > RCS file: /cvs/src/sys/boot/common/ufsread.c,v > > retrieving revision 1.11 > > diff -u -r1.11 ufsread.c > > --- ufsread.c 25 Feb 2003 00:10:20 -0000 1.11 > > +++ ufsread.c 21 Apr 2003 10:10:01 -0000 > > ... > > @@ -47,11 +59,11 @@ > > ... > > -#define FS_TO_VBA(fs, fsb, off) (fsbtodb(fs, fsb) + \ > > - ((off) / VBLKSIZE) * DBPERVBLK) > > +#define FS_TO_VBA(fs, fsb, off) ma((off) / VBLKSIZE, DBPERVBLK, \ > > + fsbtodb((fs), (fsb))) > > The division by VBLKSIZE should probably be a shift. ufsread.c has > VBLKSHIFT and uses it for all multiplications and divisions by VBLKSIZE > except this one. gcc can't optimize to just a shift since all the > types are signed and C99 specifies that division of negative integers > by positive ones has the usual hardware brokenness. As I recall, signed division gets optimized into a sign test, some bit fiddling for negative numbers, and a division. The additional cost is nominal if you only care about speed, but I'm sure using a shift directly would save a few more bytes.