[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54216e492cec4f84bc43dee176130e89@AcuMS.aculab.com>
Date: Thu, 13 Aug 2020 08:28:05 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Xu Yilun' <yilun.xu@...el.com>
CC: 'Moritz Fischer' <mdf@...nel.org>,
"linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"trix@...hat.com" <trix@...hat.com>,
"lgoncalv@...hat.com" <lgoncalv@...hat.com>
Subject: RE: [PATCH v4 1/4] fpga: dfl: change data type of feature id to u16
From: Xu Yilun
> Sent: 13 August 2020 08:59
> On Wed, Aug 12, 2020 at 08:52:39AM +0000, David Laight wrote:
> > From: Moritz Fischer
> > > Sent: 12 August 2020 04:56
> > >
> > > On Mon, Aug 10, 2020 at 10:41:10AM +0800, Xu Yilun wrote:
> > > > The feature id is stored in a 12 bit field in DFH. So a u16 variable is
> > > > enough for feature id.
> > > >
> > > > This patch changes all feature id related places to fit u16.
> >
> > How much bigger does it make the kernel?
>
> The patch changes the definition of feature id from u64 to u16, and will
> make the kernel slightly smaller.
Unlikely.
Most of the structures will gain a 'pad' field.
Using u16 for function parameters and results almost certainly
requires instructions to mask the value.
Any arithmetic on u16 will require masking instructions on
(probably) all architectures except x86.
Using 'unsigned int' is probably best.
u16 is never a good idea unless you are defining enough
of them in a structure (eg as an array) to reduce the
structure size below some threshold.
(Or are matching some hardware layout.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists