 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Emil
Guest
|
| BIT_CLEAR() generating a lot of code |
 Posted: Tue Nov 09, 2004 8:33 am |
 |
|
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 |
| Posted: Tue Nov 09, 2004 9:14 am |
|
|
| 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
|
|
| Posted: Tue Nov 09, 2004 10:15 am |
|
|
| 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
|
|
| Posted: Tue Nov 09, 2004 10:23 am |
|
|
| 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
|
|
| Posted: Tue Nov 09, 2004 11:28 am |
|
|
and when you don't like how the compiler did it,... use #asm .... #endasm
 |
|
|
Guest
|
|
| Posted: Tue Nov 09, 2004 3:52 pm |
|
|
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
|
|
| Posted: Tue Nov 09, 2004 4:01 pm |
|
|
| 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
|
|
| Posted: Tue Nov 09, 2004 4:57 pm |
|
|
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". 
Regards,
Humberto  |
|
|
Guest
|
|
| Posted: Wed Nov 10, 2004 4:29 am |
|
|
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
|
|
| Posted: Wed Nov 10, 2004 7:22 am |
|
|
| 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
|
|
| Posted: Sun Nov 21, 2004 2:32 am |
|
|
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
|
|
| Posted: Mon Nov 22, 2004 10:12 pm |
|
|
| If you write this code, you are changing the value of the address, not what the adress points to |
|
|
Ttelmah
Guest
|
|
| Posted: Tue Nov 23, 2004 9:01 am |
|
|
| 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 |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
