2.08 and Incompatible Battle Reports

[Taqwus]

*scratches head*
'volatile' may also help. The MSDN C++ Language Reference states, "Objects declared as volatile are not used in optimizations because their value can change at any time". Perhaps creating an 'int volatile do_not_reorder_me = 0;' declaration, explicitly separating the computations into multiple lines e.g.
int lhs = lhs_base + invoke_2d6() + do_not_reorder_me;
int rhs = rhs_base + invoke_2d6() + do_not_reorder_me;
would work. I haven't played around with that keyword much however -- been awhile since I wrote MT code.

[Arryn]

Originally posted by Saber Cherry:

quote:

---

Originally posted by PhilD:
Don't use two function calls in the same expression, is the lesson.

Compliers do strange things. A poorly-written compiler could rearrange consecutive lines if there is no obvious dependancy.

1: a=2d6+penetration
2: b=2d6+mrst
3: if(a>b){do c}

Lines 1 & 2 could be rearranged by a compiler if, for example, mrst is more local (already in a register) and penetration has to be fetched. That would have the same effect. I think C has some commands that let you force the complier to not rearrange things, though.

So the moral is actually not to trust Microsoft products, since they take away your control

---

Having done quite a bit of compiler beta-testing in my younger days, what this basically amounts to is an issue of (no offense to IW intended) somewhat sloppy coding practice by programmers. If you want to force the compiler to evaluate things a certain way, then make liberal use of parenthesis and local-scope intermediate variables. But what I see all too often is programmers that try to cram as much code as possible into a single line. That's just begging for trouble. And it's an absolute no-no when writing cross-platform code.

BTW, the MSVC compiler is actually very good. A bit odd at times, but good nonetheless. You just have to be very well acquainted with all it's various switches, directives, etc. The compiler doesn't really take control away from you. It's settings default to newbie usage. Which can be overridden. And should be, by professional coders.

My $0.02 worth on the subject.

[Saber Cherry]

Originally posted by Taqwus:
*scratches head*
'volatile' may also help.

Yeah, volatile was what I was thinking about. I suspect there are similar commands as well. Volatile, IIRC, is mainly used in multithreading and i/o. It can prevent a variable from being replaced by a constant, or ignored, but I'm not sure if it can prevent reordering.

Microsoft strives to prevent inter-os compatibility; maybe using an Intel compiler would be best=)

[Saber Cherry]

Originally posted by Arryn:
what this basically amounts to is an issue of (no offense to IW intended) somewhat sloppy coding practice by programmers... all too often (programmers) try to cram as much code as possible into a single line. That's just begging for trouble.

Hahaha... My lines are rarely less than 5X that long, and would be longer with a bigger monitor. Parenthesis do not help you if a compiler ignores your instruction ordering.

The problem here is that the lines are NOT LONG ENOUGH! The Microsoft compiler sees a simple rearrangement it can do to break inter-OS compatibility, and does it. If the lines are so long and confusing that the compiler can't figure out how to mutate them without breaking the program, it will just process them in order like it is supposed to

Really! I promise!

[AStott]

Eh... why bother with all the complicated methods of ensuring the calls happen in the right order. Instead, change:
if penetration+2d6 < MR+2d6

To:
if penetration < MR+2d6-2d6

Since both of the random calls are on the same side of the equation, the defined precendence order will ensure they are called in a consistent manner.

[Arryn]

Originally posted by AStott:
Eh... why bother with all the complicated methods of ensuring the calls happen in the right order. Instead, change:
if penetration+2d6 < MR+2d6

To:
if penetration < MR+2d6-2d6

Since both of the random calls are on the same side of the equation, the defined precendence order will ensure they are called in a consistent manner.

The problem comes in that the compiler's optimization will substitute the same call to the random number function for both die rolls. It won't make the two rand() calls the coders intend. What it does is make one call and plug the same value into both places. The optimizer does not know that in this circumstance, two calls to the same function do not return the same value.

[Peter Ebbesen]

Originally posted by Arryn:
The problem comes in that the compiler's optimization will substitute the same call to the random number function for both die rolls. It won't make the two rand() calls the coders intend. What it does is make one call and plug the same value into both places. The optimizer does not know that in this circumstance, two calls to the same function do not return the same value.

That would be an exceedingly poorly written optimizer. I certainly did not understand that as the original problem. I am certain that any decent compiler would make the two rand calls.

As I understood it, the real problem was that in the expression "a < b" the order of evaluation of "a" and "b" is undefined [Ansi-C, and its derivatives, with a few exceptions only specifies the order of evaluation for operators, not for sub-expressions]. Either side "a" or "b" can be evaluated first.

Given that the seed is the same, assume the RNG will return R1 and R2 over the next two calls in that order. Then the inequality:

(penetration+2d6 < MR+2d6)

can legally be compiled such that the evaluation is either of the following:
penetration+R1 < MR+R2 (left hand side evaluated first)
penetration+R2 < MR+R1 (right hand side evaluated first)

- Which may or may not give different return values.

Changing the inequality as AStott suggested, to
penetration < MR+2d6-2d6
would not necessarily solve the problem either, as the order of evaluation of the two 2d6 function calls is not defined either. (The order of the addition and subtraction is, but not the order of evaluation of the sub-expressions)

If you are in doubt, split such expressions over multiple commands independently evaluated. A bad optimizer may still hurt you, but at least you won't be bitten by the "undefined evaluation order", which is nobody's fault but your own. Or, to quote Kernigham & Ritchie:

The moral is that writing code that depends on order of evaluation is a bad programming practice in any language. Naturally, it is necessary to know what things to avoid, but if you don't know how they are done on various machines, you won't be tempted to take advantage of a particular implementation.

[ February 25, 2004, 23:23: Message edited by: Peter Ebbesen ]