I am seeing at least 2 bytes of data memory being allocated for every function called. If the function calls other functions it could mean a whole lot of bytes being allocated.

I don't remember this behavior in HiTech. Perhaps I never looked before so just did not notice it. Now I am short on memory so looking for every byte. What is the purpose of the 2 bytes? I thought stack was on program memory? Is it used for a pointer?

The sprint function takes a whooping 28 bytes of data memory! I always knew that sprintf was program memory hungry put 28 bytes of data memory!

 

Saving the W and the STATUS registers. Can you determine if these are static allocations or something else? What I mean is that if there are a total of 26 functions then regardless of any other consideration 52 bytes of data memory are allocated. If any functions have explicit or implicit recursion then this approach fails. If the allocations are dynamic from a heap, then you have a better situation, but now depending on the PIC family you will run out of RETURN address locations on the stack.

 

I am declaring the variables static within functions so they are on the stack. I guess I was remembering wrong as I thought the stack was in program memory and not data memory.

But I am still trying to figure out where the memory is still going. Any isea if there is a profiler for mplabx? I see a plugin but looks like you need the Real ICE emulator.


My chip is the 18f45k22 btw.

 

In general declaring the variables static within functions puts them on the data heap.
http://www.inf.udec.cl/~leo/teoX.pdf

 

Is this the free version of XC8?
The free version is deliberately hobbled as far as program memory goes. I don't know whether that applies to data memory too.
Try the free trial of the pro version and compare the program and data memory usage.

 

If you know PIC assembly language you could look at the output in the 'LST' file to determine how the memory is being used. It's amazing how much memory the library routines use. I remember gaining nearly a thousand bytes of program memory by simply replacing a routine containing several integer multiply and divide instructions with a simple assembly language bin2bcd routine.

Good luck on your project. Cheerful regards, Mike

 

Is this the free version of XC8?
The free version is deliberately hobbled as far as program memory goes. I don't know whether that applies to data memory too.
Try the free trial of the pro version and compare the program and data memory usage.

There is no mention of memory limitation in the free version of XC8. Just code optimization. .

 

Oh my goodness... You don't think that's a memory limitation?

 

Oh my goodness... You don't think that's a memory limitation?

In this case no. I am actually using that memory somewhere and slowly whittling it down. I don't think there is a limitation actually.

 

There is no mention of memory limitation in the free version of XC8. Just code optimization. .

Well, they wouldn't shout about it would they.
For imstance: https://www.google.co.uk/url?sa=t&r...gDbtlV6MGBbWR-wgtNPWGA&bvm=bv.149397726,d.d24

 

Well, they wouldn't shout about it would they.
For imstance: https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwi3zv_ZuM_SAhXjI8AKHbpZCcsQFggaMAA&url=http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/&usg=AFQjCNGFf0U_gDbtlV6MGBbWR-wgtNPWGA&bvm=bv.149397726,d.d24

I am not seeing anywhere where the article mentions data memory limitations. It discusses the efficiency (or inefficiency) of the compiler. Those are already accepted to get the free version.

 

I am not seeing anywhere where the article mentions data memory limitations. It discusses the efficiency (or inefficiency) of the compiler. Those are already accepted to get the free version.

Perhaps you should read what I said.

 

Perhaps you should read what I said.

You didn't say anything other than the fact you seemed to be challenging my claim that Microchip does not mention a data memory limitation. That is the subject.

 

See post #5 and try the suggestion.

 

See post #5 and try the suggestion.

My code is actually using that data memory. Or functions like printf are. My have been able to reduce my data memory allocation from 51% down to 35% and working on reducing it a bit more.

 

I would be happy to look at your code and the compiler output if you'd like to PM me...

 

I would be happy to look at your code and the compiler output if you'd like to PM me...

Thanks but I think I might have it handled. I am sure the compiler output is very inefficient. The article albert posted makes it least appear they are making it purposely bloated.

I might look at start using the SDCC compiler

http://sdcc.sourceforge.net/

 

Thanks but I think I might have it handled. I am sure the compiler output is very inefficient. The article albert posted makes it least appear they are making it purposely bloated.

I might look at start using the SDCC compiler

http://sdcc.sourceforge.net/

That article while factually correct then (a much older version) is misguided on opinions about the current release.

The old compiler generated general code before having allocated addresses for variables so it looks like crap. The full compiler optimizes away the unneeded instructions in a later pass. The current versions have enabled some of the less exotic PRO optimizations in the free version to make it less of a turd.
I won't expect to see compiler optimizations of data space on well written C programs to be more than a few percent in PRO mode.
http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINAL.pdf

Typical GCC type optimizations.

 

Is this true in the free version of XC8 too?

 

Is this true in the free version of XC8 too?

Is what true? The free version doesn't have Omniscient Code Generation.

In some older versions these were added:
New Free-mode optimization An additional optimization has been added to improve removal of redundant bank selection instructions when using Free mode. The effect of this optimization will only be observable when the assembler optimizers are enabled.

New Free mode optimizations The assembler's jump-to-jump optimizations, which previously was only available with a licensed compiler operating mode, is now available in Free mode. By default, this optimization is disabled, but it can be enabled from the --OPT option or the Optimization category in MPLAB X IDE in the usual way. If enabled, this optimization reduced the size of code output by the compiler.