View previous topic :: View next topic |
Author |
Message |
whiskman Guest
|
Bug in simple expression!!! (PCWH v3.181) |
Posted: Fri Dec 19, 2003 1:30 pm |
|
|
There is a fatal bug in the compiler (last version). Compiler mistakes in a simple operation. Try this:
#define CONSTANT (byte)(.010 / .000185) // CONSTANT = 54 = 0x36
byte a, b;
void main()
{
a = CONSTANT - b;
}
Generated code (list file):
.................... void main()
.................... {
0002: CLRF 04
.................... a = CONSTANT - b;
0003: MOVF 0A,W
0004: BSF 04.5
0005: SUBWF 16,W
0006: MOVWF 09
.................... }
a and b are in ram locations 0x09 and 0x0A respectively.
Or even this: a = 54 - b;
Is a simple subtraction!!! There is a bug like this in the last version???
The right code should be (in pure assembler):
movlw CONSTANT
movwf temp
movf a,w
subwf temp,w
movwf b
Device used: PIC16C58B, compiler PCWH 3.181.
Seems like the compiler interprets the constant like a variable address or something
Any comments?? Regards.
- |
|
![](templates/subSilver/images/spacer.gif) |
MGP
Joined: 11 Sep 2003 Posts: 57
|
|
Posted: Fri Dec 19, 2003 1:37 pm |
|
|
What happens when you try the following?
#define CONSTANT 54
My guess is that the compiler is having trouble with the (.010/.000185) part. If I remember right, ANSI C says the calulations should use int math, unless otherwise specified. Not that PCWH is ANSI compliant anyway... |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Fri Dec 19, 2003 1:48 pm |
|
|
Is the same thing, you can put
#define CONSTANT 54
or even directly
a = 54 - b;
Compiler miskates anyway.
MGP wrote: | What happens when you try the following?
#define CONSTANT 54
My guess is that the compiler is having trouble with the (.010/.000185) part. If I remember right, ANSI C says the calulations should use int math, unless otherwise specified. Not that PCWH is ANSI compliant anyway... |
|
|
![](templates/subSilver/images/spacer.gif) |
Darren Rook
Joined: 06 Sep 2003 Posts: 287 Location: Milwaukee, WI
|
|
Posted: Fri Dec 19, 2003 4:45 pm |
|
|
Code: | .................... int8 a,b;
.................... a=CONSTANT-b;
0394: MOVF 3D,W
0395: SUBLW 36
0396: MOVWF 3C |
Thats what I get when I compile it. |
|
![](templates/subSilver/images/spacer.gif) |
whiskman Guest
|
|
Posted: Mon Dec 22, 2003 6:34 am |
|
|
You compiled the code using a devide other than PIC16C58B. The instruction sublw is no in intruction set of that device.
I omitted to say that the bug appears to be in PCB part of compiler.
Try compiling that code with PIC16C58B as the devide (or 16C5X). I found the bug using that device.
Regards.
Darren Rook wrote: | Code: | .................... int8 a,b;
.................... a=CONSTANT-b;
0394: MOVF 3D,W
0395: SUBLW 36
0396: MOVWF 3C |
Thats what I get when I compile it. |
|
|
![](templates/subSilver/images/spacer.gif) |
Jim Hearne Guest
|
Yup, 3.181 is buggy, so is 3.182 |
Posted: Mon Dec 22, 2003 6:44 am |
|
|
I had the same problem with 3.181, code that works fine compiled with 3.181 gave incorrect results with 3.182.
CCS said there was no known problems with 3.181, i emailed them the code and .lst files and 3.182 appears with "support for new devices" and the problem is fixed. Hmm.
I've gone back and checked, the same source works when compiled with 3.180 and 3.182 and not 3.181
This is on a 16F88
Unfortunatly there seems to be a new bug with 3.182,
The line
temp=read_adc(ADC_START_ONLY);
Won't compile with the error
A numeric expression must appear here -1 is not 0..65535
3.180 or 3.181 accepts this line.
Jim |
|
![](templates/subSilver/images/spacer.gif) |
whiskman Guest
|
|
Posted: Mon Dec 22, 2003 7:07 am |
|
|
The CCS compiler is simple to use and fine for small projects but I never would use it for big or complex projects, is made by a patch over another patch over another patch, and so on.
Is unacceptable that things that works in a version don't work in other, bugs that appears and dissapears between versions...
The source code of the compiler must be a total mess.
I thing they should stop getting new versions and rebuild entirely the compiler and then sell a WORKING AND SERIOUS VERSION!!!!. |
|
![](templates/subSilver/images/spacer.gif) |
Jim Hearne
Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK
|
|
Posted: Mon Dec 22, 2003 7:14 am |
|
|
It had been pretty good until 3.181/3.182, it's been a long time since i'd come across a compiler bug updating to the latest version.
A year ago i would go back to an older version of the compiler anytime something unexpected happened in the code, then if it still didn't work i'd check my code, nowadays it's normally me rather than the compiler.
Jim Hearne |
|
![](templates/subSilver/images/spacer.gif) |
Haplo
Joined: 06 Sep 2003 Posts: 659 Location: Sydney, Australia
|
|
Posted: Mon Dec 22, 2003 7:32 am |
|
|
Always keep the install file of the last 'stable' version in case you run into problems with the newest one. The compiler version 3.169 is the best so far in my opinion. |
|
![](templates/subSilver/images/spacer.gif) |
Jim Hearne
Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK
|
|
Posted: Mon Dec 22, 2003 7:39 am |
|
|
Haplo wrote: | Always keep the install file of the last 'stable' version in case you run into problems with the newest one. The compiler version 3.169 is the best so far in my opinion. |
Oh, i do but i like to update to the newest version as they add features and functions for the newest chips and i'm often using the latest chips.
Jim |
|
![](templates/subSilver/images/spacer.gif) |
Renato Guest
|
|
Posted: Mon Dec 22, 2003 7:52 am |
|
|
If the project is big, I thing that you must start and finish your project with the same version, and if a bug is found try to find a workaround (you can always do it). Changing between version makes the code unstable and unpredictable results. Remember that with big project is hard to test all after each change of version.
For small project we can try a couple of versions until get one working ok for it (if some problem is detected of course). |
|
![](templates/subSilver/images/spacer.gif) |
Gordon Guest
|
|
Posted: Mon Dec 22, 2003 10:52 am |
|
|
I tried the code with PIC16C57, PCWH 3.155 and the bug appears as whiskman says. Also with version 3.180 the error persists.
With PIC16C74 the compiler generates the correct code. Seems like the bug is for 12-bit units (baseline). |
|
![](templates/subSilver/images/spacer.gif) |
Jim Hearne
Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK
|
|
Posted: Mon Dec 22, 2003 3:46 pm |
|
|
Gordon wrote: | I tried the code with PIC16C57, PCWH 3.155 and the bug appears as whiskman says. Also with version 3.180 the error persists.
With PIC16C74 the compiler generates the correct code. Seems like the bug is for 12-bit units (baseline). |
That sounds like a different problem to mine then, i'm using a 16F88 with PCW and my code works perfectly in 3.180 or 3.182 but not in 3.181
The incorrect values are the result of a long sequence of operations and i've not got the time to track down and compare exactly where the error occurs unfortunatly.
Jim |
|
![](templates/subSilver/images/spacer.gif) |
|