Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!hpl-opus!hpnmdla!hpsad!sdw
From: sdw@hpsad.HP.COM (Steve Warwick)
Newsgroups: comp.dsp
Subject: MC56000 brain dead??
Message-ID: <9520009@hpsad.HP.COM>
Date: 12 Dec 89 01:16:47 GMT
Organization: HP Signal Analysis Division - Rohnert Park, CA
Lines: 39

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.

The internal hardware stack is used for subroutine calls, interrupts and
maintaining information on nested Do structures, but for all its uses, it
is only 15 levels deep. In systems which must handle a number of separate 
tasks and/or written in a modular style, along with much of the code written
in 'C' this stack limitation seems absurdly small. 

Motorola provided two methods of dealing with this, both seem poorly thought 
out.

1)  "overflow" and "underflow" indicators in the status register exist
which tell you that you are on the 0 or 15'th level. This is fine in cases 
where each subroutine call and interrupt will check the stack to see if there
is still room, and block move the stack accordingly, but if the program is
primarily 'C', no such automatic checking exists.

2)  overflow exception interrupt occurrs when the stack pointer goes from
0 to 15 or 15 to 0. Here, the offending instruction's PC is not saved, and 
no method of stack buffering can be implemented. 

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. 

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

Thanks, 

Steve Warwick
sdw@hpsad