CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support
Bad macrodef or bug 4.104 ?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Torello



Joined: 29 Sep 2006
Posts: 120

View user's profile Send private message

Bad macrodef or bug 4.104 ?
PostPosted: Fri Jan 29, 2010 6:29 am     Reply with quote
Hi,

Using the following definition quite a while:
Code:

#define dStrLd1(Dest,a)         (Dest[0]=a, 1 )
#define dStrLd2(Dest,a,b)       (Dest[0]=a, Dest[1]=b, 2 )
#define dStrLd3(Dest,a,b,c)     (Dest[0]=a, Dest[1]=b, Dest[2]=c, 3 )
#define dStrLd4(Dest,a,b,c,d)   (Dest[0]=a, Dest[1]=b, Dest[2]=c, Dest[3]=d, 4 )
#define dStrLd5(Dest,a,b,c,d,e) (Dest[0]=a, Dest[1]=b, Dest[2]=c, Dest[3]=d, Dest[4]=e, 5 )


Handy to efficient load a few charaters in a string. Also wasn't indirect addressed by the compiler so far. Macro also returns number of characters that are set.

Anyway 4104 really make a mess of this. Below the two compilation fragment. 4103 is working 4104 is blurish.

My question: is my macrodefinition Ok ?
If not better are welcome Very Happy

Code:

v4.103
... dStrLd3(flash.dbuffer,'T','9',',');  //line start
11ACC:  MOVLW  54
11ACE:  MOVWF  5B
11AD0:  MOVLW  39
11AD2:  MOVWF  5C
11AD4:  MOVLW  2C
11AD6:  MOVWF  5D


v4.104
... dStrLd3(flash.dbuffer,'T','9',',');  //line start
0BDD6:  CLRF   FEA
0BDD8:  MOVLW  64
0BDDA:  MOVWF  FE9
0BDDC:  MOVLW  39
0BDDE:  MOVWF  FEF
0BDE0:  MOVLW  2C
0BDE2:  MOVWF  5B
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Jan 29, 2010 12:15 pm     Reply with quote
Post a small compilable test program that produces that code.
(Small = Less than 20 lines).
mbradley



Joined: 11 Jul 2009
Posts: 118
Location: California, USA

View user's profile Send private message Visit poster's website

PostPosted: Fri Jan 29, 2010 3:29 pm     Reply with quote
Just curious, should it not be like this:

Code:

#define dStrLd1(Dest,a)         {Dest[0]=a; 1 }
#define dStrLd2(Dest,a,b)       {Dest[0]=a; Dest[1]=b; 2 }

_________________
Michael Bradley
www.mculabs.com
Open Drivers and Projects
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Sat Jan 30, 2010 3:25 am     Reply with quote
Quote:
should it not be like this

More or less, the purpose of the trailing 1, 2, 3 is still unclear.
I agree with PCM programmer, that we should better see a complete code.
Ttelmah
Guest
PostPosted: Sat Jan 30, 2010 5:08 am     Reply with quote
There are some features that are a little potentially dangerous, but it should work...

If for any operation expecting a 'value' back, you put two operations one after the other, separated by a ',', C evaluates the first operation, then the second, and returns the value from the second.
So:
Code:

int16 a,b=10;

a=(b*=2,b+1);

Will make b=20 (10*2), and a=21.

In the code shown, the last number is the value 'returned' (the number of characters), which is then thrown away.

Now there are lots of warnings associated with this, since it is very easy to end up with things evaluating in a different order to what you expect. The function is only 'defined' as working, with one pair of values, so if you want to 'guarantee' that you receive the last value, you should bracket the pairs of operations.

However for an example, simplifying it a lot:
Code:

//Choose any PIC18, and oscillator fuses here
#define dStrLd3(Dest,a,b,c)     ((Dest[0]=a, Dest[1]=b, Dest[2]=c), 3 )

struct {
   int16 val;
   char dbuffer[20];
} flash;

char dbuffer[20];

void main()
{
   int8 dummy;

   dummy=dStrLd3(dbuffer,'T','9',',');  //line start
   
   dummy=dStrLd3(flash.dbuffer,'T','9',',');  //line start
   while (true) ;
}


This fails exactly as originally reported, both for a structure, and for a simple char array.
It appears that 4.104, is trying to set up table addressing, then failing completely...

Every older compiler I have tried (4.070, 099, etc.), all evaluate the statement as expected.

So, with the 'caveats' about the definition, I'd report this to CCS. It is a bug.

Best Wishes
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Sat Jan 30, 2010 6:34 am     Reply with quote
Thank you for remembering the purpose of the comma operator. The original code makes sense now.

It's not the first V4.104 bug invalidating basic C syntax, there has been also an issue with typedef.
Torello



Joined: 29 Sep 2006
Posts: 120

View user's profile Send private message

PostPosted: Sat Jan 30, 2010 7:34 am     Reply with quote
Hi all,

Thanks for the comment. Ttelmah, good idea to use the brackets. Absolutely more readable and less prone for mistake.

I've reported the bug to CCS. Waiting for an answer.

I've come up with this macrodefine to efficient load a string with a few characters. CCS will do mostly with indirect addressing while it not always needed.

Anyway, I've thrown out this macro. I hope the CCS compiler will become stable again. Since 4093 bug over bug over bug. I'm really terrified to compile my changed 11000 lines source evertime a new version is out.

I'll post CCS reaction.

Regards,
Edwin.

A Pic flying high in the Sky...
http://home.medewerker.uva.nl/e.w.baaij/page2.html
Ttelmah
Guest
PostPosted: Sat Jan 30, 2010 9:27 am     Reply with quote
It is perhaps reiterating the old comments about CCS versions.

Don't habitually upgrade, just because an upgrade exists.
Unless you actually 'need' a feature in a new version, stick with the old one....
When you build a project using a particular version, and make a backup, include the compiler version _with_ the code.
New CCS releases are not even fit to be seen as 'beta' releases. Generally, 'poor alpha'.

If you bear these in mind, when using CCS, like is a lot easier....

Best Wishes
Torello



Joined: 29 Sep 2006
Posts: 120

View user's profile Send private message

PostPosted: Sat Jan 30, 2010 10:06 am     Reply with quote
Well I sure will keep my 4093 installed.

But in a project that is running for 3 years now, and probably more to go, I don't like the idea either to stay put. In that case I would still be stuck on version ? <4. And then getting support (forum of CCS) will probably end up with the strong advise to upgrade to the newest version.

little off topic:
Some credits; CCS has done remarkable string optimization. I develop/debug my project in 3 stages: (1)Testmode, (2)Normal ops + serial debug -output- only, and (3) Normal ops. Testmode has a lot of strings. In my case the optimization saves me 12% for testmode and 2% for normal ops.

    CSS_v4093:
    Mode 1: Rom 70%, RAM 34% (48% worst case)
    Mode 2: Rom 64%, Ram 33% (37%)
    Mode 3: Rom 47%, Ram 33% (37%)

    CSS_v4104:
    Mode 1: Rom 58%, RAM 34% (48% worst case)
    Mode 2: Rom 57%, Ram 33% (37%)
    Mode 3: Rom 45%, Ram 33% (37%)


Best wishes,
Edwin.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group