1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

OK, Maybe the ADA folks are right

Discussion in 'Embedded' started by Tim Wescott, Oct 27, 2011.

  1. Tim Wescott

    Tim Wescott Guest

    This compiles:

    ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
    raw_data;

    I have every confidence that it would work as intended in lieu of

    if (adc_ping_pong)
    {
    osc_vector[fill_vector][fill_ix] = raw_data;
    }
    else
    {
    gyro_vector[fill_vector][fill_ix] = raw_data;
    }

    Ewww.

    --
    www.wescottdesign.com
     
    Tim Wescott, Oct 27, 2011
    #1
    1. Advertising

  2. Tim Wescott

    Rob Gaddi Guest

    On 10/26/2011 5:09 PM, Tim Wescott wrote:
    > This compiles:
    >
    > ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
    > raw_data;
    >
    > I have every confidence that it would work as intended in lieu of
    >
    > if (adc_ping_pong)
    > {
    > osc_vector[fill_vector][fill_ix] = raw_data;
    > }
    > else
    > {
    > gyro_vector[fill_vector][fill_ix] = raw_data;
    > }
    >
    > Ewww.
    >


    Hey, don't knock it. On a RISC machine, that difference might save you
    two, maybe even three instructions.

    --
    Rob Gaddi, Highland Technology -- www.highlandtechnology.com
    Email address domain is currently out of order. See above to fix.
     
    Rob Gaddi, Oct 27, 2011
    #2
    1. Advertising

  3. Tim Wescott

    Joe Chisolm Guest

    On Wed, 26 Oct 2011 19:09:40 -0500, Tim Wescott wrote:

    > This compiles:
    >
    > ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
    > raw_data;
    >
    > I have every confidence that it would work as intended in lieu of
    >
    > if (adc_ping_pong)
    > {
    > osc_vector[fill_vector][fill_ix] = raw_data;
    > }
    > else
    > {
    > gyro_vector[fill_vector][fill_ix] = raw_data;
    > }
    >
    > Ewww.


    Probably what the orignal intent, other than just being
    a smart ass, is to try and help a bad compiler with the index
    multiplies. A good optimizer will fix both code sets to be
    the same or very close. The first example might save a stack
    save/load if you have a lot of registers to play with.

    The Ewww factor is very high, enough to send the person back
    to beginning typing school to learn to use more than 2 fingers.

    --
    Joe
    Republic of Texas
     
    Joe Chisolm, Oct 27, 2011
    #3
  4. On Wed, 26 Oct 2011 19:09:40 -0500, Tim Wescott wrote:

    > This compiles:
    >
    > ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
    > raw_data;
    >
    > I have every confidence that it would work as intended in lieu of
    >
    > if (adc_ping_pong)
    > {
    > osc_vector[fill_vector][fill_ix] = raw_data;
    > }
    > else {
    > gyro_vector[fill_vector][fill_ix] = raw_data;
    > }
    >
    > Ewww.


    You're complaining about the spurious parentheses around adc_ping_pong,
    on the first line, right? ;-)

    Cheers,

    --
    Andrew
     
    Andrew Reilly, Oct 27, 2011
    #4
  5. Tim Wescott

    Arlet Ottens Guest

    On 10/27/2011 02:09 AM, Tim Wescott wrote:
    > This compiles:
    >
    > ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
    > raw_data;
    >
    > I have every confidence that it would work as intended in lieu of
    >
    > if (adc_ping_pong)
    > {
    > osc_vector[fill_vector][fill_ix] = raw_data;
    > }
    > else
    > {
    > gyro_vector[fill_vector][fill_ix] = raw_data;
    > }
    >
    > Ewww.
    >


    You could introduce a temporary variable, and make it a lot more readable:

    vector = adc_ping_pong ? osc_vector : gyro_vector;

    vector[fill_fector][fill_ix] = raw_data;

    Or, rewrite the code like this:

    vector[adc_ping_pong][fill_vector][fill_ix] = raw_data;
     
    Arlet Ottens, Oct 27, 2011
    #5
  6. Andrew Reilly <> writes:

    > On Wed, 26 Oct 2011 19:09:40 -0500, Tim Wescott wrote:
    >
    >> This compiles:
    >>
    >> ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
    >> raw_data;
    >>
    >> I have every confidence that it would work as intended in lieu of
    >>
    >> if (adc_ping_pong)
    >> {
    >> osc_vector[fill_vector][fill_ix] = raw_data;
    >> }
    >> else {
    >> gyro_vector[fill_vector][fill_ix] = raw_data;
    >> }
    >>
    >> Ewww.

    >
    > You're complaining about the spurious parentheses around adc_ping_pong,
    > on the first line, right? ;-)


    ha ha , that is just what I noticed, And I write stuff a bit like that
    sometimes,,,

    AFAIK they are equivalent and should produce the same optimised object
    code.


    --

    John Devereux
     
    John Devereux, Oct 27, 2011
    #6
  7. On 27.10.2011 02:09, Tim Wescott wrote:
    > This compiles:
    >
    > ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
    > raw_data;


    I'll call, and raise you a

    fill_ix<:adc_ping_pong
    ? osc_vector
    : &(gyro_vector[(int)
    NULL])[fill_vector:>] = raw\
    _data;

    If you're going to try a "reductio ad absurdum", why stop short? Might
    as well go all the way to make it truly absurd.

    Of course it will compile --- it'll even work. Which does beg the
    question: why the "Ewww"?

    Seriously, though, nobody forces anyone to write code like that first
    snippet (much less mine), and rather few programmers would. Most people
    would only consider the conditional operator for the right-hand side of
    an assignment, or function arguments, i.e. for making rvalues, not lvalues.

    But then again, in a pinch the compiler might, for some strange reason,
    compile denser/faster code from it, and if that saves the day, there's
    nothing wrong with having that option, is there?

    And if you're really uncomfortable with that rather dense notation,
    there are always in-between options like those shown by others here.
    Following the principle of separating things that differ from things
    that don't (in other words: don't copy-paste, concentrate!), I would
    lean towards this one:

    if (adc_ping_pong) {
    vector = osc_vector;
    } else {
    vector = gyro_vector;
    }

    vector[fill_vector][fill_ix] = raw_data;
     
    Hans-Bernhard Bröker, Oct 27, 2011
    #7
  8. Tim Wescott

    Mike McGinn Guest

    On 2011-10-27, Hans-Bernhard Bröker <> wrote:
    > On 27.10.2011 02:09, Tim Wescott wrote:
    >> This compiles:
    >>
    >> ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
    >> raw_data;

    >
    > I'll call, and raise you a
    >
    > fill_ix<:adc_ping_pong
    > ? osc_vector
    > : &(gyro_vector[(int)
    > NULL])[fill_vector:>] = raw\
    > _data;
    >
    > If you're going to try a "reductio ad absurdum", why stop short? Might
    > as well go all the way to make it truly absurd.
    >
    > Of course it will compile --- it'll even work. Which does beg the
    > question: why the "Ewww"?
    >
    > Seriously, though, nobody forces anyone to write code like that first
    > snippet (much less mine), and rather few programmers would. Most people
    > would only consider the conditional operator for the right-hand side of
    > an assignment, or function arguments, i.e. for making rvalues, not lvalues.
    >
    > But then again, in a pinch the compiler might, for some strange reason,
    > compile denser/faster code from it, and if that saves the day, there's
    > nothing wrong with having that option, is there?
    >
    > And if you're really uncomfortable with that rather dense notation,
    > there are always in-between options like those shown by others here.
    > Following the principle of separating things that differ from things
    > that don't (in other words: don't copy-paste, concentrate!), I would
    > lean towards this one:
    >
    > if (adc_ping_pong) {
    > vector = osc_vector;
    > } else {
    > vector = gyro_vector;
    > }
    >
    > vector[fill_vector][fill_ix] = raw_data;
    >


    I think if you are going to use the conditional operator you *must* nest them at
    least nine deep. I did that once about twenty years ago, the boss emitted steam.

    Well worth it.

    Mike
     
    Mike McGinn, Oct 27, 2011
    #8
  9. On Thu, 27 Oct 2011 13:51:14 -0500, Mike McGinn
    <> wrote:
    >
    >I think if you are going to use the conditional operator you *must* nest them at
    >least nine deep. I did that once about twenty years ago, the boss emitted steam.
    >
    >Well worth it.
    >
    >Mike


    You can probably rigorously prove that any if-else construct involving
    assignment to a single variable can be represented with nested C
    ternary operators.

    DFC
     
    Datesfat Chicks, Oct 27, 2011
    #9
  10. Tim Wescott

    tim.... Guest

    "Rob Gaddi" <> wrote in message
    news:j8a94q$bdf$...
    > On 10/26/2011 5:09 PM, Tim Wescott wrote:
    >> This compiles:
    >>
    >> ((adc_ping_pong) ? osc_vector : gyro_vector)[fill_vector][fill_ix] =
    >> raw_data;
    >>
    >> I have every confidence that it would work as intended in lieu of
    >>
    >> if (adc_ping_pong)
    >> {
    >> osc_vector[fill_vector][fill_ix] = raw_data;
    >> }
    >> else
    >> {
    >> gyro_vector[fill_vector][fill_ix] = raw_data;
    >> }
    >>
    >> Ewww.
    >>

    >
    > Hey, don't knock it. On a RISC machine, that difference might save you
    > two, maybe even three instructions.


    Only if you have a crap compiler :-(

    tim
     
    tim...., Oct 29, 2011
    #10
    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. free stuff guy

    maybe its a scan, but maybe its for real

    free stuff guy, Sep 16, 2004, in forum: Hardware
    Replies:
    1
    Views:
    307
    zixaq
    Sep 16, 2004
  2. Bob Johnson
    Replies:
    0
    Views:
    447
    Bob Johnson
    Aug 6, 2008
  3. Phred
    Replies:
    3
    Views:
    476
    Tony Harding
    Aug 9, 2008
  4. Dirk Craeynest
    Replies:
    0
    Views:
    1,459
    Dirk Craeynest
    Jun 11, 2009
  5. Dirk Craeynest
    Replies:
    0
    Views:
    295
    Dirk Craeynest
    Jun 8, 2011
Loading...

Share This Page