For Loop Issue

[flyway38]

Hello all,

Have found an odd issue.

Maybe me not doing it right, but need to ear from you about it.

Here's the code:

      for nSmsCenterPhone using Index loop
          SmsCenterPhone[Index+1]=data_eeprom(Index+n)+48
      end loop

Situation is; I need to start filling array SmsCenterPhone[20] starting from 2nd byte [1].

It fails and don't understand why.

EEprom data is ok. Have double checked it.

Have found that it works if I don't add +1 do Index to SmsCenterPhone[Index+1], but would like to understand why this is happening.

Thank you very much.

Kind regards,

Filipe Santos

[flyway38]

Heres the issue in a different form:

This code works:

      for nSmsCenterPhone+1 using Index loop
          SmsCenterPhone[Index]=data_eeprom(Index+n)+48
      end loop
      SmsCenterPhone[0]=data_eeprom(n)                        -- Insert "+" @[0]

This should work and the same, but no... it doesn't work.

      SmsCenterPhone[0]=data_eeprom(n)                        -- Insert "+" @[0]  

     for nSmsCenterPhone using Index loop

          SmsCenterPhone[Index+1]=data_eeprom(Index+n+1)+48
      end loop

Very odd issue.

Any ideas?

Thank you.

Cheers,

FS

[Rob CJ]

Hi Filip,

No idea. I need to see if I can reproduce this.

Of what type are Index and n? What is the value of n?

Thanks

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens flyway38 <fsfo...@gmail.com>
Verzonden: vrijdag 16 december 2022 19:34
Aan: jallib <jal...@googlegroups.com>
Onderwerp: [jallib] Re: For Loop Issue

 

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/a5e8729b-7dc4-4f2d-904f-7950f3b3d05cn%40googlegroups.com.

[flyway38]

Hi Rob,

Thanks for your support.

Both vars are bytes.

Cheers,

FS

[flyway38]

Missed this information above.

n goes from 0 to something like 20, and nSmsCenterPhone is also a byte and assumes 12 in this case.

[Rob CJ]

Hi Filip,

The problem with these kind of issues is finding the reproduction scenario. I made one and found indeed a problem which might be a compiler issue.

Attached you find a test program that I made to reproduce your issue. There are 6 test and test number 5 goes wrong (when counter is not equal to 0) and a workaroud is given in test 6 by using a temporary variable. The output of test 5 and test 6 should have been the same but it is not, see screenshot below.

 

I need to analyze this further to see where the compiler goes wrong. For now your problem could be fixed by using a temporary variable. Please give it a try and let me know if it solves your problem.

Thanks.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens flyway38 <fsfo...@gmail.com>

Verzonden: vrijdag 16 december 2022 22:46
Aan: jallib <jal...@googlegroups.com>
Onderwerp: Re: [jallib] Re: For Loop Issue

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/adb14af6-a36e-4440-9c9d-14d69514636fn%40googlegroups.com.

[Rob CJ]

Hi Filipe,

I did some analysis and it seems to be a compiler issue. I registered the issue under: https://github.com/jallib/jalv2compiler/issues/26

Problem when incrementing index and using index directly in a function call · Issue #26 · jallib/jalv2compiler Given this code -- This goes wrong. print_string(serial_hw_data, "Test 1 must show C to J : ") for (MY_ARRAY_SIZE - 2) using index loop variable_array[index + 1] = data_eeprom(index + 1) ... github.com

I also added the analysis where the problem is visible in the assembly code. Maybe too much detail but handy for later.

I was working on another compiler issue (#25) but got it only partly solved and now I am stuck with the part that is not yet working correctly. 

Maybe I will have a look at this issue later. For now the workaround works, which is also shown in the analysis.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob CJ <rob...@hotmail.com>
Verzonden: zaterdag 17 december 2022 11:33
Aan: jal...@googlegroups.com <jal...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/GVXP195MB1637CA9F2DBE49FAB7B1C589E6E79%40GVXP195MB1637.EURP195.PROD.OUTLOOK.COM.

[flyway38]

Hello Rob,

Thank you for your time on this issue.

Don't worry much. Take your time.

As I said above, have also found another way of reaching the same result with a code not much different.

So, for me its a solved issue for now. But understand you in raising new compiler issue as it should be addressed in future for a better compiler.

Thank you very much.

Cheers,

FS

[Rob CJ]

Hello Filip and other Jallib users,

I found out that the problem is caused by the fact that the pic_data_eeprom library is using 'inline' statements for all procedures and functions.

When I remove those, it all works fine.

So the compiler has an issue with the use of 'inline' in this specific situation since it does not always happen.

I can do 2 things:

1. Analyze the compiler issue with the use on 'inline' for this specific situation and solve it.
2. Adapt the pic_data_eeprom library by removing all 'inline' statements.

Options 2 is the quickest but I will have a look at option 1 too.

I wonder why this libarary uses 'inline' statements since in my opinion (but please share your thoughts on this) you would use 'inline' only in situations that require high speeds (since a call is replaced by putting the actual code in) or is there another reason to use it?

Let me know if you are OK by temporary removing 'inline' from this library or wait for option 1). 

I updated the compiler issue with this latest update.

Thanks

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens flyway38 <fsfo...@gmail.com>

Verzonden: zaterdag 17 december 2022 20:29

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/5e3c6661-db05-475d-992f-24617058da52n%40googlegroups.com.

[flyway38]

Hello Rob,

In my opinion and assuming I am done about this issue with a good option code, would vote for #1.

Don't know what about other users of this LIB, so... maybe wait some more time to formulate a decision.

Thank you for your efforts.

Cheers,

FS