🚀 go-pugleaf

I'm sure others have responded to or will respond to this as well, but just
thought I'd throw in my 0.5 inverse cents worth (fractions only :-).

In article <9520009@hpsad.HP.COM> sdw@hpsad.HP.COM (Steve Warwick) writes:
> I have been looking into using the Motorola DSP56000 for use as more than
> just a DSP engine - taking on additional system control and i/o functions.
> I have come across an apparently insurmountable problem in the stack handling
> of this chip, and am wondering if others have found an efficint workaround.
...
> has anyone actually run into such problems and have a method of dealing
> with the stack limitation? In the ideal world, the stack interrupt would 
> have occurred before we run out of room on the stack itself, allowing 
> an exception routine to buffer the stack as needed. Else, allowed the user
> to specify an area of internal XY ram as a stack base and forgot about the 
> 15 double words. 

As you have surmised, the internal stack is kind of useless for C code.  The
Motorola 56K compiler uses the same solution my assembly code does --
allocate R7 as the stack pointer, and forget the internal stack.  Actually,
interrupt handling will still happen on the internal stack, limiting one to
16 (8?) levels of nested interrupt -- big deal.  Also, in my assembly code,
I'm using the internal stack for jsr and for do nesting, since I can
guarantee that they will be 3-4 levels deep at most -- the C compiler really
hasn't this option...

> I am concerned that the 96000 will also have this problem, which will be
> a suprising limitation for a 32 bit processor!!

The rumor mill has it that this limitation will in fact also exist in the
96K.

					Bart Massey
					
					Tektronix, Inc.
					TV Systems Engineering
					M.S. 58-639
					P.O. Box 500
					Beaverton, OR 97077
					(503) 627-5320

					..tektronix!videovax.tv.tek.com!bart