On Mon, May 16, 2011 at 9:10 PM, Raphael Neider <rneider@web.de> wrote:

> The hidden goal is to properly support setjmp/longjmp and implement a
> basic task switcher.
> The proposal is to shortcut the hardware stack implemented in the PIC.

I'm currently (and have been for the last few months) busy in other
projects so that I do not have any/a lot of time to spend on hacking SDCC.

I have had a look at your patch: With that implementation, we still use
the hardware stack and can get stack overflows and maybe even underflows
iff you switch from a context with low nesting level back to one with a
high nesting depth.
To eliminate that was not your goal, I just wonder what would happen.

Yes that's true. Bad things would happen.

My goal is to bypass the HW stack completely, because we cannot share it among more than one context. Saving the hw stack pointer and restoring it is possible, but it would leave quite a small stack for actual calls.

So the only thing that remains is to ensure that a lot of CALLs will not overflow the HW stack, I think that it can be done by forcing stkptr to zero at function entry after saving the return address, because on return, the proper return address will be retrieved from the SW stack and positionned at stack[0], and then used by the RETURN instruction as if nothing had happened.
Additionally, on a context switch, you have to save TOS[UHL] since you
might have been interrupted prior to saving those on the SW stack. Again,
not a showstopper, but worth documenting.

Would it be so dangerous? if an ISR pops in the middle of the PUSH TOS[UHL] instructions triplet, the ISR will save the current PC, run the irq context, restore PC and return to the initial task. The task will theoretically stay in a consistant, however strange, state.

The datasheet for the 18f1220 states in 5.2.1 that "The user must disable
the global interrupt enable bits while accessing the stack to prevent
inadvertent stack corruption.". This sounds rather costly, as it requires
the current interrupt state before and restoring from somewhere around
both function prologue and epilogue.

Yes... I did not see that. That might be a pain. Moar brain time is obviously required here.
Personally, I do not use PICs in any project, so I do not know whether
such an approach is useful or not. I can see the presented benefits of
true context switching (and setjmp/longjmp, though I wonder whether PIC
programs should use such exception-like approaches?).

well the only benefit could be context switching, it could allow a small RTOS such as TinyOS (or anything small enough - or something I want to write) with parallel infinite loops and preemptive multitasking. I think the setjmp function per se is useless in a pic: Exceptions are not required.
As the patch does not seem to break anything as long as --soft-call-stack
is not given, I have no objections to committing the proposed changes iff
you see any benefit of having them in the official sources.

Not for the moment. I don't think it would be wise to apply that until the global behaviour of a pure soft stack are defined and understood :-) It lives quietly in my working copy :-)
However, I would like to see a solution/discussion to the HW stack overflow/underflow
topic first. Would adding a POP instruction after saving TOS[UHL] and a
PUSH instruction prior to restoring TOS[UHL] suffice? Is that what you
meant with "forcing STKPTR to 0"?
Yep. If we don't fully "disable" the HW stack (which is automatically used when using CALL/RETURN) we'll run into problems as soon as the original HW stack under/over flows. So my idea was to only use the first level of the HW stack as a "return address register" and handle the real stacking using the parameters stack. So as a first thought, defining STKPTR to zero before storing anything inside sounded the right thing to do. What remains to understand is how well this works with interrupts.

More work is required to make sure we have it right, specifically when a hardware IRQ is triggered, and we cannot avoid the hw stack mechanism. I think it's worth introducing this feature, and it shall be done properly.

Thanks for participating in the thread.