> I was reading the docs of the beta version of MPLINK and I understand
> that there is no efficent RAM allocation algorithm. I don't get it,
> am I the only one who benefits from such an algorithm? I gathered the
> following info from an app I did with the macros I wrote about last
> year...
>                                                          But, because
> of separate compilation, a linker won't be compatible with any
> "external" allocation algorithm, so I think it's important that it
> includes one. Unless I'm the only one with RAM-hungry apps. . . I'd
> like to hear your opinions.

I think the documentation surrounding those macros was a little bit
confusing; still, there's no reason for any reasonable development
system NOT to support **AT MINIMUM** stack-based(*) allocation similar
to those macros.  Since I've not looked at MChip's linker I can't say
whether it could be coaxed into such things, but if not I can't see
recommending it.

(*) There are two related algorithms, both equally good for allocation of
    local variables; both have problems dealing with function calls that
    occur within another function's argument list (e.g. foo(bar(x),boz(y)).
    The choice of one algorithm over the other may be made based upon other
    system considerations.

 [A] The stack-bottom method: for each procedure, ask the question: if
     memory were a stack, what's the lowest address at which I could
     allocate these variables without overflowing the stack?  For proc-
     edures that call no others, variables should be started at the bottom
     of local data space.  For procedures that call others, variables should
     be allocated just above the top of the "tallest descendent".

 [B] The stack-top approach: for each procedure, ask the question: if
     memory were a stack, and the program started executing with the stack
     pointer at the top of memory, what is the lowest address at which I
     might have to put these variables to avoid colliding with my caller's
     variables?  For the root level (main) procedure, variables should be
     allocated starting from the top of local data space.  For other proc-
     edures, variables should be located just below their "deepest caller".

    Both of these procedures will require the same simulated stack-depth;
    variables not on that "critical top-to-bottom path" will be located
    differently.  The primary difficulties with both algorithms are that
    they don't take into consideration that variables may become obsolete
    in other than LIFO order, and that they don't support parameter-passing
    very well.  But IMHO no coding tool can aspire to greatness unless it
    has memory allocation that's AT LEAST this good.