Interpreting memory usage statistics in .asm file

[Rusttree]

I compiled a program using SDCC, which reports the following statistics at the bottom of the asm file:

; Statistics:
; code size: 34916 (0x8864) bytes (26.64%)
; 17458 (0x4432) words
; udata size: 3165 (0x0c5d) bytes (82.42%)
; access size: 37 (0x0025) bytes

This is for an 18F67J60, which has 128k of program memory and 3.8k of RAM.

"Code size" is obvious, but I'm a little confused about "udata size" and "access size". Does udata refer to all of the space reserved for global variables? If so, does that mean I have only 635 bytes left for the stack during runtime?

The SDCC user's manual doesn't seem to cover these statistics.

 

[Pommie]

I would assume that the compiler allocates a suitable block of memory for the stack and that is included in the udata area. Try compiling an empty file (just main and a while loop etc) and see what the statistics are.

Mike.

 

[Ian Rogers]

Its a pic related thing.... I can just get my head round it. I use C18 and UDATA and IDATA can at best be a pain,,, UDATA (if you don't already know) is uninitialized data were as IDATA is..... Initialized. With C18 I keep getting (out of memory) errors when I clearly have plenty ( pic18f4620 ) In C18 I can declare two pages in memory as "BIG" and point my UDATA to it I then have oodles of UDATA space.

I used SDCC once, but the pic16 port was too buggy for me. I have moved to the C18 which is also free (student edition) No problems now as the documentation is much, much better.

Ian

 

[Rusttree]

Did what you suggested, Pommie, and it looks like your assumption is probably pretty close to truth. As I created small functions with local variables, the udata size got larger. That indicates udata does reflect the stack. However, creating global variables didn't affect udata. So there's still something I'm missing. But I'm less concerned now, as I'm not worried about running out of stack space in my program.