And a stranger feature ...

[Bertrand BAROTH]

I took my prog and modified it back, all numeric variables as Byte (no Word). This attached program has the error with PortD.7

[Bertrand BAROTH]

And now I modified it in lines 76 to 78 : I modified the order of the operators, putting the variables in leading position and the litteral at the end. And now ... IT WORKS !
I read some informations in the Help about operations, related with "Byte" or "Word" mode, and "casting" (in "Setting variables"). I suspect that the litteral in first place in the formula sometimes switches the compiler in a "wrong" mode, and that one should ever begin with variable names in a calculation ...

[Anobium]

I have found the bug based on your words in the post.

I need a really simple piece of code to test. This is the test.

#chip mega328p

'Test 1
numero_message_local = Marche_avant + gare + 1

'Test 2
numero_message_local = 1 + Marche_avant + gare

---

Test 1 produces valid ASM as follows:

;Test 1
;numero_message_local = Marche_avant + gare + 1
    lds SysTemp2,MARCHE_AVANT
    lds SysTemp3,GARE
    add SysTemp2,SysTemp3
    mov SysTemp1,SysTemp2
    inc SysTemp1
    sts NUMERO_MESSAGE_LOCAL,SysTemp1

Test 2 produces INVALID ASM as follows: Note the first lds systemp2 has no register. So, systemp2 is not initialised to a known state, then this unknown state is INCremented. Therefore, the calculation IS incorrect. Examination the ASM shows that the asm should be lds systemp2, MARCHE_AVANT - this would yield the correct result. I will resolve in the new compiler.

I have tried to define a workaround. One method at the moment is to move the constant to the end, or, another method to try (I cannot prove here, so please test for me) is to use method Test 3

;Test 2
;numero_message_local = 1 + Marche_avant + gare
    lds SysTemp2,
    inc SysTemp2
    lds SysTemp1,GARE
    add SysTemp2,SysTemp1
    sts NUMERO_MESSAGE_LOCAL,SysTemp2

---

'Test 3
numero_message_local = 1 : numero_message_local = numero_message_local = Marche_avant + gare

;Test 3
;numero_message_local = 1 : numero_message_local = numero_message_local = Marche_avant + gare
    ldi SysValueCopy,1
    sts NUMERO_MESSAGE_LOCAL,SysValueCopy
    lds SysTemp2,MARCHE_AVANT
    lds SysTemp3,GARE
    add SysTemp2,SysTemp3
    mov SysTemp1,SysTemp2
    lds SysBYTETempA,NUMERO_MESSAGE_LOCAL
    mov SysBYTETempB,SysTemp1
    rcall   SysCompEqual
    sts NUMERO_MESSAGE_LOCAL,SysByteTempX

[Anobium]

BUG FOUND: At releases prior to release v0.98.07 always add CONSTANTS at the end of the numerical calculation.

As follows: Where 1 is the constant.
numero_message_local = Marche_avant + gare + 1

This will fail to yield the correct result: Where the constant 1 is the first number in the maths calc.

numero_message_local = 1 + Marche_avant + gare

This issue is AVR only and does not impact the PIC.
I will look to resolve in v0.98.07 meanwhile alway put CONSTANTS at the end of the line of numeric calculations.

Anobium

[Anobium]

I have located the compiler code segment where the LDS instruction does not have a parameter - this is the error in terms of the ASM.

I need to work back through the compiler to understand why the compiler is not determining the source variable correctly.

@Bertrand. I will add a check in the compiler to catch this error. The compiler could issue an error message and then the user would be aware, and, the user can then resolve. Not nice but much better than no message and bad ASM.

[Bertrand BAROTH]

I am happy that I could contribute to resolve a bug ...
When can we expect 0.98.07 ?

[Anobium]

We are awaiting Hugh to complete the deep compiler changes. Then we can release. Not sure when - sorry.

[Anobium]

Issue is resolved in Great Cow BASIC v0.98.07 RC 22 or greater.