A lint classic

No joke! (I didn't say it was my code! It was in a code review - a la the OP's example)

Reply to
Rick Merrill
Loading thread data ...

It doesn't.

--
"I'm a war president.  I make decisions here in the Oval Office
 in foreign policy matters with war on my mind." -         Bush.
 Click to see the full signature
Reply to
CBFalconer

This works if the hardware has only a single bit shift operation and those 16000 shifts must be done by software loop. If multi bit shifts are available, does it really shift 16000 times or just say 32 times in practice ? If the instruction really does 16000 shifts, is the instruction interruptible and restartable, if not, interrupts can be blocked for a long time. What if the hardware uses some kind of barrel shifter, in which case the shift time is independent of number of shift positions.

Liberal use of the "volatile" keyword should prevent that.

This is a good advice, since you are very early forced to reconsider the implementation, when you are porting to a new environment, when you have some in-line assembly in the code. This way any potential problems do not go undetected until the new product is on the market.

Paul

Reply to
Paul Keinanen

It may well decide not to shift at all. After all, a shift by more than the register width cannot possibly make any sense, ever, so it's perfectly sensible for the compiler or the hardware to only consider the lower 5 or 6 bits to determine the actual shift count. And since (16000 & 63) is zero, that would mean it'll not shift at all.

Anyway, even if the above *did* work, on a particular platform, at the very least it should be accompanied by a massive comment block explaining the exact rationale of doing that, in exactly that way. And some assertions or #ifdef's to detect any change of platform that would invalidate the assumptions it's based on.

Not really. You can't rely on *anything* sensible to happen in this case. That code snippet is deep inside the realms of undefined behaviour, so it's entirely up to the compiler and the hardware what happens. It's technically allowed to explode your computer (optionally only if you do this on the 7th tuesday after halloween) or mail a complaint about the programmer's coding style to the CEO.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

If you declare the "var" as volatile, then you cannot read "var" more than once. "var" is not changed by the statement. Also if you declare "new_var" as volatile, then you cannot write it more than once. The "var

Reply to
Ulf Samuelsson

I now have a new quote in my personal quote file. It presents the following two quotes as a pair...

"'Undefined behavior' means that the compiler is free to do literally anything it wants to. Phased plasma beams are perfectly standard-compliant... -Craig Richardson

"That code snippet is deep inside the realms of undefined behaviour, so it's entirely up to the compiler and the hardware what happens. It's technically allowed to explode your computer (optionally only if you do this on the 7th tuesday after halloween) or mail a complaint about the programmer's coding style to the CEO." -Hans-Bernhard Broeker

Thanks!

Reply to
Guy Macon

... snip ...

That will exceed the normal four line sig limit, if so used :-)

--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
 Click to see the full signature
Reply to
CBFalconer

That's why it's in my personal quote file, not my .sig file.

--
Guy Macon, Electronics Engineer & Project Manager for hire. 
Remember Doc Brown from the _Back to the Future_ movies? Do you 
 Click to see the full signature
Reply to
Guy Macon

Maybe if the code was shown in it's proper context:

void* foo(ostream& var) { void *new_var;

new_var = var

Reply to
Dan Olson

"Ulf Samuelsson" wrote in news:UFmvc.1176$9n5.828@amstwist00:

Hmmm... this is the opposite to the definition of volatile as I understand it; marking a variable as 'volatile' should inform the compiler that it must make no assumptions about the contents of the variable since it may have changed since it was last read.

The variable will therefore be read every time it is used rather than being assumed to be equal to a copy held in a register or on the stack.

Peter.

Reply to
CodeSprite

Neither of the above statements makes any sense to me. Care to explain what you mean?

--
Grant Edwards                   grante             Yow!  HELLO KITTY gang
                                  at               terrorizes town, family
 Click to see the full signature
Reply to
Grant Edwards

"CodeSprite" skrev i meddelandet news:Xns95027D4C2D61DoHcRiKeYwotID@63.218.45.215...

In the statement

new_var = (var

Reply to
Ulf Samuelsson

I think you have an extra instruction near the end of the first example....

See below...

Ulf Samuelss>

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

The old adage in optimizing compilers is "you can cheat -- but don't get caught." Consider:

for (i = 0; i < 10; ++i) { f(); } vs for (i = 0; i < 10; ++i) { f(&i); }

in the first the compiler could keep i in a (callee-saves) register, in effect "cheating" by not updating some `int i' in memory. In the second it must make sure that i is updated before the call to f() because f() might care about the value of i.

Using the volatile keyword is a warning to the compiler that there are forces beyond its control that care about how the memory is manipulated (for example, it could be a memory mapped IO register, or another processor may access the memory). The compiler won't cheat by avoiding, moving or duplicating reads or writes.

--
Ben Jackson

http://www.ben.com/
Reply to
Ben Jackson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.