LoWord and HiWord issue

[Maged A. Mohamed]

Please I read 32 bits from sensor then split them to 16 for T and 16 for H
I found my problem in the LoWord and HiWord results.
So I commented the whole function and made this function compose a longinteger (TT) for 221 and 110 values
It come up with 14483566
If I use the same function to split, the result is correct but if I put
TT = 14483566 which the the same value, I get both results 110

Please look for *** where I comment near the issue
Best regards
Maged

[Dany]

Please I read 32 bits from sensor then split them to 16 for T and 16 for H
I found my problem in the LoWord and HiWord results.
So I commented the whole function and made this function compose a longinteger (TT) for 221 and 110 values
It come up with 14483566
If I use the same function to split, the result is correct but if I put
TT = 14483566 which the the same value, I get both results 110

Please look for *** where I comment near the issue
Best regards
Maged

Hi I tested (part of) your code in the IDE simulator/debugger, see below, and everything works as expected: values are 221 and 110...

Code: Select all

program HiWord_LoWord

' Declarations section 

dim TT as longint
    S1H, S1T as word

main:
'   Main program 

HiWord(TT) = 221
       LoWord(TT) = 110
       TT = 14483566  ' This is the result of TT from above 2 assignments, if we comment this line, it works fine
       S1H = Hiword(TT)         '   S1H becomes 221
       S1T = LoWord(TT)        '   S1T becomes 110
       
  TT = 0 'only for breakpoint purposes
end.

[Maged A. Mohamed]

Thanks a lot for your help
I re-tried the following

Code: Select all

program HiWord_LoWord

' Declarations section 

dim TT as longint
    S1H, S1T as word

main:
'   Main program 

       TT = 14483566  ' This is the result of TT from above 2 assignments, if we comment this line, it works fine
       S1H = Hiword(TT)         '   S1H becomes 221
       S1T = LoWord(TT)        '   S1T becomes 110
       
  both became 110, I think something is wrong with my PC
end.

[janni]

both became 110, I think something is wrong with my PC

Nothing's wrong with your computer. You've probably upgraded to mB version 6.6.2 which (again) hasn't been preceded by any beta-tests and now exhibits unintended side effects of improvements that, most probably, seemed innocuous enough to developers.

[Maged A. Mohamed]

both became 110, I think something is wrong with my PC

Nothing's wrong with your computer. You've probably upgraded to mB version 6.6.2 which (again) hasn't been preceded by any beta-tests and now exhibits unintended side effects of improvements that, most probably, seemed innocuous enough to developers.

GOD bless you,
That is exactly what happened, I re-installed 6.6.1 and everything works fine
6.6.2. was even flickering and unstable
Thanks very much
Best regards
Maged

[aCkO]

I agree that compiler is generating bad listing, but I suspect that the real reason is hiding in incomplete optimization (probably combined with inline functions). Personally, I think that the local variable tt should be completely eliminated with this code as it is. That can be easily seen from the code and the Help file just confirms it:

Local vars optimization

No local variables are being used if their result does not affect some of the global or volatile variables.

Here's the problem:

Code: Select all

       HiWord(TT) = 221
       LoWord(TT) = 110
       TT = 14483566  ' This is the result of TT from above 2 assignments, if we comment this line, it works fine
       S1H = Hiword(TT)         '   S1H becomes = 110 rather than (221)
       S1T = LoWord(TT)

At some point in the function, the user assigned a literal to a variable effectively forcing the compiler to treat the variable like constant from that moment on (but the compiler should also be aware that previously no global or volatile variable was affected by variable tt thus eliminating it completely). Unlike previous versions of the compiler, v6.6.2 (correctly) decides to use literals instead of variable tt and assign them to S1H and S1T (unfortunately using bad literal for HiWord part).

We can easily prevent this from happening if we somehow let the compiler know that the value of tt can be changed between the lines:

Code: Select all

...
TT = 14483566  ' This is the result of TT from above 2 assignments, if we comment this line, it works fine
S1H = Hiword(TT)         '   S1H becomes = 110 rather than (221)
...

Making tt volatile solves the problem, forcing the compiler to replace literals with registers.

Regards

[janni]

Local variables would indeed be optimized out but all variables in the example are global so the problem effectively comes to improper interpretation of inline functions (Lo, Hi, Higher, Highest, LoWord, and HiWord) at compile time. There's indeed no problem at runtime (or forced runtime behaviour by making the variables volatile or inserting assembly). Previous versions of the compiler also used literals instead of variable whenever it was possible at compile time - just used the valid ones (BTW, with the line commented out one obtains correct values because compiler does not use literals when assigning S1H & S1T).

All in all this bug is comparatively benign - it's just that again no beta-tests were performed and who knows what may surface next.

[aCkO]

I was referring more to the improper optimization in the original example, than to the scope of variables used.

Local variables would indeed be optimized out...

No, in previous versions they wouldn't and that's exactly what kept this bug "hidden" (see example below). In previous versions the use of inline functions prevented the optimizer from eliminating their arguments. In v6.6.2, inline functions are part of the optimization process.

...so the problem effectively comes to improper interpretation of inline functions (Lo, Hi, Higher, Highest, LoWord, and HiWord) at compile time.

That's because they were never interpreted at compile time in previous versions (except when used on literals).

Previous versions of the compiler also used literals instead of variable whenever it was possible at compile time

That depends on what "whenever possible" exactly means and that's where the new version differs from previous. Consider this modified Dany's example:

Code: Select all

program HiWord_LoWord

dim S1H, S1T as word

main:
  dim TT as longint
  
  TT = 14483566  ' This is the result of TT from above 2 assignments, if we comment this line, it works fine
  S1H = Hiword(TT)         '   S1H becomes 221
  S1T = LoWord(TT)        '   S1T becomes 110

end.

Previous versions generate the following listing:

Code: Select all

_main:
;HiWord_LoWord.mbas,6 :: 		dim TT as longint
;HiWord_LoWord.mbas,8 :: 		TT = 14483566  ' This is the result of TT from above 2 assignments, if we comment this line, it works fine
0x0003	0x306E      	MOVLW      110
0x0004	0x1283      	BCF        STATUS, 5
0x0005	0x1303      	BCF        STATUS, 6
0x0006	0x00F0      	MOVWF      R0
0x0007	0x3000      	MOVLW      0
0x0008	0x00F1      	MOVWF      R0+1
0x0009	0x30DD      	MOVLW      221
0x000A	0x00F2      	MOVWF      R0+2
0x000B	0x3000      	MOVLW      0
0x000C	0x00F3      	MOVWF      R0+3
;HiWord_LoWord.mbas,9 :: 		S1H = Hiword(TT)         '   S1H becomes 221
0x000D	0x0872      	MOVF       R0+2, 0
0x000E	0x00A2      	MOVWF      _S1H
0x000F	0x0873      	MOVF       R0+3, 0
0x0010	0x00A3      	MOVWF      _S1H+1
;HiWord_LoWord.mbas,10 :: 		S1T = LoWord(TT)        '   S1T becomes 110
0x0011	0x0870      	MOVF       R0, 0
0x0012	0x00A0      	MOVWF      _S1T
0x0013	0x0871      	MOVF       R0+1, 0
0x0014	0x00A1      	MOVWF      _S1T+1

while v6.6.2 simplifies this to:

Code: Select all

_main:
;HiWord_LoWord.mbas,6 :: 		dim TT as longint
;HiWord_LoWord.mbas,9 :: 		S1H = Hiword(TT)         '   S1H becomes 221
0x0003	0x306E      	MOVLW      110
0x0004	0x1283      	BCF        STATUS, 5
0x0005	0x1303      	BCF        STATUS, 6
0x0006	0x00A2      	MOVWF      _S1H
0x0007	0x3000      	MOVLW      0
0x0008	0x00A3      	MOVWF      _S1H+1
;HiWord_LoWord.mbas,10 :: 		S1T = LoWord(TT)        '   S1T becomes 110
0x0009	0x306E      	MOVLW      110
0x000A	0x00A0      	MOVWF      _S1T
0x000B	0x3000      	MOVLW      0
0x000C	0x00A1      	MOVWF      _S1T+1

but unfortunately with bad literal.

All in all this bug is comparatively benign - it's just that again no beta-tests were performed and who knows what may surface next.

Agreed. Also, in those betas I would prefer to see more technical description of what has been changed in the compiler, so we can all perform targeted testing of fixed or new features. Otherwise, we would be looking for a needle in a haystack, as we are doing now, and occasionally learn about the bugs from the pinpricks we get.

Regards

[janni]

I see what you mean with the TT variable made local and never used besides the two assignments. There's indeed more optimization in new version in such case. Still, it doesn't seem to have any influence on the error found as it shows up whether such optimization takes place or not. It's still there when TT is global and all the difference between final code of older and new version is in literals used in assignments.

Anyway, once the problem was found it is for the developers to detect the reason and find a fix. Hopefully that's the only problem of the new version.

Also, in those betas I would prefer to see more technical description of what has been changed in the compiler, so we can all perform targeted testing of fixed or new features. Otherwise, we would be looking for a needle in a haystack, as we are doing now, and occasionally learn about the bugs from the pinpricks we get.

How true (especially when one considers that there was supposedly no change in command line compiler in v 6.6.2).

[Maged A. Mohamed]

Hi All
I appreciate your thorough discussion, as I am not as specialized as you are, but I feel like to comment on some notes

I wrote this program like I said in the 1st post to read humidity and temperature from 2 sensor each gives one 48 bit value, 16 for H, 16 for T and 16 for CRC, I read only 32 bits. A function to update 4x20 characters display to show result and also time a BCD generated.
All calculated values showed wearied characters and did not accept keypad changes, so at the end of each function, I assigned a value to locate where the interpretation went wrong and the data is lost.
1- The variable TT being treated as constant because I assigned a literal to it, a variable is expected to be assigned a math result or a literal for a starting value, and in the body of the function, TT was modified be the sensor's reading serially 16 bits.
Also I tried 3 versions of this code, TT is local inside the function, then as advised here a global variable, the bug was consistence

' code to move port pin serially into variable TT
HiWord(TT)=221 LoRord(TT)=110 ' I added this line just to see if the values are displaying correctly
S1H=Hiword(TT) S1T=LoWord(TT) ' This works fine
but
HiWord(TT)=221 LoRord(TT)=110
TT= 14483566 ' the result of the above line
S1H=Hiword(TT) S1T=LoWord(TT) ' This gives wrong result, no matter of what the optimizer may consider TT as, the value in it is still the same and the result should be the same.

Thanks very much again, I will stick for the moment with 6.6.1
Best regards

Oh by the way the Watch window and the clock window does not stay, Each time I ran 6.6.2 I had to go from the menu to show them, then they appear on the left, If I move them to the right the program flickers for sometime and then shows something like 2 copies opened and I can't get rid of one of them

[filip]

Hi,

I have reproduced the issue that you were talking about and will report them to our developers.
I apologize for the inconvenience.

Regards,
Filip.

[janni]

Oh by the way the Watch window and the clock window does not stay, Each time I ran 6.6.2 I had to go from the menu to show them, then they appear on the left, If I move them to the right the program flickers for sometime and then shows something like 2 copies opened and I can't get rid of one of them

I could not reproduce it, but then it's probably layout dependent.

[Maged A. Mohamed]

Thanks for interest and probably also machine/driver dependent
Best regards

[dangerous]

Interesting that this is still an issue 6 months later. Is there a fix due?

I got caught by the bug:

Code: Select all

dim t0real,t1real as word
dim t1h, t1l, t0h, t0l as byte
const t0cnt as word = 4000    'counts required for tmr0
const t1cnt as word = 20000   'counts required for tmr1


'later in the program Interrupt is on tmr rollover so subtract counts from 0xFFFF

t0real = 0xFFFF - t0cnt   'gets counts before rollover (preload value)
t1real = 0xFFF - t1cnt
t1h = hi(t1real)
t1l = lo(t1real)
t0h = hi(t0real)
t0l =  lo(t0real)
'gets reload values for tmr0 & tmr1

Causes major issue with hi bytes of tmr0 and tmr1 as both get the low byte not the high byte
The cure is to change the first line to:

Code: Select all

dim t0real,t1real as word volatile

but I am unsure why it happens.
From other posts it seems that the way V6.6.2 handles literals in inline code is the issue, but t1real and t0real are variables that are assigned values at run time.

[janni]

From other posts it seems that the way V6.6.2 handles literals in inline code is the issue, but t1real and t0real are variables that are assigned values at run time.

As long as t1real and t0real are not declared volatile, they're not used in assignments that follow - constants are propagated to the other variables instead - with known consequences.

Interesting that this is still an issue 6 months later.

And not the only issue . Even easy to fix errors in processor definition files stay there untouched...