Motherboard Forums


Reply
Thread Tools Display Modes

OK, Maybe the ADA folks are right

 
 
Tim Wescott
Guest
Posts: n/a
 
      10-27-2011, 12:09 AM
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
 
Reply With Quote
 
 
 
 
Rob Gaddi
Guest
Posts: n/a
 
      10-27-2011, 12:38 AM
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.
 
Reply With Quote
 
 
 
 
Joe Chisolm
Guest
Posts: n/a
 
      10-27-2011, 01:47 AM
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
 
Reply With Quote
 
Andrew Reilly
Guest
Posts: n/a
 
      10-27-2011, 02:23 AM
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
 
Reply With Quote
 
Arlet Ottens
Guest
Posts: n/a
 
      10-27-2011, 05:23 AM
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;

 
Reply With Quote
 
John Devereux
Guest
Posts: n/a
 
      10-27-2011, 03:21 PM
Andrew Reilly <(E-Mail Removed)> 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
 
Reply With Quote
 
Hans-Bernhard Bröker
Guest
Posts: n/a
 
      10-27-2011, 06:24 PM
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;

 
Reply With Quote
 
Mike McGinn
Guest
Posts: n/a
 
      10-27-2011, 06:51 PM
On 2011-10-27, Hans-Bernhard Bröker <(E-Mail Removed)> 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

 
Reply With Quote
 
Datesfat Chicks
Guest
Posts: n/a
 
      10-27-2011, 09:44 PM
On Thu, 27 Oct 2011 13:51:14 -0500, Mike McGinn
<(E-Mail Removed)> 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
 
Reply With Quote
 
tim....
Guest
Posts: n/a
 
      10-29-2011, 10:00 AM

"Rob Gaddi" <(E-Mail Removed)> wrote in message
news:j8a94q$bdf$(E-Mail Removed)...
> 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


 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
The Ada Connection = Ada-Europe 2011 + Ada Conference UK 2011 Dirk Craeynest Embedded 0 06-08-2011 07:36 PM
Thirty years of the Ada User Journal, Ada-Europe Reports Dirk Craeynest Embedded 0 06-11-2009 10:39 PM
Re: OT (maybe, maybe not): freeware utility software Phred Dell 3 08-09-2008 06:35 PM
Re: OT (maybe, maybe not): freeware utility software Bob Johnson Dell 0 08-06-2008 01:42 PM
maybe its a scan, but maybe its for real free stuff guy Hardware 1 09-16-2004 06:04 AM


All times are GMT. The time now is 07:50 PM.


Welcome!
Welcome to Motherboard Point
 

Advertisment