LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

__int64 constant optimization messing up in compound function call

using LabWindows/CVI 8.1.1

declaring an __int64 variable called value, performing 1*value works fine until you try that in a compound function call ( f(g( dummy, 1*value), 1*value) ), where it results in "value*value" being passed to the function called.

do you think this is normal ?

attached is a software to reproduce the problem. and here is the output:


taking 2 steps, the operation is fine:
round called with: conversion=42, interval=8
round returns    : 40
add called with  : conversion=40, delay=8
add returns      : 48
separated: 48

the same in one step fails:
round called with: conversion=42, interval=64
round returns    : 0
add called with  : conversion=0, delay=8
add returns      : 8
grouped: 8

but note that this works fine: (i used "value" instead of "1*value")
round called with: conversion=42, interval=8
round returns    : 40
add called with  : conversion=40, delay=8
add returns      : 48
grouped: 48

can you find the pattern in the failling computation?
(note the value passed into the interval parameter)
value            : 8
round called with: conversion=42, interval=64
round returns    : 0
add called with  : conversion=0, delay=8
add returns      : 8
grouped: 8

value            : 9
round called with: conversion=42, interval=81
round returns    : 0
add called with  : conversion=0, delay=9
add returns      : 9
grouped: 9

value            : 10
round called with: conversion=42, interval=100
round returns    : 0
add called with  : conversion=0, delay=10
add returns      : 10
grouped: 10

you guys at NI have strange maths: 1*value = value*value...

but wait, isn't it the compiler shiting itself with the constant ?
let's try 2*value instead of 1*value...
value            : 7
round called with: conversion=42, interval=14
round returns    : 42
add called with  : conversion=42, delay=7
add returns      : 49
grouped: 49

aaaaaaaargh....



0 Kudos
Message 1 of 6
(3,917 Views)
Hi,

I have verified the behavior you are seeing and created a bug ID (#4BB9KT0F) for this issue. As of now, the only workarounds I can see are

- Using debug mode instead of release
- Not using a compound function call
- Changing 1  * value to 1.0 * value (of course this causes a conversion warning)

Sorry for you inconvenience and thanks for reporting the issue.

Best Regards,
Jonathan N.
National Instruments
0 Kudos
Message 2 of 6
(3,888 Views)
> I have verified the behavior you are seeing and created a bug ID (#4BB9KT0F) for this issue. As of now, the only workarounds I can see are

thanks a lot for creating it.

> - Using debug mode instead of release

for this application, i can't afford the O(n) behavior of the debug malloc routine...

> - Not using a compound function call
> - Changing 1  * value to 1.0 * value (of course this causes a conversion warning)

i just removed all my "1*" multiplication, which renders the software a litlle bit less readable.

(believe me, i really wrote a lot of 1 time multiplication... ok, 'value' was in fact 'HOUR', 'MINUTE', 'SECOND' and such, 'f' and 'g' were 'add' and 'round' and a lot more in the same vein, and the real lines were looking like 'add( round( time, 1*HOUR ), 1*HOUR )')

thanks you.
0 Kudos
Message 3 of 6
(3,882 Views)
There was another problem with the LCC compiler __int64 implementation, if the right hand element of a 64 bit binary expression was of static storage class, a GPF resulted.  I was told this would get fixed, but don't know if it was or not.

If you have Visual C++, or better yet, the Intel C++ compiler, you could use one of these compilers in release mode and probably avoid the problem.

Menchar


0 Kudos
Message 4 of 6
(3,869 Views)
> There was another problem with the LCC compiler __int64 implementation, if the right hand element of a 64 bit binary expression was of static storage class, a GPF resulted.  I was told this would get fixed, but don't know if it was or not.

it seems this one has been fixed.

> If you have Visual C++, or better yet, the Intel C++ compiler, you could use one of these compilers in release mode and probably avoid the problem.

i have Visual C++ and digital mars (www.digitalmars.com, give it a try, it is worth it) at hand.

digital mars is borland compatible (using OMF object and library files) but unfortunately does not want to link the cvi runtime due to incorrect name decoration. i have no time nor will to create a def file for the cvi runtime right now.
i tried visual studio before, but my code would not compile. now i think i have found the problem ('small' seems to be defined as a type somewhere...) and will retry later.
0 Kudos
Message 5 of 6
(3,858 Views)
I've had good luck using the Intel C++ Compiler for Windows ($450).

NI provides a template for using the 9.0 Intel compiler in release mode, I made a copy of it for the 10.0 compiler and it seems to work all OK.

When optimized for speed, I've seen speedups of 50% typically and sometimes 75% over the LCC compiler in release mode.

Q software systems has made the LCC compiler C99 compliant, I think NI would be well served to bring their version of the LCC compiler up to C99.   I keep running into nasty little problems that have been fixed in C99 Vs. C89.

Menchar
0 Kudos
Message 6 of 6
(3,842 Views)