Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!oakhill!pete
From: pete@oakhill.UUCP (Pete Percosan)
Newsgroups: comp.dsp
Subject: re: MC56000 brain dead??
Keywords: hardware stack, software stack
Message-ID: <2761@chomsky.oakhill.UUCP>
Date: 21 Dec 89 14:42:51 GMT
Organization: Motorola Inc. Austin, Tx
Lines: 81


> 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.

There are two ways to use the system stack.  In some embedded applications,
stack usage is inherently bounded so 15 levels are enough.  Examples are FAX,
modems, sound and music, image processing, graphics...
In this case, the hardware stack is fast, deterministic and supports
the nested hardware Do loop fetch mechanism.  When switching tasks, the
used stack locations can be moved to/from memory.  Register r7 is often
used as a software stack pointer via postincrement/predecrement
operations.
 
The other case is unbounded stack usage, where 15 levels is not enough.
'C' code is a good example.  Here the stack is used by the calling
procedure to store the return address, which is moved to/from memory by
the called procedure if necessary.  This is identical to RISC compilers'
use of their "return address" register, except that the 56K can overlap
the memory moves in parallel with other useful work.  This only uses a
few stack locations - the rest are used for nested interrupts.  Since
the 56K interrupts are bounded to 4 hardware levels, the 15 levels are
enough to leave the interrupt return addresses on the hardware stack.
This provides fast, low latency i/o service for 'long' interrupts -
'fast' interrupt routines do not use any hardware stack levels.
 
> 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.


Programs written in a high level language ( such as 'C' )for the dsp56000/1
utilize, at most, one location on the hardware stack, the return address ( SSH )
of a "leaf routine". But in all other cases the hardware stack is bypassed and 
hardware stack information is maintained on the software stack maintained by
the compiler. 

 
> 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.


The overflow, underflow and stack error exception are intended as a diagnostic
trap for an error condition - unfortunately, they are not useful for managing
the stack.  The problem is that it is fairly easy to construct a program which
results in excessive stack thrashing to/from memory, no matter where any
automatic load/unload thresholds are set.  So it may remain more efficient to
manage the stack in software.

 
> 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
 
 
Peter Percosan
Motorola DSP Group