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

BIT_CLEAR() generating a lot of code

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







BIT_CLEAR() generating a lot of code
PostPosted: Tue Nov 09, 2004 8:33 am     Reply with quote

Hi!
I have a problem with the BIT_CLEAR(), BIT_SET() built in functions and that is that they produce large amount of code. In best case it ends up with 5 instructions and in worst case 12 instructions. This is verry bad when you living on the edge regarding ROM usage. How can I override the built in functions or tell the compiler not to inline them? Since I dont whant to rewrite the code since ther is no time for that.

//Emil
Ttelmah
Guest







Re: BIT_CLEAR() generating a lot of code
PostPosted: Tue Nov 09, 2004 9:14 am     Reply with quote

Emil wrote:
Hi!
I have a problem with the BIT_CLEAR(), BIT_SET() built in functions and that is that they produce large amount of code. In best case it ends up with 5 instructions and in worst case 12 instructions. This is verry bad when you living on the edge regarding ROM usage. How can I override the built in functions or tell the compiler not to inline them? Since I dont whant to rewrite the code since ther is no time for that.

//Emil

I'd have thought that for the smaller case given, forcing them to be seperate, will acually be bigger (the compiler would then need to get the value, transfer it to the scratch register, then execute a call). I'd expect that a lot of the size for the bigger examples, is bank switching code. If this is the case, the biggest saving, might be in selecting the locations of the registers carefully, so that the commonest ones are in the first bank.
You can force any inline function f this sort to be seperate, by just putting it in a 'wrapper' function, and declaring this as #seperate. Normally in C, bit_clear, and bit_set, are declared as macros, not as functions at all, and will therefore always be 'inline'.

Best Wishes
Humberto



Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata

View user's profile Send private message

PostPosted: Tue Nov 09, 2004 10:15 am     Reply with quote

Quote:

Hi!
I have a problem with the BIT_CLEAR(), BIT_SET() built in functions and that is that they produce large amount of code


Not sure what are you talking about but

bit_set(var,0); >>>>> bsf 3A.0
bit_clear(var,0); >>>> bcf 3A.0


produce one single line of code.

Tested in 16F877 ROM 97% RAM 68%

Humberto
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Tue Nov 09, 2004 10:23 am     Reply with quote

Quote:
Not sure what are you talking about but


Quote:
I'd expect that a lot of the size for the bigger examples, is bank switching code.
treitmey



Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA

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

PostPosted: Tue Nov 09, 2004 11:28 am     Reply with quote

and when you don't like how the compiler did it,... use #asm .... #endasm
Smile
Guest








PostPosted: Tue Nov 09, 2004 3:52 pm     Reply with quote

How about giving us a quick sample of the actual usage and supplying the compiler version and processor.

I don't have access to my compiler in this location, but I could imagine that a bit set or clear of a port pin could take a few instructions if you are using standard io since the processor must clear the appropriate bit in the tris register before setting or clearing the pin. Also in most cases the port c tris register is not accessed directly but rather through a mirror copy that is manipulated then copied as a whole to the c tris register, then the port pin would need to be set or cleared as required.
Ttelmah
Guest







PostPosted: Tue Nov 09, 2004 4:01 pm     Reply with quote

Humberto wrote:
Quote:

Hi!
I have a problem with the BIT_CLEAR(), BIT_SET() built in functions and that is that they produce large amount of code


Not sure what are you talking about but

bit_set(var,0); >>>>> bsf 3A.0
bit_clear(var,0); >>>> bcf 3A.0


produce one single line of code.

Tested in 16F877 ROM 97% RAM 68%

Humberto

To my mind the possibilities are that the 'bit' being selected is a variable, and/or that the variable being accessed is itself an array, with a variable as an index. These would explain the different sizes the poster is reporting. The problems are though that in the second case, the access to talk to the required byte in the array would still happen if the bit function was seperate. While in the first case, the overhead is still less than is involved in setting up a call.
If you then assume that the two variables are in different banks, you have bank switching as well... :-(
I think the questioner, is not actually realising what is making the 'size', with it not being the bit set/clear functions as such, hence the difference shown in your example....

Best Wishes
Humberto



Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata

View user's profile Send private message

PostPosted: Tue Nov 09, 2004 4:57 pm     Reply with quote

Ttelmah wrote:

Quote:

I think the questioner, is not actually realising what is making the 'size', with it not being the bit set/clear functions as such, hence the difference shown in your example....


Ttelmah, thanks for focusing where I guess the real problem is.
Meanwhile we are still waiting that Emil post a more detailled example
of the "offensive code". Confused

Regards,

Humberto Very Happy
Guest








PostPosted: Wed Nov 10, 2004 4:29 am     Reply with quote

Yes, Ttelmah is right. The bit that is selected is a array variable and the index is a variable in it self. So I was happy whit the first respons. I am new to PIC programming so I'm still lerning. Have been programming AVR's before and I love them. This is a huge project that I have taken over resently at my new work. So have to dig in to it. It consist of several processors communication with eachother and there is a lot of work to do on it.
//Emil
Ttelmah
Guest







PostPosted: Wed Nov 10, 2004 7:22 am     Reply with quote

Anonymous wrote:
Yes, Ttelmah is right. The bit that is selected is a array variable and the index is a variable in it self. So I was happy whit the first respons. I am new to PIC programming so I'm still lerning. Have been programming AVR's before and I love them. This is a huge project that I have taken over resently at my new work. So have to dig in to it. It consist of several processors communication with eachother and there is a lot of work to do on it.
//Emil

The 'worst kind' of project. :-(
If history is anything to go by, the original programmer, will have been of the school that believes documentation/comments are rude words...
Assuming this is a '16' chip, some significant savings may be made by optimising the register placements. Some suggestions about this, and methods to approach it, may be found in the old group archives. I'd also suggest that you may be able to save some space/time by using alternative approaches to things (the order in which arrays are accessed, using 'preloaded' pointers, rather than array references etc. - for example, if you load a pointer with the address of the first element in an array, and move through the array by incrementing the pointer, this is slightly quicker in each loop, than solving for a new address each time round the loop - but may be larger). Some constructs that look large in code, can be very efficiently optimised by the compiler, while other small items can be very large. If (for instance), you build quite a complex arithmetic construct, using constants, the compiler knows to work this out 'in advance'. However the same construct using just one variable, has to be coded, and will become massive...
Learning what tends to be 'bulky', is an art. One 'classic', is arithmetic, where it is much more efficient to use scaled integers, than to use floating point, and for many 'sampling' applications, where the values are in a fixed range, gives better results.
Good Luck with your work.

Best Wishes
leonake



Joined: 20 Nov 2004
Posts: 1

View user's profile Send private message

PostPosted: Sun Nov 21, 2004 2:32 am     Reply with quote

my advice: build your own functions and directives

#define setbit(x, y) x|= 1<<y
#define clrbit(x, y) x&= !(1<<y)

where x-byte, y-bit

Ciao
Guest








PostPosted: Mon Nov 22, 2004 10:12 pm     Reply with quote

If you write this code, you are changing the value of the address, not what the adress points to
Ttelmah
Guest







PostPosted: Tue Nov 23, 2004 9:01 am     Reply with quote

Anonymous wrote:
If you write this code, you are changing the value of the address, not what the adress points to

No.
Addresses don't come into the code as posted. The '&' there, is a bitwise 'and' operator, and the functions are perfectly acceptable. However as has already been found out, the size, was not coming from the bitwise operators, but the code needed to actually 'get to' the variables concerned...

Best Wishes
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