🚀 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

Remember that the 56000 is designed as a Digital Signal Processor.  I hardly
think that Motorola intended it as a general purpose 32 bit processor.  Thus
I would disagree that its hardware stack limitations are a "flaw".

For speed purposes, I think their internal stack is much faster than an
external stack.  As an internal stack, it is therefore more limited in size
than a normal external stack.  This speed improvement does more good for DSP
programming than any consideration for high level language support.

Brian Willoughby
UUCP:           ...!{tikal, sun, uunet, elwood}!microsoft!brianw
InterNet:       microsoft!brianw@uunet.UU.NET
  or:           microsoft!brianw@Sun.COM
Bitnet          brianw@microsoft.UUCP

Minor flame ahead ... Hmmm, is it just me or is this a bit absurd ?

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.

Why? A DSP is a DSP, it isn't a general purpose CPU. Why do you want to 
make it into one? You can add any number of cheap micros on the board 
next to it if you want a CPU.

[Dealing with the small stack ...]

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

Well, if I were writing a C compiler for the 56000 and I knew of the stack
limitation (which I surely would), I would have the compiler generate all
of this stack checking code at the entrance to, and exit from each call. Or,
I wouldn't even use the "real" stack, and instead use a pointer off into some
random RAM and "pretend" it was a stack. The compiler writer can do all this
magic easily. 

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

So stay away from using the real stack except for interrupts or exception
processing.

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

Why not buy a different processing unit? It seems the 56000 is ill suited
to your needs. I don't know if you would consider yourself primarily a 
software person or a hardware person, but it seems that considering 
different hardware is in order here. Just a sanity check mind you, you
probably have compelling reasons why you want to use the DSP as a CPU
but normally when such fundamental problems occur they are a signal that
the peg is square and the hole is round.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@Eng.Sun.COM
These opinions are my own and no one elses, but you knew that didn't you.
"If it didn't have bones in it, it wouldn't be crunchy now would it?!"

As indicated by Pete Percosan from Motorola, the C compiler DOES
correctly deal with the hardware stack limitation by transferring
the return address to the software stack upon subroutine entry, and 
restoring it upon exit, effectivly bypassing the hardware stack.
This has also been verified by simulation. Overhead is two moves
per subroutine call.

 As he correctly asserts, since the processor has a limited number
 of external interrupts,
the 15 level stack is sufficient as long as the `do' construct is not
overused. Again, a software stack can be used to buffer nested do loops
written in assembler if necessary. I am not shure whether the Motorola
C compiler even uses the do loop construction..

Thanks for your replies, 

Steven Warwick
sdw@hpsad