>= and others

[Linuxbuilders]

there are serious issues with equations like if (a >= b) or if (a > b), etc...

I have noticed it few times, the code compiles mad in such cases, if I use (a == b) then it works like a baby, main issue is 18F45j11, 18F4520 seems to be a bit better, I had issues with 16F690 too in this subject. I have noticed it a cross of many pics and it has nothing to do with a program, most simple comparation operations are killing whole program. I am not going to post any program for very simple reason, all vars are int, and it should work. It goes mad when it is long int but this I have managed to fix by doing double loops like this one:

[Ttelmah]

Seriously, first post your compiler version.
Bugs like this, were 'common' with the early 4.xxx compilers, but on the 'mainstream' chips (PIC16/18), I have not seen anything like this in ages, _except_ for 'user error', with things like size of variables, numbers using unsigned types, and then going -ve, etc. etc...

Best Wishes

[temtronic]

Have you contacted CCS with the type/version of your compiler and a very small program that shows the problem? Is the problem specific to only some PICS? Perhaps to just a certain version of the compiler?

Telling us here is nice but please email CCS so they can look into it and 'patch' the compiler as required.
It is not uncommon for a new PIC's die to have a 'problem', so Microchip will release 'errata' info.This is a hardware issue, not the compiler.

As for the compiler being 'buggy', you should have been around when the Radio Shack TRS80s came out. Every two weeks they sent out a letter with 'patches' to the OS requiring you to use a diskeditor to fix it.Any typo on your part could and did create havoc!CCS has invested tens of thousands of manhours in their products that are very affordable.I've never met a code cutter who wrote a perfect program the very first time and I've been doing this since 1975.
I do not 'upgrade' any software unless there is a specific need on MY part.This includes, compilers,operating systems,etc. Just because 'they' upgrade doesn't mean the code will run on my system.Some upgrades only work for newer chips.When I do, I make sure I backup the previous and can return to it, if(when?) the new version fails!

[PCM programmer]

Don't post your "fix". Post a test program that shows the problem.
Also post your compiler version.

The test program should have the #include for the PIC, #fuses, #use
delay(), all necessary variable declarations, main(), and test code.
It should be as short as possible (No "wizard" code, if not needed to
show the problem).

[Linuxbuilders]

4.107, the funny thing is that I have downloaded an upgrade 114 and then what? then software which work on 107 without any problem on 18f4520 does not work on 114, I do not know what to think any more. It is like a ccs playground but on my cost...no fun no go...I think I will freeze my a... to one stable version and keep it going as long as possible, so far as it goes CCS is changing into Apple and Microsoft and lost all of its stability and trust, uses customers as testing ground.
_________________
Help "d" others and then you shell receive some help from "d" others.

[FvM]

[JoeR]

Hi,

I have this issue on PCH 4.073 on a PIC18F4550 with USB.

A simple test like "if (t3 > event_boundary)"
returns true when t3=-7 and event_boundary = 5

t3 and event_boundary are longs

Which version fixes these issues???

I do not really want to change compilers I have too much work invested, and this is my last problem. I managed the program down to 83% space.
I am trying to see what else I can eliminate to free up space.

any work arounds???

I've been chasing this for days, and its maddening.

Thanks.

[Ttelmah]

It would, and it'd be right!....
A 'long', is unsigned.
-7 represented as an unsigned number, is 0xfff9, which _is_ larger than 5.

This is exactly the sort of thing I was 'expecting'. Wrong choice of number types, and not understanding the limitations these impose.

Best Wishes

[JoeR]

Oh geez, you're right. In my old age, my eyes did not parse the help file correctly. I will define the values properly and I am sure it will work right using signed values....

Sorry for the noise.

[5440]

So is this <= or >= statements a known bug?

I don't use any CCS functions as I like to roll my own.

I'm using 4.106 on a PIC18F2585 and finally found a "random" issue with my code that is currently only uses 3% ROM that involves a <= statement.

If I use an == statement, all seems fine, but my code will be less reliable in the future.

[PCM programmer]

If you want help, post a test program. Complete, but short, and that
compiles with errors. By complete, I mean it has the #include for the PIC
and the #fuses, and the #use delay, and all variable declarations and
#define statements, and a main().

The shorter, the better. Don't put in anything that isn't needed to show
the problem.

[SherpaDoug]

[scottc]

I am using 4.116 and do see some weirdness with operators => and <=.

I don't know if its a bug but I have seen this before. Honestly I never really
paid attention to it as I could find a way to make my code work.

Here is an example of a small routine that works fine. KHZ is a INT Variable.

[PCM programmer]

Look at a list of valid C operators:
http://academic.evergreen.edu/projects/biophysics/technotes/program/c_ops.htm#relational

[scottc]

Yep operator is not valid, should use

<= Less Than Or Equal To

Or

>= Greater Than Or Equal To

Code compiles fine

Thank You PCM