18F6722 possible math issue from compiler v5.074 to 5.105

pmuldoon · Joined: 26 Sep 2003 Posts: 218 Location: Northern Indiana

I've sent this off to tech support, but I thought you guys might spot something quicker.

I'm not sure if it's my code or a math issue with the latest compiler. My code worked fine in previous versions of the compiler.

The code compiled in 2019 worked and the code I recently compiled has the issue. From the dates of my compiler updates I
concluded it must be a difference between v5.074 and v5.105.

Unfortunately I don't save the lst files of previous iterations of code. Only the source & hex. And I've never had to try to compile with a previous version of the compiler, so I'm not sure how to do that. I'm hoping this might be enough to notice a problem with my code or the compiler.

This is the context of the problem line.
The intention is to calculate a count that would be a percentage of full-scale.
Default_SP[i] is a % of full scale of the adc count. range 0-100 with 255=unused.

With i=1 SP = 35 and I expect 1433 but get 20971. The lst is a bit overwhelming and I'm not confident I could read it well enough to spot a problem.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Make us a test program that fails.

I made this one and it gives me 1433.

pmuldoon · Joined: 26 Sep 2003 Posts: 218 Location: Northern Indiana

Hmm...well that's embarrassing!

I just copied your code into a test program and ran it thru PICSIM and mine worked, too.
I guess I should have tried that first, eh?

I will have to dig deeper. I was certain this is where the problem was being created.

Thanks PCM for helping me rule out this line of code. I guess I'll have to look at the other 3000 lines of code now, LOL.

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

FYI, the 'overwhelming' lst, is only a tiny part of the code involved.
The actual maths, is in the RCALL 3156, and the RCALL 30FA routines....
What you have posted is perhaps one tenth of the actual code... Sad

pmuldoon · Joined: 26 Sep 2003 Posts: 218 Location: Northern Indiana

Update:
Even though the short example version worked, the full program still did not.
I commented out the entire program and got it down to one line of code that would cause the failed calculation. So I got the enter program down to 2 lines in Main().

The first one was the LoadDefault() that had the math problem. The second was a TerminalCheck() function that checked for terminal activity and, if a key were pressed, would launch the terminal menu/interaction etc. I could uncomment all of the other code and it would calc properly as long as the TerminalCheck() remained commented out.

The TerminalCheck() contained a lot of functions and some of those functions called functions. So it had a lot of potential depth, although none of it actually executed because no key was ever pressed. I commented out it's contents and the calc worked again. Uncommented and it failed.

That was the point where I figured I was probably wasting my time and sent it off to CCS support. It seemed more likely to be a hidden issue within the compiler rather than the result of some awkward coding.

CCS responded remarkably fast with a patch. But, unfortunately, no explanation. I just sent a reply asking for a brief summary of what the problem was. I put a lot of time & effort into trying to figure out if it was me or the compiler, and in trying to narrow it down (and trying to create a simple test program). Hopefully they will respond with some info and I'll be a little smarter for it.

Bottom line: I'm glad the problem is behind me and CCS support is great! I just wish I could have posted a better answer here.

pmuldoon · Joined: 26 Sep 2003 Posts: 218 Location: Northern Indiana

response from CCS support:
"It was an optimization bug related to the CLRF instruction. A bank selection instruction was incorrectly removed.
It showed up when that statement used registers in both bank 1 and 2. When all the registers used where bank 1
it worked. #opt 0 should also have worked."

So, I guess it was because of the compound math statement. That would explain why, when I broke it down, it worked.

I totally get how that crazy bank switching can be complicated!!!

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

They seem to have done quite a few optimisation changes around 5.100,
suspect this is from then. These are what cause the problems for me
when using the multiple interrupt levels in PCD. before this local variables
in different priority interrupts respect each other, after this they don't.
Seems they are going a little too far on some of the 'savings'... Sad

pmuldoon · Joined: 26 Sep 2003 Posts: 218 Location: Northern Indiana

another one of my sources of confusion. This is right out of the CCS manual:

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

0 turns it off.

The point is that the problem is part of their optimisation, and they are
saying that if you use zero (so this is off), this isn't done.

kda406 · Joined: 17 Sep 2003 Posts: 97 Location: Atlanta, GA, USA

I cannot believe I ran into this thread today.

I have been having to simplify single, complex math statements down to 2-3-4 lines since around 5.09x, Ttelmah. Statements that have worked for years through 3,x, 4.x, even in other C compliers, suddenly no longer work in 5.x and must be rewritten.

Recently, I have been struggling with interrupts. I could not understand why ISRs that had worked for years with CCS and various PIC families no longer worked. Today an ISR for INT0 stopped working. I was troubleshooting that.

I noticed I was using optimization level 9 and could not remember if that was correct. I saw the same ridiculous explanation in the manual as was quoted above. I was confused so I searched the forum and found this thread where you are discussing the same issues I'm having today. Wow.

So I changed my #opt to 0 and guess what? The ISR for INT0 that I have been troubleshooting for 3 days magically works again. Mad

I cannot begin to total up all the lost-time troubleshooting, rewriting, and simplifying math code that used to work recently. I bet it is months of lost productivity. Frustrating! Mad

Even so, I say thanks for the helpful discussion guys.

-Kyle

temtronic · Posted: Fri Jan 28, 2022 6:13 am

I'm thinking, yeah..like the dinosaur I am.., that the 'optimization' default should be ZERO.
Only when a program is 'up and running', should 'optimization' be enabled, kinda like the WDT.

I'm betting no one KNOWS what happens for levels 1 thru 9, what exactly the compiler's doing or HOW it's doing it. Maybe level 4 is great for project 'x', and 7 perfect for project 'Z'.

It is scary that a feature designed to HELP programmers, actually can cause so much pain !

kda406 · Joined: 17 Sep 2003 Posts: 97 Location: Atlanta, GA, USA

Especially considering the recent "improvements", I agree, it should be zero unless set otherwise. Good idea.

Every one of my projects includes the same header file as the first element. I'm curious about using #opt 0 as a line there.

Here is why I ask about the inline directive though. I use multiple compile units (MCU) and my larger projects have dozens of program and header files. If your code is solid and elegant it works. I use MPLabX and love it - it's the same as NetBeans that I use for C and other languages mostly for programming Windows and Linux stuff. With MPLabX, you set the project up and hidden in the project is an assignment for code optimization. It defaults to 9. It passes this as a CL parameter to the compiler (and linker?) as it builds the project. The projects are setup automatically and I will need to remember to punch in and change the optimization parameter on every project. Sad

Do any of you know: If I put #opt 0 in the configuration header of every compile unit and MPLabX passes the default CL parameter of 9, which one will "win" and be used for the build?

Ttelmah · Joined: 11 Mar 2010 Posts: 19539

Hm. I'd have expected the ones 'in code' to override the ones on the build
line. However the answer would probably be to test. You can usually see
changes in the OPT level in the build size, so see if the code gets a little
larger with the optimisation turned down in code. If it does, you know
which has priority.

temtronic · Posted: Fri Jan 28, 2022 8:45 am

hmmmm I wouldn't guess (it'd be wrong...Murphy's Laws..)
yes, try a small program and see what happens...

kda406 · Joined: 17 Sep 2003 Posts: 97 Location: Atlanta, GA, USA

GOOD NEWS

I was hoping one of you guys could just tell me... Wink

This morning I'm working on a project with just a few compile units. No math to simplify like the OP for this thread, but this one does have the ISR routines that work with optimize set to 0 and simply do not work (at all) when set to 9.

I put #opt 0 as the first line of the single config header that is included in every compile unit. I made sure the project (IDE) was set for the default 9, and verified the CL arguments passed to the compiler included +Y=9.

In my experiment, the #opt 0 line takes precedence over the command line for PCH 5.107. That's good news for what temtronic mentioned above where the optimization could be different for different projects. This will allow us to embed the best optimization for a project right into the code. I believe that will be better than worrying about potential changes in our IDE affecting CL parameters in the future.

HTH,
Kyle