Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!newstop!sun!stpeter!cmcmanis
From: cmcmanis@stpeter.Sun.COM (Chuck McManis)
Newsgroups: comp.dsp
Subject: Re: MC56000 brain dead??
Message-ID: <129650@sun.Eng.Sun.COM>
Date: 27 Dec 89 20:41:13 GMT
References: <9520009@hpsad.HP.COM>
Sender: news@sun.Eng.Sun.COM
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 52

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?!"