| View previous topic :: View next topic |
| Author |
Message |
hayri
Guest
|
| struct - codesize problem |
 Posted: Wed Jan 12, 2005 4:24 am |
 |
|
i changed my working code and added 2 structs. even i didn't use them anywhere code size changed.
when i declared 2 structs(tolcum and olcumler) but i did NOT USE -> code size=961.
| Code: |
typedef struct {
int16 Sensor1;
int16 Sensor2;
} tolcum;
struct {
int8 DT1;
int8 DT2;
tolcum olcum[12];
} olcumler;
|
when i removed these -> code size=889
i didn't change anything else...
| Code: |
/*
typedef struct {
int16 Sensor1;
int16 Sensor2;
} tolcum;
struct {
int8 DT1;
int8 DT2;
tolcum olcum[12];
} olcumler;
*/
|
code compiled and worked succesfully with both of code pieces above.
why code size changed? i'm missing something. what is it?
(when i used 'olcumler.olcum[1].Sensor1=make16(Sensor1[1],Sensor1[0]' code size increased only 4 byte); |
|
 |
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Wed Jan 12, 2005 4:36 am |
|
|
| Quote: | | why code size changed? i'm missing something. what is it? |
You didn't mention the compiler version and processor type you are using, so we can't test your findings.
I tried this in v3.187 for a PIC18F458 and here the optimizer works great, for both your two examples the resulting code was small and unchanged. |
|
|
hayri
Guest
|
|
| Posted: Wed Jan 12, 2005 4:53 am |
|
|
thanks for reply.
| Code: |
typedef struct {
int16 Sensor1;
int16 Sensor2;
} tolcum;
tolcum olcumle[12];
|
also uses 961 bytes of rom. i guess that when 'tolcum' used elsewhere code size increases. It is not a problem because more than 1k memory avaible (pic16f628). |
|
|
hayri
Guest
|
|
| Posted: Wed Jan 12, 2005 2:54 pm |
|
|
hi,
(maybe new threads question)
i look asm code and it seems that compiler generating many ram bank switching. most probably variable locations changing. i put my codes header and 'null' main function. everything i compiled below.
forget everything above and look at this...
| Code: |
//compiled file exacty this.
#include <16F628A.h>
#use delay(clock=4000000)
#fuses NOWDT,INTRC_IO, PUT, NOPROTECT, BROWNOUT, MCLR, LVP, NOCPD
#use fast_io(A)
#use fast_io(B)
#define IntTimer1_Interval_Secs 30
#BYTE RCSTA = 0x18
#BIT OERR = RCSTA.1
#BIT CREN = RCSTA.4
byte sec,min,hour,day,date,month,year;
int8 cntr=0;
int8 Timer1_Int_Process=0;
int1 LCD_Clear_Req=0;
int1 ReadTemp_Done;
int1 ReadTemp_Req;
int8 buff[9];
int8 bufftest[2];
void main()
{
}
|
AND RESULTS:
---------------------------------------------------------------
ROM used: 13 (1%)
13 (1%) including unused fragments
0 Average locations per line
13 Average locations per statement
RAM used: 26 (15%) at main() level
26 (15%) worst case
---------------------------------------------------------------
015-016 CCP_1
015 CCP_1_LOW
016 CCP_1_HIGH
018 RCSTA
018.1 OERR
018.4 CREN
01F.6 C1OUT
01F.7 C2OUT
020 sec
021 min
022 hour
023 day
024 date
025 month
026 year
027 cntr
028 Timer1_Int_Process
029.0 LCD_Clear_Req
029.1 ReadTemp_Done
029.2 ReadTemp_Req
02A-032 buff
033-034 bufftest
077 @SCRATCH
078 @SCRATCH
078 _RETURN_
079 @SCRATCH
07A @SCRATCH
07B @SCRATCH
0004 main
0004 @cinit
------------------------------------------------------------
I didn't use sec, min, hour, day .... , buff[], bufftest[] anywhere.
but compiler reserved ram area for them.
How can i prevent this? |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Wed Jan 12, 2005 2:57 pm |
|
|
Don't stick them in there  |
|
|
Guest
|
|
| Posted: Wed Jan 12, 2005 3:11 pm |
|
|
good idea!!!
but they can move already declared variables to other banks and this situation can create many extra bank switchings. compiler creates more code than required, uses more memory then required. this is a last thing that ccs programmers may want. There must be an option to remove unused variables when preprocessing. |
|
|
hayri
Guest
|
|
| Posted: Wed Jan 12, 2005 3:20 pm |
|
|
| is compiler optimizes only code space or both rom and ram space ? locating variables to best-better positions, also optimizes the rom space. |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Wed Jan 12, 2005 3:22 pm |
|
|
Here is some suggestions on how to limit what you are seeing:
Try to limit Globals. The compiler will handle local variables and parameters better.
You can force variables to be in a certain section or at a specification location.
Although what you see as a big problem is probably not as bad as you think. You aren't going to get huge increases everytime you add a variable. The code size will change but only by a small amount. Once the bank switches are in there, adding more variables isn't necessarily going to add a bunch more bank switches. |
|
|
hayri
Guest
|
|
| Posted: Thu Jan 13, 2005 2:25 pm |
|
|
i agree. it doesn't matter which language you are using, if you use more variables, you will have more bank switchings.
Warnings about unused variables are important if compiler doesn't ignore them. Better, using a directive, precompiler may ignore unused variables -like unused codes- and may give warnings. |
|
|
Guest
|
|
| Posted: Sat Jan 15, 2005 11:14 pm |
|
|
| hayri wrote: | thanks for reply.
| Code: |
typedef struct {
int16 Sensor1;
int16 Sensor2;
} tolcum;
tolcum olcumle[12];
|
also uses 961 bytes of rom. i guess that when 'tolcum' used elsewhere code size increases. It is not a problem because more than 1k memory avaible (pic16f628). |
are you using #zero_ram ?
CCS did #zero_ram with very poor efficiency in ASM code like
olcumle[0] = 0;
olcumle[1] = 0;
olcumle[2] = 0;
...
instead of using loop.
look at your LST file |
|
|
hayri
Guest
|
|
| Posted: Sat Jan 29, 2005 10:04 am |
|
|
main problem shown in this topic is:
when you add global variables, structs compiler reserves some ram for them. Even you NEVER use them!
this means, more bank switchings, some wasted memory.
more bank switchings requires more "bcf .. , bsf .. " instuctions. as you see required code space for them can be high ratios (889/961 bytes shown above).
Ckielstra saying no changes on PIC18F458. yes, of course. because PIC18F458 has linear memory addressing and no bank switchings. Of course program size remain unchanged... But what about used memory size? is it still unchanged? No!
I believe, the best, compiler may ignore unused variables if programmer wants.
I think this is NOT a BUG. i think it comes from DESIGN.
as said by Mark above, trying to limit global variables and using local variables is the best program architecture even for PC programs. This program architecture is general, not related pics, ccs, c, c++, vb......
this is my last post in this topic. i don't want to say something unfair. this a GREAT compiler. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
