CCS compiler hidden RAM requirements

[drdailey]

Hello all,

I'm currently developing on a 18F6520 using the PCH v4.005 compiler. I've been trying to figure out exactly how the compiler uses RAM for scratch memory and the like. If there is any formal documentation on this, I haven't seen it.

First off, the compiler reserves RAM locations 0x000 through 0x004 for function return values (it can also use these for scratch locations, but return values are always placed here). The compilerisnice enough to give you an error message explaining this if you try to force a variable into this area.

I found that the compiler also uses RAM locations for the storage of various SFRs during its built-in ISR routines. What I find annoying is that the location for this array is just placed somewhere in free memory at compilation. I don't like things not being locked down, so I wrote my own global ISR to replace to compiler's; solved that problem.

Next I searched through the disassembly listing and found every instance of the compiler using a free RAM location for scratch purposes. I then re-wrote my code to eliminate the need for the scratch math.

So now I have code that makes absolutely no refernce to any RAM locations that I have not specifically declared and #located in the RAM space (well, except for the aforementioned return val locs).

I then used the #reserve command to reserve the entire remainder of the RAM space (i.e. I #locate'd all of my variables sequencially, the #reserve'd from the end of the variables until the last RAM location). The compiler coughed up a "not enough RAM" error. I found that if I backed my #reserve off 6 locations, the compiler is happy.

I double checked my code, and still cannot find any refernce to these RAM locations that the compiler is insiting that it requires (checked for all direct references, indirect refernces via FSRs, and any access to that space via banked (BSR) references). I even (painstakingly) ran my code under simulation, and never saw those RAM locs get modified at all.

The conclusion is that the compiler _requires_ these 6 RAM locations, even if it doesn't need them. So here's my question: If this RAM is _required_, why the %$#$@! wasn't it just reserved by the compiler in the beginning of RAM like the RETVAL space is???

[Ttelmah]

To my mind you are wasting effort, _and memory_ by what you are doing. If you are using a compiler, then let it manage memory, unless you have very good reasons not to. The compiler works on the simple basis of treating all non static, and non globally allocated memory as a 'pool'. When a subroutine is called (either your's, or one of the compiler's own routines), memory is allocated from that pool, and reserved, till the routine exits. A few lines latter, the same memory can be used by another routine. This is essential in a chip with limited memory like the PIC, but the same re-allocation is also used on larger computers (but with the advantage of a hardware memory manager). In the current 'newest' OS's, the physical allocation will even be deliberately randomised, to help prevent certain types of virus attacks, which fixed allocations make easier...
Now the actual location of the core scratch, is definable by you, from the device editor. The interrupt handler scratch, will directly follow this, if you assign your interrupt handlers at the start of the code (this is slightly safer, since it forces them to be in bank0). Otherwise they will appear after other variables that have been defined first. Remember if you are using any for of ICD, _this_ will have it's own requirements for RAM, which are not under the control of the compiler, and will not show in the sym file.
In general, I'd say, let the compiler do it's job. If you don't want memory management, then use a library, and an assembler instead.

Best Wishes