Interrupts, saving registers. Stack handling

[d00dajo]

Hi everyone,
I have a few more Q's to run by you all.

1. In the CCS compiler (still working with the 18F4680), does one manually need to handle saving of the registers when entering an ISR, or will the compiler generate the neccessary code? I.e. in an ISR "CanRxInterruptIsr" registers like W, the adder, multiplier etc. may be used. Will the CCS compiler recognize the registers used in the ISR code and automatically generate "save/restore" for those registers? If not, are there some form of compiler control (pragmas) to simplify the save/restore for registers. (In the C18 as an example, one specifies save=PROD, etc. for each ISR)

2. Memory Stack Handling
How is the software stack handled in CCS? Is it all up to the compiler to allocate the memory area for the stack, or can I set the software stack manually? (Example: main function calls "myLittleFunction1 which has 40 bytes of local variables, which in turn calls myLittleFunction2 which has 30 bytes of local variables. How to I check/control the memory space allocated for stacking these local variables?)


Thanks in advance,

//Daniel.

[Ttelmah]

The compiler saves everything (which can be a problem for speed), unless you use the 'fast' statement on the interrupt, or the #int_global statement. The latter specifies that you are taking over writing the global interrupt handler, and hence are expected to do all the saving/restoring yourself, while the former specifies to use the fast interrupt ability, and again then assumes that you will do the minimum necessary to save the registers.

There is no 'software stack', in the sense you are using the term. The compiler works by using a 'tree' of useage. Basically, if a routine is called inside another routine, then it's memory useage, must be seperate from that of the calling routine, and they will both be allocated seperate memory areas. If however two routines are called sequentially, they can both use the same memory area. The overrides for this, are 'static', and 'global' declarations, which are always given unique locations. If you look at the symbol file, it will show how the memory is allocated. So a entry like:
290 set1_setup.i
290 dmess.tbyte
290 set1_dat.i
290 init.cause
290 set1_al.opt
290 main.@SCRATCH
291.0 dmess.sflag

Shows that address 290 is being used in seven places, the variable 'i', in the routine set1_setup, the 'tbyte' variable in dmess, the 'i' variable in set1_dat etc..
Looking at these, you will find that each cannot occur inside the other (set1_dat, ad set1_setup, are two routines, one to setup the configuration, and one the data format, that are both called from the same 'menu', but only one can ever be called at a time, hence the memory can be re-used).

Note also that the compiler prevents re-entrancy on the interrupts, so if (for instance), you call a 'delay' routine inside the interrupt, and then use the same delay routine outside, interrupts will be disabled for the external delays. The same will apply to any other called routine used both inside and outside the interrupts. Generally simple operations (basic arithmetic etc.), are generated as 'inline' code, so this is not a problem, but if (for instance), you used a high level maths routine both inside and outside the interrupt, this would apply.

Best Wishes