At 18.40 11/01/98 -0600, you wrote:
>One simple approach that works well for local variables (somewhat less well
>for argument passing) is to figure out where on the stack each variable would
>go, worst-case, on a stack-based machine.  For non-recursive programs, it's
>always possible to assign addresses in this way, and the number of addresses
>required by this method will equal the maximum depth that the program could
>need if it used a stack.
>
>The only drawback to this approach (or a bottom-up approach which yields the
>same memory requirements, but orders things differently) is that special
>care needs to be used for parameter marshalling.  For example, consider this
>program:
>
>int foo(int p, int q) {return p+q;}
>int boz(int s, int t) {return s*t;}
>int bar(int u, int v) {return u-v;}
>
>int floozle(int ss, int tt, int uu, int vv)
>{
>  return foo(boz(ss,tt),bar(uu,vv));
>}
>
>It isn't possible to use a fixed address for foo's parameters unless some
>other area is used for "parameter martialling".  In particular, a compiler
>given the above code should translate the last function into:
>
>int floozle(int ss, int tt, int uu, int vv)
>{
>  int temp1;
>
>  boz.s = ss; boz.t = tt; CALL boz;
>  temp1 = RESULT;
>  bar.u = uu; bar.v = vv; CALL bar;
>  foo.p = temp1; foo.q = RESULT; CALL foo;
>}
>
>where function.param is the variable allocated to that function's parameter,
>and RESULT is a system global used to hold function return values.  If the
>compiler always allocates a temp for all but one of the "complex" parameters
>to a function, it will work okay though it will in many cases generate data
>moves that turn out to be redundant.  On the other hand, all of the PIC-based
>compiles I've seen choke on the above example program, so maybe parameter
>marshalling may be safely ignored in practice (since such programs are rare).
>
>

thanks John, this method seems to me that is good. Not so good for argument
passing but for a beta it can be ok.
My goal is to make a simple c compiler thats product a asm code for MPLAB,
full commented and easy to modify with a no run time support (or very small
and easy to understand = modify).
Take a look at the grammar.
Bye.



Attachment converted: wonderland:Grammar.htm (TEXT/ttxt) (0000FA14)


===================================================
Alboni Giorgio
Faenza (Ra) ITALY
E-Mail: rac1337@racine.ravenna.it

http://www.geocities.com/SiliconValley/Heights/5444
(Last Update: 29/09/97)
===================================================