🚀 go-pugleaf

> I don't use a C compiler. But I'm curious about how they handle subroutines
> calls. Do they use a separate stack for parameters and local storage? Is
> the Stack Register used for subroutine calls? Are nesting of subroutines
> calls and used of hardware DO loop used sparingly?

For both g56k and g96k, we manage a software stack in addition to the
hardware stack. When a function is called, the jsr instruction is
used.  The callee will then transfer the saved program counter off of
the hardware stack and onto the software stack, thus freeing up that
stack location. At the end of the function, the saved program counter
is restored to the hardware stack, and the rts instruction is used.
Leaf functions, which make no function calls themselves, don't bother;
they just leave the program counter on the hardware stack. 

We, by default, issue up to three nested do loops. We won't issue a 
do loop if the loop body contains a function call for obvious reasons.
The number three was picked so that most of the do loop benefit would be 
derived in most cases, with plenty of room for interrupt nesting. The
user can change this limit. The user can also turn off leaf function 
optimizations.

	Jeff Enderwick
	jeff@dsp.sps.mot.com

In article <1992Oct15.003553.14620@news.Hawaii.Edu>, denault@galileo.ifa.hawaii.edu (Tony Denault) writes:
>The system stack register seem very limited due to its size restriction
>of 15 RAM locations. According to the manual it can handle up to 15
>long int, 7 DO loops or 15 JSR's or a combinations of these. This would
>make it seem rather easy to write a program with overflows the stack.
>I wrote a function which has 4 nested DO loop. I am very careful when to
>call it. It seem to me if I nest subroutine call and receive an interrupt,
>I could get in trouble very easily. 
>
>I don't use a C compiler. But I'm curious about how they handle subroutines
>calls. Do they use a separate stack for parameters and local storage? Is
>the Stack Register used for subroutine calls? Are nesting of subroutines
>calls and used of hardware DO loop used sparingly?

The following is valid for the Intermetrics 96002 C-compiler:

- The hardware stack is saved as part of the prologue in all C-functions that
  may call other functions.
- Parameters are passed on a software stack maintained by the code. An address
  register is reserved for use as software stack pointer (another address
  register is reserved for use as base pointer).
- This compiler *never* generates do-loops.
- There are no restrictions (other than RAM shortage) on the number of 
  function calls that can be executed.

-- 
** The above was the private opinions of Harald Ljo"en (harald.ljoeen@nta.no) **

mmh@mercury.analog.com (Marc M. Hoffman) writes:

>In article <johnr.719787436@ee.uts.EDU.AU> johnr@ee.uts.edu.au (John Reekie) writes:

>All my statements are based on our new compiler GCC and when I say 'we'
>that means our version of the GCC compiler.

>   Uh, well, I'm not exactly working on a compiler, but I'll have to
>   pretty soon. I'd add:

>   vi. modulo addressing

>We do this in our GCC compiler.  Althought the solution is not as
>general as we would like the solution works for most applications.

>Depending on the architecture you might be able to use the combiner of
>GCC to recognize the modulo addressing.  i>N?0:i+1 or something like
>this.  But on our architecture this doesn't work because of the b|i
>combinations. 

Isn't what's really required a pointer object? So you could go
something like:

	ModuloBuffer<float> p;		/* modulo buffer of floats */
	p = newModuloBuffer( N );	/* N is size of buffer */

	*p.current = x;			/* read from buffer */
	*p.current++ = y;		/* write and (modulo) increment */

	... p.base ...;			/* this is th base address */
	... p.size....;			/* this is the size of it */
	
	ModuloBuffer<float> q;
	q = accessModuloBuffer(p);	/* reference the same memory */

	if ( p.current >= q.current )	/* modulo comparison ? */

I know nothing about C++, but I;m sure this could be expressed
easily in it. Then all you do is say that your compiler
"knows" about certain types of object, such as ModuloBuffers.	
It can generate efficient code for calls like *p.current++
(on C30, you would get ldf *ar0++%,r0, for example). AND the
code would still be standard C++, so you could have portability
as well.

Does anyone have any comments on this idea?
		
>   vii. use of index registers

>We use index registers as much as possible.  We even generate
>postmodify code.


So if I have

	for ( i = 0; i < N; i++ ) {
		*p = *q;
		p += pinc;
		q += qinc;
	}

it will do the pointer updates using postmodify? (pinc and qinc
are not known at compile time!)

>   viii. Associative and non-associative arithmetic (I guess this
>	 is really a language feature)

>?? what does this mean

Well, I could have put it better, that's for sure. I was trying
to say that sometimes you need to be able to specify the
exact order of computation of an expression, and not have the compiler
re-arrange it, for reasons of precision. On a related note, it
may also be desirable to be able to specify numeric precision,
so that high-precision values are kept in registers, (even if
this requires extra cycles). I don't know much about this topic --
maybe someone who does could offer an example?

>   ix. smart structure return i.e. return small structures in
>       registers

>This is extreamly hard with a multi-memory architecture.  But I think
>it can be done easily if the function prototype stated where the value
>must be returned to..

I'm not sure I understand the problem. Doesn't gcc return
strctures that will fit into teh register set in registers?
This would be very important for complex numbers, for example.

>   x. Ability to inline assmebler functions (no idea how this would
>      work!)

>This is awsome and GCC provides the Best assembler interface that I
>have ever seen.  Check it out..

I will (one of these days....). What is the difference between
gcc 2.0 (which is on our machine) and gcc 2.22 (which is what
everyone talks about :-) )?

>   xi. Automatic code inlining

>Gcc does this too via a switch.

>   xii. complex number smarts (again a language feature -- I guess
>       I'm talking about not just C compilers).

>We have added this feature to our compiler.  And we like it very much
>here look:

>void fft(complex int data[], complex int coef[])
>{
>  complex int A, B, Coeff, temp;
>  int groupsPerStage = 1, BperG = 1024  >> 1;

>  for(I=10) {
>    for (J = groupsPerStage) {
>      for(K = BperG) {
>	temp = coef[I] * data[(2*J+1)*BperG+K];
>	data[ 2*J    * BperG + K] += temp;
>	data[(2*J+1) * BperG + K] -= temp;
>      } 
>    }
>    groupsPerStage <<= 1;
>    BperG >>= 1;
>  }
>}

This is pretty neat. How does the performance compare with
an assembler implementation? You use array indexing instead
of pointers -- does this adversely affect performance?

My earlier attempts to find out mroe about Numerical C
have met with no success. What document would I ask the
local rep for to find out at least about your implementation?
The DSP/C manual?

>   xiii. Preservation of dependencies between instructions so the compiler
>	 can fill in pipeline holes.

>The gcc compiler 2.0 or better does a fairly good job scheduling
>code..   


John Reekie

>My earlier attempts to find out mroe about Numerical C
>have met with no success. What document would I ask the
>local rep for to find out at least about your implementation?
>The DSP/C manual?

Does Analog Devices offer a gcc based DSP/C compiler for sale?
How can I buy one?

	Jeff Enderwick
	jeff@dsp.sps.mot.com