[U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks

[Anton Staaf]

On Tue, Jul 12, 2011 at 12:30 PM, Wolfgang Denk <wd at denx.de> wrote:

> Dear Anton Staaf,
>
> In message <CAF6FioVs5rsF27Boq9+Bb+3Cgdh2m=jj1c=
> 41a-32muBUd9wtw at mail.gmail.com> you wrote:
> >
> > > Sorry, but because such code is unportable we do not accept it, as it
> > > would lead to driver code that becomes unportable, too.
> > >
> > > I know that this is throwing more fuel on the fire (for which I am
> sorry),
>
> You don't have to apologize.  I think it is important that everybody
> understands the reasons behind such decisions.


Thanks.

> but I don't follow the argument that this is unportable.  As far as I can
> > tell, the # : # syntax is not using any special compiler extensions, it
> is
> > simply substituted into a (boo) ? # : # expression, thus extracting
> either
> > the first of second number from the definition of the bit field.
> >
> > If I am wrong I would be interested to know what about this is not
> standard
> > pre-processor usage?
>
> I did not say anything about preprocessor issues.  The use of bit
> numbers (and ranges of bit numbers) in code is inherently unportable.
>
> For example:
>
> "Bit 10" means 0x00000400 on some systems (like, for example, on ARM),
> but  it  means 0x00200000 on others (like, for example, on PPC).
>
> On many systems bit 0 means trhe LSB, but the Power Architecture
> defines it as the MSB.  Thus bit numbers should never be used in any
> code to access bits or to create masks etc. - they are not generally
> applicable.


Ahh, I think I've finally (been lurking on this subject for a while) got the
core of this understood.  The problem is that if this mechanism (bit numbers
of any sort) were allowed in to U-Boot, then common driver code would end up
using it and the result would be drivers that specify bit fields using LSB 0
(or MSB 0) notation that would not match a datasheet from an SoC that uses
the alternative standard.  For example, the ns16550 driver would have to
pick one of LSB 0 or MSB 0 in it's header file instead of just specifying a
mask value.  The result would be that one of the standard bit field numbers
would become a second class citizen.  The code would still work for them,
but the encoding of the masks would be in an alien format.

That makes sense to me.  Would an alternative that uses the "width" and
"size" of the field be acceptable?  Then there is a well understood (on both
types of architectures) mapping from these values to the mask and shift
required to access portions of a register and/or variable in memory.

Thanks,
    Anton

Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> "In Christianity neither morality nor religion come into contact with
> reality at any point."                          - Friedrich Nietzsche
>