RE: [ECOS] changing the stack ptr

["Dan Conti" <danc at iobjects dot com>]

Even with 'Use seperate stack for interrupts' enabled ?

This is a fairly lengthy routine. It's cpu intensive, and the deal with
the extra register is either i use the sp, rewrite it (which i dont
think i can do in a reasonable time period) and hopefully save a
register, or spill data onto the stack so i can preserve the sp.

I feel like i'm missing something here. On this processor the sp and lr
are banked in irq and fiq mode. When an irq occurs shouldn't it be
referencing the irq stack at that point?

Thanks,
-Dan

> -----Original Message-----
> From: Gary Thomas [mailto:gthomas@redhat.com]
> Sent: Thursday, July 26, 2001 5:46 PM
> To: Dan Conti
> Cc: Ecos-Discuss (E-mail)
> Subject: RE: [ECOS] changing the stack ptr
> 
> 
> Chainging the stack with interrupts enabled is just asking 
> for trouble.
> 
> How long of a routine is this?  Can you justify leaving interrupts off
> for the time it runs?
> 
> Can't you get by with one fewer registers?
> 
> [questions asked just to play advocate]
> 
> On 26-Jul-2001 Dan Conti wrote:
> > I'm working on the cirrus part.
> > 
> > I have a piece of code that needs to use all available registers. As
> > such, i'm storing the sp off to a seperate location and 
> reusing it as a
> > normal data register. I have actually done this in the past with
> > moderate success (on older kernels), but i'm having some 
> problems now.
> > 
> > In the past, i used the sp to point into the middle of a 
> data structure,
> > the "upper" (as in >= sp) part of the structure being state 
> data for the
> > routine, and the "lower" (as in < sp) part of the structure 
> was a small
> > 1k stack, completely unrelated to the main thread stack. So 
> basically i
> > was able to use the sp register for my own purposes, but 
> there was still
> > a psuedo-stack that, if my routine was interrupted, could be used to
> > store data on.
> > 
> > Using this same code on current cvs kernels i get the following
> > exception:
> > 
> > ASSERT FAIL: <3>sched.cxx           [ 170] static void
> > Cyg_Scheduler::unlock_inner()
> >                 Bad next thread
> > 
> > I set a break in cyg_assert_fail(), and it appears that the 
> entire stack
> > is hosed.
> > 
> > Any thoughts?
> > 
> > -Dan
> > 
> > --
> > Dan Conti             e danc@iobjects.com
> > Software Engineer     p    (425) 289 0326
>