No joke! (I didn't say it was my code! It was in a code review - a la the OP's example)
No joke! (I didn't say it was my code! It was in a code review - a la the OP's example)
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.
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
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.
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
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!
... 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
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
Maybe if the code was shown in it's proper context:
void* foo(ostream& var) { void *new_var;
new_var = var
"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.
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
"CodeSprite" skrev i meddelandet news:Xns95027D4C2D61DoHcRiKeYwotID@63.218.45.215...
In the statement
new_var = (var
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
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/
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.