AVRCO Scheduler problem (big bug)

Hi Rolf

I'm coming back about the note I told you about frame pointer and the use of frame in interrupt handlers.

I create a very light project (only one file) that you can download and test on any ATMega board with 2 leds.

The main.pas file contains a lot of comments which explain the principle of the test.
I run the project on my ATMega board and, in less than a second, the software detect a frame pointer invalid at the entry of an interrupt handler.

This point confirm what I thought before: the use of the frame bufferas it is implemented, is not compatible with using frame pointer in interrupt handler.

I develop :
For a call to a procedure which use frame pointer, AvrCo generates this code :
PUSH _FRAMEPTR
PUSH _FPTRHI
CALL AProcedure
POP _FPTRHI
POP _FRAMEPTR


So if an interrupt occurs during the execution of the two last lines, the frame pointer which could be use in the interrupt is invalid.

So if AvrCo keeps this way to use the frame pointer, it will be impossible to use frame in any interrupt handler, so it is impossible to use local variables in any user function called from an interrupt routine. In an other hand, it is not easy to know which system functions we can use in the interrupt because some use the frame and some use the registers.

The protection from interrupt of each (Pop _FPtrHi / Pop _FramePtr), will be very heavy.

I don't have any easy solution but one could be (as in Delphi) that each procedure which needs frame has to create it from its stack pointer. But it is a hard job to change in the compiler. The other advantage is to not have a dedicated area for the frame and we have only to size the stack of each process.

May be a light solution that can be used for small frame (less than 63 bytes) is to reintegrate in the procedure the frame Sub/Add by ininterruptible code : Instead of the sequence above you can replace it by only
CALL AProcedure
and change the AProcedure entry and exit by (if the procedure needs 32 bytes of local data)
AProcedure:
SBIW _FRAMEPTR, 32
....
AProcedure_X:
ADSBIW _FRAMEPTR, 32
RET
but not any cpu can do this and it is only for less than 63bytes of frame for the ATMega.


For conclusion, at this time, any userDevice can't use frame to pass parameters and must use registers or static variables.

Gérard

Hello Merlin

I agree with you, it is a good and fast solution.
Unfortunately, when I develop I don't use the optimizer (only for the release version) and in this case I survey any bug/malfunction of my code through the developing steps (as any developer ?

What will be fine, is to integrate this optimization in the compiler, it will be efficient for more than 90% of the procedure calls. Then moreover, if the frame size is too large and oblige to use SBC, add a locked sequence to manipulate the frame ptr after (and only after) the call, a little bit like in the new version of the scheduler.

The result will be useful, because we will be able to use local variables and any procedures in the interrupt handler without risk (except the time execution !).
Gerard

Hi Gerard.

Just to expand a little of Rolf's comments.

It is not really possible for the compiler to make the optimsations in the way the optimser does. It cannot know what value to add to the stack because the procedure might not yet be defined (for example if it declared as forward, or is in a unit). That is a big difference between compiler and optimiser - the optimiser has the whole file to handle, but the compiler does not (since it is in the process of creating it!). The only practical way that I can see for the compiler to handle this is by storing the interrupt enabled flag, disabling interrupts and restoring it at the end, which as you point out adds a lot of overhead, since it would need to be done for every call.