I dont know what you want to achieve by evaluating only the 15 LSB in a long int after a multiply of 16-bit ints. The resulting 15 bits will roll over whenever the value cannot be represented within 0-32767. In any application I can imagine, the correct response would be that something is wrong and halt whatever is being attempted. I guess my imagination is too narrow.
Apart from the above, you are correct in everything that you write.
What you are doing by evaluating the 15 LSB etc. etc. may work the way you expect in that particular CPU, but Rockwell cannot guarantee that it will work on other CPUs, including the emulator.
It says in the RSLogix 500 reference manual that
I am pretty sure that the emulator merely passes the arguments to the CPU (in this case an intel x86) which then returns the result. You might be right that it returns a "wrong value", but it would be the intel CPU, not the emulator that is in the wrong.
re "stale phart".
You wrote yourself "My only purpose in opening this thread was curiosity". My response was because of the same curiosity. When arguing back and forth we may learn something. I shall not post in your threads again.
Apart from the above, you are correct in everything that you write.
What you are doing by evaluating the 15 LSB etc. etc. may work the way you expect in that particular CPU, but Rockwell cannot guarantee that it will work on other CPUs, including the emulator.
It says in the RSLogix 500 reference manual that
I dont think that "SLC 5/02 or higher" includes the emulator running on a PC.[S:0/1] sets if overflow is detected at destination; otherwise resets. On
overflow, the minor error flag is also set. The value -32,768 or
32,767 is placed in the destination. Exception: If you are using
an SLC 5/02 or higher processor and have S:2/14 (math overflow
selection bit) set, then the unsigned, truncated least significant
16-bits of the result remains in the destination. For floating
point destinat
I am pretty sure that the emulator merely passes the arguments to the CPU (in this case an intel x86) which then returns the result. You might be right that it returns a "wrong value", but it would be the intel CPU, not the emulator that is in the wrong.
re "stale phart".
You wrote yourself "My only purpose in opening this thread was curiosity". My response was because of the same curiosity. When arguing back and forth we may learn something. I shall not post in your threads again.