Coding Style Question - Is there any sane reason for doing this?

Discussion in 'C++' started by BCFD36, Jan 10, 2012.

  1. BCFD36

    BCFD36 Guest

    I am working on a piece of legacy code that has many, shall we say,
    strange things. This one, as J.K. Anderson (classics Prof at UC
    Berkeley) used to say, "baffles me". It has the following statement in
    the code:

    const unsigned int WAKEUP_MASK = (1 << 1) ;

    Is there any reason for doing this, other than to make the code even
    more obscure?

    D. Scruggs
     
    BCFD36, Jan 10, 2012
    #1
    1. Advertising

  2. On 10.01.2012 02:11, BCFD36 wrote:
    > I am working on a piece of legacy code that has many, shall we say,
    > strange things. This one, as J.K. Anderson (classics Prof at UC
    > Berkeley) used to say, "baffles me". It has the following statement in
    > the code:
    >
    > const unsigned int WAKEUP_MASK = (1<< 1) ;
    >
    > Is there any reason for doing this, other than to make the code even
    > more obscure?


    No, there is no good reason: one should in general reserve ALL UPPERCASE
    identifiers for macros.

    But they should be used for macros.

    Also, there is no reason for the keyword `int`.

    So that's also quite baffling: is the author, like, a compulsive typist
    who just wants to type as much as possible, regardless of lack of meaning?

    Anyway, the almost OK part of that code, `1 << 1`, explicitly tells you
    that this is a single bit bitmask, and which bit is set; in the context
    of the rest it's bafflingly clear & communicative. It's generally good
    to be explicit in code, and let the compiler handle the translation to
    machine code, rather than doing it oneself and writing e.g. 0x0002. The
    latter is just a number which the reader then must decompile. However,
    for the general case `1 << n` runs the risk of Undefined Behavior, since
    it is a signed expression. It should be `1u << n`.


    Cheers & hth.,

    - Alf
     
    Alf P. Steinbach, Jan 10, 2012
    #2
    1. Advertising

  3. BCFD36

    Ian Collins Guest

    On 01/10/12 02:11 PM, BCFD36 wrote:
    > I am working on a piece of legacy code that has many, shall we say,
    > strange things. This one, as J.K. Anderson (classics Prof at UC
    > Berkeley) used to say, "baffles me". It has the following statement in
    > the code:
    >
    > const unsigned int WAKEUP_MASK = (1<< 1) ;
    >
    > Is there any reason for doing this, other than to make the code even
    > more obscure?


    In addition to Alf's comments, the form is quite common especially in
    the embedded or driver world. Although it is more common to see
    something like

    const unsigned wakeupBit = 1;
    const unsigned someOtherBit = 2;

    // other bit definitions

    const uint32_t wakeupMask = (1u << wakeupBit);

    --
    Ian Collins
     
    Ian Collins, Jan 10, 2012
    #3
  4. BCFD36

    BCFD36 Guest

    On 1/9/12 5:30 PM, Ian Collins wrote:
    > On 01/10/12 02:11 PM, BCFD36 wrote:
    >> I am working on a piece of legacy code that has many, shall we say,
    >> strange things. This one, as J.K. Anderson (classics Prof at UC
    >> Berkeley) used to say, "baffles me". It has the following statement in
    >> the code:
    >>
    >> const unsigned int WAKEUP_MASK = (1<< 1) ;
    >>
    >> Is there any reason for doing this, other than to make the code even
    >> more obscure?

    >
    > In addition to Alf's comments, the form is quite common especially in
    > the embedded or driver world. Although it is more common to see
    > something like
    >
    > const unsigned wakeupBit = 1;
    > const unsigned someOtherBit = 2;
    >
    > // other bit definitions
    >
    > const uint32_t wakeupMask = (1u << wakeupBit);
    >


    Interesting. I didn't know the form is common. I've never seen it
    before, but I don't do much driver work and haven't seen it in the
    embedded work I have done.

    Personally, I find it quite obscure and prefer the 0x0002 notation
    myself. But I will have to think on it some more. I can see how you
    could OR together a bunch of these and it be pretty clear which bits are
    set. But I still find it obscure.

    Thanks, much. Just for grins, I think I'll run it by the rest of my
    group and see if any of them have seen it before.

    --
    Dave Scruggs
     
    BCFD36, Jan 10, 2012
    #4
  5. BCFD36

    Richard Guest

    [Please do not mail me a copy of your followup]

    "Alf P. Steinbach" <> spake the secret code
    <jeg3u2$fen$> thusly:

    >No, there is no good reason: one should in general reserve ALL UPPERCASE
    >identifiers for macros.
    >
    >But they should be used for macros.


    I've seen people defining constant quantities like this in upper case
    because they are used to only being able to define constants with
    macros and they've equated the semantic category of "constants" to
    "macros" in their mind.

    I could go either way about it.

    I prefer the advice given in Coding Standard 0: Don't Sweat the Small
    Stuff, from "C++ Coding Standards" by Alexandrescue and Sutter.
    --
    "The Direct3D Graphics Pipeline" -- DirectX 9 version available for download
    <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

    Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
     
    Richard, Jan 10, 2012
    #5
  6. On 10.01.2012 07:05, Richard wrote:
    > [Please do not mail me a copy of your followup]
    >
    > "Alf P. Steinbach"<> spake the secret code
    > <jeg3u2$fen$> thusly:
    >
    >> No, there is no good reason: one should in general reserve ALL UPPERCASE
    >> identifiers for macros.
    >>
    >> But they should be used for macros.

    >
    > I've seen people defining constant quantities like this in upper case
    > because they are used to only being able to define constants with
    > macros and they've equated the semantic category of "constants" to
    > "macros" in their mind.
    >
    > I could go either way about it.
    >
    > I prefer the advice given in Coding Standard 0: Don't Sweat the Small
    > Stuff, from "C++ Coding Standards" by Alexandrescue and Sutter.


    Well, I also like that statement, and have also quoted it many times.

    However, I think "small stuff" is mainly stuff that only impacts on the
    feelings of proponents of this scheme and that.

    Things that have associated costs such as wasted work time, especially
    for others, are IMHO not that kind of small stuff, to be disregarded.
    Name collisions have such costs. Reduced readability have such costs.


    Cheers,

    - Alf
     
    Alf P. Steinbach, Jan 10, 2012
    #6
  7. BCFD36

    BCFD36 Guest

    On 1/9/12 10:12 PM, Alf P. Steinbach wrote:
    > On 10.01.2012 07:05, Richard wrote:
    >> [Please do not mail me a copy of your followup]
    >>
    >> "Alf P. Steinbach"<> spake the secret
    >> code
    >> <jeg3u2$fen$> thusly:
    >>
    >>> No, there is no good reason: one should in general reserve ALL UPPERCASE
    >>> identifiers for macros.
    >>>
    >>> But they should be used for macros.

    >>
    >> I've seen people defining constant quantities like this in upper case
    >> because they are used to only being able to define constants with
    >> macros and they've equated the semantic category of "constants" to
    >> "macros" in their mind.
    >>
    >> I could go either way about it.
    >>
    >> I prefer the advice given in Coding Standard 0: Don't Sweat the Small
    >> Stuff, from "C++ Coding Standards" by Alexandrescue and Sutter.

    >
    > Well, I also like that statement, and have also quoted it many times.
    >
    > However, I think "small stuff" is mainly stuff that only impacts on the
    > feelings of proponents of this scheme and that.
    >
    > Things that have associated costs such as wasted work time, especially
    > for others, are IMHO not that kind of small stuff, to be disregarded.
    > Name collisions have such costs. Reduced readability have such costs.
    >
    >
    > Cheers,
    >
    > - Alf


    I fully agree. If the original author had just added a comment about
    what this was, it would have been no problem. Obscure with an
    explanation I can handle. Obscure and just sitting there with everything
    else, which also has no explanation, is just wrong.



    --
    Dave Scruggs
     
    BCFD36, Jan 10, 2012
    #7
  8. BCFD36

    BCFD36 Guest

    On 1/9/12 11:01 PM, Paavo Helde wrote:
    > BCFD36<> wrote in news:jegihu$ri7$:
    >
    >> On 1/9/12 5:30 PM, Ian Collins wrote:
    >>> On 01/10/12 02:11 PM, BCFD36 wrote:
    >>>> I am working on a piece of legacy code that has many, shall we say,
    >>>> strange things. This one, as J.K. Anderson (classics Prof at UC
    >>>> Berkeley) used to say, "baffles me". It has the following statement

    > in
    >>>> the code:
    >>>>
    >>>> const unsigned int WAKEUP_MASK = (1<< 1) ;
    >>>>
    >>>> Is there any reason for doing this, other than to make the code even
    >>>> more obscure?
    >>>
    >>> In addition to Alf's comments, the form is quite common especially in
    >>> the embedded or driver world. Although it is more common to see
    >>> something like
    >>>
    >>> const unsigned wakeupBit = 1;
    >>> const unsigned someOtherBit = 2;
    >>>
    >>> // other bit definitions
    >>>
    >>> const uint32_t wakeupMask = (1u<< wakeupBit);
    >>>

    >>
    >> Interesting. I didn't know the form is common. I've never seen it
    >> before, but I don't do much driver work and haven't seen it in the
    >> embedded work I have done.
    >>
    >> Personally, I find it quite obscure and prefer the 0x0002 notation
    >> myself. But I will have to think on it some more. I can see how you
    >> could OR together a bunch of these and it be pretty clear which bits

    > are
    >> set. But I still find it obscure.

    >
    > The "1<<..." style is better for several reasons, most of which kick in
    > when you have larger values than just 0x2:
    >
    > - it clearly documents this is a bit mask
    > - it clearly documents there is only one bit set
    > - it clearly documents which bit it is so one can easily avoid
    > collisions with other masks and see which bits are unused
    >
    > The hexadecimal notation can also do all these things, but requires more
    > mental effort from the reader and familiarity with the hexadecimal
    > notation in the first place.
    >
    > Cheers
    > Paavo
    >
    >


    Only two small quibbles... it was not at all clear to me what this was
    supposed to indicate. Now that I know the secret handshake, it makes
    more sense. And doing it in HEX is no problem at all, at least for me.
    Maybe it is the dinosaur in me.


    --
    Dave Scruggs
     
    BCFD36, Jan 10, 2012
    #8
  9. On Jan 10, 7:01 am, Paavo Helde <> wrote:
    > BCFD36 <> wrote innews:jegihu$ri7$:
    > > On 1/9/12 5:30 PM, Ian Collins wrote:
    > >> On 01/10/12 02:11 PM, BCFD36 wrote:


    [strange legacy code]

    > >>> const unsigned int WAKEUP_MASK = (1<< 1) ;

    >
    > >>> Is there any reason for doing this, other than to make the code even
    > >>> more obscure?


    it's quite acommon idiom (the sift that is). I've always thought it a
    bit twee. "I'm so cool I can do clever things with bit operators, even
    though I don't know hex!".

    Perhaps better would be

    const unsigned BIT0 = 1;
    const unsigned BIT1 = 2;
    const unsigned BIT2 = 4;
    const unsigned BIT3 = 8;
    // etc.

    then

    const unsigned WAKEUP_MASK = BIT1;

    > >> In addition to Alf's comments, the form is quite common especially in
    > >> the embedded or driver world. Although it is more common to see
    > >> something like

    >
    > >> const unsigned wakeupBit = 1;
    > >> const unsigned someOtherBit = 2;

    >
    > >> // other bit definitions

    >
    > >> const uint32_t wakeupMask = (1u << wakeupBit);

    >
    > > Interesting. I didn't know the form is common. I've never seen it
    > > before, but I don't do much driver work and haven't seen it in the
    > > embedded work I have done.

    >
    > > Personally, I find it quite obscure and prefer the 0x0002 notation
    > > myself. But I will have to think on it some more. I can see how you
    > > could OR together a bunch of these and it be pretty clear which bits
    > > are set. But I still find it obscure.

    >
    > The "1<<..." style is better for several reasons, most of which kick in
    > when you have larger values than just 0x2:
    >
    >   - it clearly documents this is a bit mask


    not really

    >   - it clearly documents there is only one bit set


    sort of

    >   - it clearly documents which bit it is so one can easily avoid
    > collisions with other masks and see which bits are unused


    I submit my named constantrs are clearer

    > The hexadecimal notation can also do all these things, but requires more
    > mental effort from the reader and familiarity with the hexadecimal
    > notation in the first place.


    scarey thought. There are people writing device drivers that don't
    know hex?
     
    Nick Keighley, Jan 10, 2012
    #9
  10. On 10.01.2012 09:30, Nick Keighley wrote:
    >
    > scarey thought. There are people writing device drivers that don't
    > know hex?


    Why not use octal? Saves you typing an "x". After all, the creators of C
    were quite happy with octal for expressing low level bit patterns.


    Cheers,

    - Alf
     
    Alf P. Steinbach, Jan 10, 2012
    #10
  11. On 1/10/2012 12:14 PM, Scott Lurndal wrote:
    > "Alf P. Steinbach"<> writes:
    >> On 10.01.2012 09:30, Nick Keighley wrote:
    >>>
    >>> scarey thought. There are people writing device drivers that don't
    >>> know hex?

    >>
    >> Why not use octal? Saves you typing an "x". After all, the creators of C
    >> were quite happy with octal for expressing low level bit patterns.
    >>
    >>

    >
    > Assuming you're not having us on, you can't evenly divide 8, 16, or 32 by three.
    >
    > Octal made sense in the 12-bit and 36-bit worlds from which the creators of C
    > hailed.


    Are you saying that 040 is more difficult to read than 0x20? Just
    checking...

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jan 10, 2012
    #11
  12. BCFD36

    Jorgen Grahn Guest

    On Tue, 2012-01-10, Victor Bazarov wrote:
    > On 1/10/2012 12:14 PM, Scott Lurndal wrote:
    >> "Alf P. Steinbach"<> writes:
    >>> On 10.01.2012 09:30, Nick Keighley wrote:
    >>>>
    >>>> scarey thought. There are people writing device drivers that don't
    >>>> know hex?
    >>>
    >>> Why not use octal? Saves you typing an "x". After all, the creators of C
    >>> were quite happy with octal for expressing low level bit patterns.
    >>>
    >>>

    >>
    >> Assuming you're not having us on, you can't evenly divide 8, 16, or 32 by three.
    >>
    >> Octal made sense in the 12-bit and 36-bit worlds from which the creators of C
    >> hailed.

    >
    > Are you saying that 040 is more difficult to read than 0x20? Just
    > checking...


    Perhaps both Alf and you are joking and my humor center is out of
    operation, but anyway:

    I learned programming 20 years ago, and never found any reason to
    learn to read octal, other than in the very limited field of Unix file
    protection bits. It takes practice, and very, very few people get that
    practice these days.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jan 10, 2012
    #12
  13. BCFD36

    Jorgen Grahn Guest

    On Tue, 2012-01-10, Alf P. Steinbach wrote:
    > On 10.01.2012 02:11, BCFD36 wrote:
    >> I am working on a piece of legacy code that has many, shall we say,
    >> strange things. This one, as J.K. Anderson (classics Prof at UC
    >> Berkeley) used to say, "baffles me". It has the following statement in
    >> the code:
    >>
    >> const unsigned int WAKEUP_MASK = (1<< 1) ;

    ....
    > Also, there is no reason for the keyword `int`.


    Oddly, I've recently met two decent/good programmers who didn't know that
    the 'int' in 'unsigned int' is redundant. One asked me if just writing
    'unsigned' was a GCC extension!

    I suspect others write 'unsigned int' because they believe verbosity
    increases readability. I remember I did that very early in my career.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jan 10, 2012
    #13
  14. Jorgen Grahn <> writes:

    > On Tue, 2012-01-10, Alf P. Steinbach wrote:
    >> On 10.01.2012 02:11, BCFD36 wrote:
    >>> I am working on a piece of legacy code that has many, shall we say,
    >>> strange things. This one, as J.K. Anderson (classics Prof at UC
    >>> Berkeley) used to say, "baffles me". It has the following statement in
    >>> the code:
    >>>
    >>> const unsigned int WAKEUP_MASK = (1<< 1) ;

    > ...
    >> Also, there is no reason for the keyword `int`.

    >
    > Oddly, I've recently met two decent/good programmers who didn't know that
    > the 'int' in 'unsigned int' is redundant. One asked me if just writing
    > 'unsigned' was a GCC extension!
    >
    > I suspect others write 'unsigned int' because they believe verbosity
    > increases readability. I remember I did that very early in my career.


    I write "unsigned int" because making just "unsigned" work is a clear
    mistake in the standard :).

    --
    David Dyer-Bennet, ; http://dd-b.net/
    Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
    Photos: http://dd-b.net/photography/gallery/
    Dragaera: http://dragaera.info
     
    David Dyer-Bennet, Jan 10, 2012
    #14
  15. Jorgen Grahn <> wrote:
    > On Tue, 2012-01-10, Alf P. Steinbach wrote:
    > > On 10.01.2012 02:11, BCFD36 wrote:
    > >> I am working on a piece of legacy code that has many, shall we say,
    > >> strange things. This one, as J.K. Anderson (classics Prof at UC
    > >> Berkeley) used to say, "baffles me". It has the following statement in
    > >> the code:
    > >>
    > >> const unsigned int WAKEUP_MASK = (1<< 1) ;

    > ...
    > > Also, there is no reason for the keyword `int`.


    > Oddly, I've recently met two decent/good programmers who didn't know that
    > the 'int' in 'unsigned int' is redundant. One asked me if just writing
    > 'unsigned' was a GCC extension!


    > I suspect others write 'unsigned int' because they believe verbosity
    > increases readability. I remember I did that very early in my career.


    I use the "unsigned int" form I guess due to some sense of sym-
    metry, since I also have to write "unsigned long" and "unsigned
    short" (and I wouldn't consider 4 more characters as "verbosity"
    and, yes, to me it looks a bit more readable or at least it may
    stop me from from getting distracted by wondering "Did I really
    mean 'int' or did I perhaps forgot about the 'long' or 'short'?"
    when I later read it again).
    Regards, Jens
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Jan 10, 2012
    #15
  16. BCFD36

    Jorgen Grahn Guest

    On Tue, 2012-01-10, Jens Thoms Toerring wrote:
    > Jorgen Grahn <> wrote:
    >> On Tue, 2012-01-10, Alf P. Steinbach wrote:
    >> > On 10.01.2012 02:11, BCFD36 wrote:
    >> >> I am working on a piece of legacy code that has many, shall we say,
    >> >> strange things. This one, as J.K. Anderson (classics Prof at UC
    >> >> Berkeley) used to say, "baffles me". It has the following statement in
    >> >> the code:
    >> >>
    >> >> const unsigned int WAKEUP_MASK = (1<< 1) ;

    >> ...
    >> > Also, there is no reason for the keyword `int`.

    >
    >> Oddly, I've recently met two decent/good programmers who didn't know that
    >> the 'int' in 'unsigned int' is redundant. One asked me if just writing
    >> 'unsigned' was a GCC extension!

    >
    >> I suspect others write 'unsigned int' because they believe verbosity
    >> increases readability. I remember I did that very early in my career.

    >
    > I use the "unsigned int" form I guess due to some sense of sym-
    > metry, since I also have to write "unsigned long" and "unsigned
    > short" (and I wouldn't consider 4 more characters as "verbosity"


    Yes, you're right. I would have cited symmetry reasons back then.

    I now think of the symmetry argument as bogus though. 'long' and
    'short' are not "siblings" to 'int', just shorthand for 'long int' and
    'short int'.

    (And now someone will come claiming he always writes 'unsigned long
    int' for maximum readability.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jan 11, 2012
    #16
  17. BCFD36

    MikeWhy Guest

    Jorgen Grahn wrote:
    > On Tue, 2012-01-10, Jens Thoms Toerring wrote:
    >> Jorgen Grahn <> wrote:
    >>> I suspect others write 'unsigned int' because they believe verbosity
    >>> increases readability. I remember I did that very early in my
    >>> career.

    >>
    >> I use the "unsigned int" form I guess due to some sense of sym-
    >> metry, since I also have to write "unsigned long" and "unsigned
    >> short" (and I wouldn't consider 4 more characters as "verbosity"

    >
    > Yes, you're right. I would have cited symmetry reasons back then.
    >
    > I now think of the symmetry argument as bogus though. 'long' and
    > 'short' are not "siblings" to 'int', just shorthand for 'long int' and
    > 'short int'.
    >
    > (And now someone will come claiming he always writes 'unsigned long
    > int' for maximum readability.)


    For full, well rounded symmetry, you might consider writing 'signed long
    int'.

    I'm still stuck on simpler matters, 'uint32_t' for example, where 'unt32_t'
    would seem more symmetric with 'int32_t'.

    int32_t ifoo;
    unt32_t ufoo;

    uint32_t xfoo; // needs a tab rather than space to keep it aligned.
     
    MikeWhy, Jan 11, 2012
    #17
  18. BCFD36

    hanukas Guest

    On Jan 10, 10:30 am, Nick Keighley <>
    wrote:
    > On Jan 10, 7:01 am, Paavo Helde <> wrote:
    >
    > > BCFD36 <> wrote innews:jegihu$ri7$:
    > > > On 1/9/12 5:30 PM, Ian Collins wrote:
    > > >> On 01/10/12 02:11 PM, BCFD36 wrote:

    >
    > [strange legacy code]
    >
    > > >>> const unsigned int WAKEUP_MASK = (1<< 1) ;

    >
    > > >>> Is there any reason for doing this, other than to make the code even
    > > >>> more obscure?

    >
    > it's quite acommon idiom (the sift that is). I've always thought it a
    > bit twee. "I'm so cool I can do clever things with bit operators, even
    > though I don't know hex!".
    >
    > Perhaps better would be
    >
    > const unsigned BIT0 = 1;
    > const unsigned BIT1 = 2;
    > const unsigned BIT2 = 4;
    > const unsigned BIT3 = 8;
    > // etc.
    >
    > then
    >
    > const unsigned WAKEUP_MASK = BIT1;
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > >> In addition to Alf's comments, the form is quite common especially in
    > > >> the embedded or driver world. Although it is more common to see
    > > >> something like

    >
    > > >> const unsigned wakeupBit = 1;
    > > >> const unsigned someOtherBit = 2;

    >
    > > >> // other bit definitions

    >
    > > >> const uint32_t wakeupMask = (1u << wakeupBit);

    >
    > > > Interesting. I didn't know the form is common. I've never seen it
    > > > before, but I don't do much driver work and haven't seen it in the
    > > > embedded work I have done.

    >
    > > > Personally, I find it quite obscure and prefer the 0x0002 notation
    > > > myself. But I will have to think on it some more. I can see how you
    > > > could OR together a bunch of these and it be pretty clear which bits
    > > > are set. But I still find it obscure.

    >
    > > The "1<<..." style is better for several reasons, most of which kick in
    > > when you have larger values than just 0x2:

    >
    > >   - it clearly documents this is a bit mask

    >
    > not really
    >
    > >   - it clearly documents there is only one bit set

    >
    > sort of
    >
    > >   - it clearly documents which bit it is so one can easily avoid
    > > collisions with other masks and see which bits are unused

    >
    > I submit my named constantrs are clearer
    >
    > > The hexadecimal notation can also do all these things, but requires more
    > > mental effort from the reader and familiarity with the hexadecimal
    > > notation in the first place.

    >
    > scarey thought. There are people writing device drivers that don't
    > know hex?


    Sure we do know hex. But we are translating System/Catapult code and
    specification into C/C++ header, that is the simplest way to do it.
    Let's say we have a 5 bit field at offset 20. Sure we can juggle the
    masks in our heads nibble-at-time and get the right answer 99.9% of
    the time. But with this approach we do it in fraction of the time and
    get it right 99.999% of the time.

    We don't really care what that header looks like, what we do care
    about is that RB_BLOCK_CLOCK_GATE_MASK has the right value on it. We
    don't think in terms of "we are too cool to get our jobs done on
    time", you know? What would doing this thing ass-backwards prove? That
    we know hex? You are serious, though? Scary.
     
    hanukas, Jan 11, 2012
    #18
  19. BCFD36

    hanukas Guest

    On Jan 10, 10:45 pm, Richard <> wrote:
    > Victor Bazarov <> writes:
    > > On 1/10/2012 12:14 PM, Scott Lurndal wrote:
    > >> "Alf P. Steinbach"<>  writes:
    > >>> On 10.01.2012 09:30, Nick Keighley wrote:

    >
    > >>>> scarey thought. There are people writing device drivers that don't
    > >>>> know hex?

    >
    > >>> Why not use octal? Saves you typing an "x". After all, the creators of C
    > >>> were quite happy with octal for expressing low level bit patterns.

    >
    > >> Assuming you're not having us on, you can't evenly divide 8, 16, or 32by three.

    >
    > >> Octal made sense in the 12-bit and 36-bit worlds from which the creators of C
    > >> hailed.

    >
    > > Are you saying that 040 is more difficult to read than 0x20?  Just checking...

    >
    > It is.


    It's a question of point of view, as usual; in my mind I see those as:

    0x20 = 0010 0000
    040 = 000 100 000

    It's just a different # of bits grouped together, big deal. But that
    doesn't change anything. The idea of (1L << N) isn't to be readable
    anyway (in the context of embedded driver work) so arguing which form
    is more readable is missing the point.

    So what is the point? The point is painless translation of
    specification into usable header in finite time. Each field has mask
    and offset, these are used through everywhere else. This comes from
    digital circuit logic design languages like VHDL, SystemC, Catapult.
    The idea is painless interaction between those and C/C++ (C mostly).
     
    hanukas, Jan 11, 2012
    #19
  20. BCFD36

    hanukas Guest

    On Jan 11, 10:04 am, hanukas <> wrote:
    > On Jan 10, 10:45 pm, Richard <> wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > Victor Bazarov <> writes:
    > > > On 1/10/2012 12:14 PM, Scott Lurndal wrote:
    > > >> "Alf P. Steinbach"<>  writes:
    > > >>> On 10.01.2012 09:30, Nick Keighley wrote:

    >
    > > >>>> scarey thought. There are people writing device drivers that don't
    > > >>>> know hex?

    >
    > > >>> Why not use octal? Saves you typing an "x". After all, the creatorsof C
    > > >>> were quite happy with octal for expressing low level bit patterns.

    >
    > > >> Assuming you're not having us on, you can't evenly divide 8, 16, or 32 by three.

    >
    > > >> Octal made sense in the 12-bit and 36-bit worlds from which the creators of C
    > > >> hailed.

    >
    > > > Are you saying that 040 is more difficult to read than 0x20?  Just checking...

    >
    > > It is.

    >
    > It's a question of point of view, as usual; in my mind I see those as:
    >
    > 0x20 = 0010 0000
    > 040 = 000 100 000
    >
    > It's just a different # of bits grouped together, big deal. But that
    > doesn't change anything. The idea of (1L << N) isn't to be readable
    > anyway (in the context of embedded driver work) so arguing which form
    > is more readable is missing the point.
    >
    > So what is the point? The point is painless translation of
    > specification into usable header in finite time. Each field has mask
    > and offset, these are used through everywhere else. This comes from
    > digital circuit logic design languages like VHDL, SystemC, Catapult.
    > The idea is painless interaction between those and C/C++ (C mostly).


    For the record, none of the proposed approaches are used anyway.

    (1 << 4) // nope
    (1U << 4) // naah
    (1L << 4) // uh-huh..

    Here's how it's done:

    (0xf << 12) // zero-based mask shifted to correct position

    Or more concrete:

    SOME_REGISTER_FIELD_MASK (0xff << 16)
    SOME_REGISTER_FIELD_OFFSET 16
    SOME_REGISTER_FIELD_SIZE 8

    Usually this is not done by hand. The HLL description of logic is
    translated into C header and we always get all of these; mask, offset,
    size. It's up to the driver author to use the appropriate fields where
    needed.

    When we type these by hand, we follow the same convention for
    consistency. =)
     
    hanukas, Jan 11, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. calmar
    Replies:
    11
    Views:
    931
    calmar
    Feb 21, 2006
  2. Abhishek Saksena
    Replies:
    7
    Views:
    364
    Maxim Yegorushkin
    Aug 10, 2005
  3. __PPS__
    Replies:
    3
    Views:
    1,538
    Alf P. Steinbach
    Nov 9, 2005
  4. Jimmy
    Replies:
    3
    Views:
    461
    John Carson
    Jun 30, 2006
  5. NewToCPP
    Replies:
    28
    Views:
    675
    NewToCPP
    Jul 31, 2006
Loading...

Share This Page