Suggestion for scratch registers

[RLScott]

I often use #INT_GLOBAL for faster interrupt speed, rather than the CCS interrupt dispatcher. One problem with this is that nothing is saved, unless I do it myself. With the PIC18F parts this is not much of a problem since the hardware saves STATUS, W, and BSR. But not so with the @SCRATCH registers.

It occurs to me that it might be desirable to have the compiler use a separate set of scratch registers during interrupts, assuming there is enough unused RAM to do it. It also might be difficult for functions that are called from both interrupt code and main code. But I would be content if just the #INT_GLOBAL routine used the alternate scratch registers. If I decide to call a function from both the interrupt code and the main code, I can take responsibility for saving the main scratch registers, but that would be a very rare application.

Is there already some option I am not aware of that would provide for using alternate scratch registers in interrupts? So far what I have done is examine the compiled code in the .LST file to see if scratch registers are being employed and then rewrite the code, if possible, to make the use of those registers unnecessary. If I cannot do that, then I do go ahead and save and restore the scratch registers.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting

[Ttelmah]

Problem is the PIC is very inefficient at using 'movable' registers. Code that accesses an address that can change needs about 10 extra lines versus the same code accessing an address at a fixed location. Hence 'movable scratch' is not going to be efficient in a PIC. What you could do is load a separate maths library (how to do this has been described here), which then creates separate versions for the interrupt and main code, each with their own scratch. This would only leave a very few scratch locations common to both. However this is going to be quite bulky, and generally the scratch locations are few compared to the number of processor registers involved.

I've often wished the PIC had duplicate/swappable primary registers available (as was done years before on several early processors).

[RLScott]

It would not be necessary to have run-time movable scratch registers. It would be sufficient if the alternate scratch registers were just used for the in-line code generated in the #INT_GLOBAL function itself. I know there are lots of library functions that probably use scratch registers, and I don't expect those to be the alternate ones. If my interrupt routine is doing things involved enough to need library routines, then I probable have enough time to save and restore the standard scratch registers they might use. The real benefit to such an option would be for those very fast interrupt routines that have no need to call library functions. Just a simple 32-bit add and subtract is enough to invoke scratch registers. If those could be done with alternate scratch registers that would be a big help to me.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting

[Ttelmah]

You are fractionally missing the point.
If the maths routines are going to use alternative copies of the scratch, the routines themselves have to be duplicated, otherwise they are going to have to use movable registers. Hence the need to load an alternative maths library. Understand that if you tell the compiler to use an alternative library, it only actually loads the routines that are _used_, so loading an extra library would only load the maths functions your code uses in the section involved.

Look at this thread:
<http://www.ccsinfo.com/forum/viewtopic.php?t=25464&start=4>

Which shows how to make the compiler use a separate library for the maths.

Do this, and you will find that the symbol map suddenly has two sets of scratch registers for the div16 routine....

[RLScott]

As I said, I don't want or expect the math library routines to use alternate scratch registers. I have lots of interrupt code that does not use any math routines (from the library) at all. It does use some math operations, like adding and subtracting 32-bit numbers. I have looked at the compiled code in the LST file and they do not call any math routines. They are compiled into in-line calculations, which also happen to use scratch registers. The compiler could use alternate scratch registers for these in-line calculations without affecting any math library routines. I don't need to do something so drastic as load an entirely separate alternate math library to accomplish this. One work-around, I suppose might be to compile as it current is, then take the compiled code from the LST file and use it to design a #ASM...#ENDASM equivalent for what that code does, except that I will use my own scratch registers instead of the ones the compiler did. Of course this is a lot of work and is not very maintainable, which is why I raised the possibility of just specifying an option that in the #INT_GLOBAL code and _only_ in the #INT_GLOBAL code, ram locations 4,5,6 and 7 would be used instead of 0,1,2,3 (the usual @SCRATCH locations).
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting

[Ttelmah]

Just use the example I showed, and see what it does.

Separate maths routines for the interrupt, and separate scratch. Exactly what you want/is needed. All maths is 'from the library'. 'Maths.c', is not 'the library', it is the extended (things like log') library.

It does what you want.

[Ttelmah]

Let me do a demo of how to use this:

[RLScott]

Thank you for taking the time to prepare this demo for me. I pasted it into my project and compiled it, and this is what I noticed from looking at the resulting LST file:

The interrupt handlers call a version of @@DIV1616 located at 0x50 and the main program calls a version of @@DIV1616 located at 0x402. Looking at the code at 0x50 and 0x402, they are indeed very similar. But both versions start out by clearing RAM locations 0, 1, 2, and 3 (@SCRATCH in the symbol table). How is that not a problem? Supposedly the 0x402 version of @@DIV1616 could be interrupted and the 0x50 version given control, thus corrupting the 0x402's use of these four registers.

Then I applied the #ORG statements to my current code to further demonstrate the problem. Around my #INT_GLOBAL routine I put:

[Ttelmah]

That's why I always save those four registers....

You started by asking about maths scratch, which is what I answered.
These are the general temporary scratch variables.

Now technically it should be possible to relocate these with #locate.
This was an ability that worked at one time, then stopped, then started again, and is not being accepted by the current compilers.


The syntax was:

#locate auto=<address>

I'd suggest a quick email to CCS, pointing out that this ability is not working.

[RLScott]

[RLScott]

After reporting the problem to support, I got a very prompt and useful response. Here is the whole story on the #locate auto directive:

Despite what the help file says, the correct syntax is:

[Ttelmah]

I'd query back and point out you want to relocate the scratch.