gnupic: Quick port of Janusz J. Mlodzianowski's MediumC to linux
Subject:
Re: Quick port of Janusz J. Mlodzianowski's MediumC to linux
From:
Scott Dattalo ####@####.####
Date:
9 Sep 2000 04:36:42 -0000
Message-Id: <Pine.LNX.4.21.0009082328210.15967-100000@tempest2.blackhat.net>
On Fri, 8 Sep 2000, w. v. ooijen / f. hanneman wrote:
> (more on stack-like code generation being impractical for a PIC)
>
> consider
> byte a,b,c
> a = b + c
<snip>
> So: stack-oriented code generation for PICs is possible, but would you want
> to use a compiler that generates code that is either 2 * the size and 6 *
> as slow as 'decent' code?
Nope! And that's why I don't use small C or it's derivatives. However, if one
were to preclude recursion then I don't see why stack based variables are
necessary. In PLM there's a function modifier type called REENTRANT that allows
one to explicitly specify those functions that are re-entrant (in this context,
it means the function may get interrupted and then called by the interrupt
routine). I'm not suggesting that the C syntax be modified to cope with PIC's
inadequacies, but I think there's room for cleverness. For example, command line
options could be provided to select which functions are re-entrant. Or perhaps
special pragmas may be used. Both solutions are ugly, but at least they avert a
stack based solution. As long as the functions are not recursive, then it's
possible to do as you described earlier: create a variable usage map. Perhaps a
call tree could be created to help determine which variables need to be mapped
to which functions (and thus allowing to reuse some variables). I suppose these
are some of the tricks you and other compiler writers play, but I wouldn't
know...
Scott
