Re: HEADS UP: UFS2 now the default creation type on 5.0-CURRENT

From: David Schultz <das_at_freebsd.org>
Date: Tue, 22 Apr 2003 05:56:08 -0700
On Tue, Apr 22, 2003, Bruce Evans wrote:
> On Mon, 21 Apr 2003, David Schultz wrote:
> 
> > On Mon, Apr 21, 2003, Bruce Evans wrote:
> > > On Mon, 21 Apr 2003, David Schultz wrote:
> > > > 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
> > > > ...
> > > > _at__at_ -47,11 +59,11 _at__at_
> > > >  ...
> > > > -#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
>                               ^ by a power of 2
> > bit fiddling for negative numbers, and a division.  The additional
>                                            shift
> > cost is nominal if you only care about speed, but I'm sure using a
> > shift directly would save a few more bytes.
> 
> I tried this, but it had no effect since FS_TO_VBA() is never actually used.
> So there is a much better optimization for it :-).  I think this makes ma()
> unused too.

In that case, I'm wondering how I managed to save a few bytes by
adding ma().  (Isn't the other macro that uses it expanded twice?)
Anyway, when I have time I'll look for a more elegant way to save
a few bytes.
Received on Tue Apr 22 2003 - 03:56:10 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:04 UTC