gnupic: Thread: Quick port of Janusz J. Mlodzianowski's MediumC to linux

Taking a quick look around for a C compiler for pic, I found Janusz J.
Mlodzianowski's MediumC written for Borland C (I also found this list)
I've done a quick port to Linux...

ftp://ryeham.ee.ryerson.ca/pub/pic/mediumc.tar.gz

It generates poor code, but seems to work and it's GPL'd.  YMMV

-- 
D. Jeff Dionne                                        ####@####.####
   -VP Research and Development, Office of the CTO

Lineo - Put Linux Anywhere

On Thu, 7 Sep 2000, D. Jeff Dionne wrote:

> Taking a quick look around for a C compiler for pic, I found Janusz J.
> Mlodzianowski's MediumC written for Borland C (I also found this list)
> I've done a quick port to Linux...
> 
> ftp://ryeham.ee.ryerson.ca/pub/pic/mediumc.tar.gz
> 
> It generates poor code, but seems to work and it's GPL'd.  YMMV

Confirmed.

mediumc suffers from the same root cause of pic_cc: ported from Small C. In the
ten minutes I played with it, I found that it was less stable than pic_cc and
generated the same code.


--------

As you probably know, I asked the SDCC guys what it'd take to target a PIC. The
answer was predictable: Yeah, no problem, but no time either... One person has
expressed serious interest in pursuing this arduous task. But before we venture
off into this somewhat uncharted territory, I'd suggest we look at what it would
take to use gcc as the basis for the pic c compiler. Jeff Dionne and a few
others on the SDCC list suggest that it may not be as bad as we think (or at
least I think). It seems rather daunting. However, there's already been a gcc
port to AVR and this may serve as a good template for a port to the
PIC. Furthermore, there have been probably 20 different processors targeted by
gcc. There's got to be some common ground between these and a PIC in there
somewhere.

I'm not suggesting that SDCC be abandoned just yet. However a port to gcc will
allow us to leverage off the huge GNU tool chain.

Scott

Oops, meant to be sent to the list but sent to Scott instead.
But the difference is not that big? ;)

> > > Furthermore, there have been probably 20 different processors
targeted by
> > > gcc. There's got to be some common ground between these and a PIC in
> > there
> > > somewhere.
> > 
> > This is a frequently rising idea on the piclist (at least twice a
year).
> > The problem is that the PIC is a VERY special beast. 8051, AVR, 1750,
6800,
> > 6502, you name it, are all pretty close to what gcc was inteded for
(they
> > all have a parameter stack), and the model required to generate
effecient
> > PIC code is quite different (stack only for calls, very limited stack,
in
> > fact very limited anyaway!).
> 
> Hi Wouter,
> 
> Thanks for the feedback. I don't think I have the energy to actually do
the port
> myself. I'm hoping to get enough people interested so that someone else
could do
> it :).  I've thought about the stack issue and it's going to be a
problem.
> Recursion will kill you if you let it! What I would probably do though is
place
> the "stack" in RAM at convenient boundaries, use INDF/FSR to access it,
and use
> BTFSx instructions to test stack overflows. It sucks. Although as a user
of the
> compiler, one would be careful not to pass numerous parameters, make
recursive
> calls, or have many local function variables.
> 
> Scott
> 

That approach will produce code that is inferior to a more PIC-suited code
generattion scheme by a FACTOR of 2 - 10. At least it won't be a threat to
Jal... For a PIC one should/must use the static stack method: 
- first make sure there is no recursion
- then sort-of simulate the stack of the runnig program, to determine where
each local variable and paramter will end up
- genererate code, knowing the absolute addresses of each variable or
parameter

This is not that difficult, but it is not easy to integrate this in a
compiler that does not think that way in the first place!

regards,
Wouter

(more on stack-like code generation being impractical for a PIC)

consider
   byte a,b,c
   a = b + c

good PIC code would be (3 instructions)
   movfw c
   addwf b, f
   movwf a

stack-oriented code would be
   push c
   push b
   add
   pop a

or
   push c
   add b
   pop a

stack-oriented code for a PIC, with calls (6 instructions, but calling all
the push etc routines takes 24 instructions execution!)
   movlw _c
   call push
   movlw _b
   call add
   movlw _a
   call pop

inline stack-oriented PIC code would be faster, but takes (much) more
instructions.

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?

Wouter
   

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

> However, if one
> were to preclude recursion then I don't see why stack based variables are
> necessary.

Only when one wants to re-target gcc: because that is the way gcc sees its
target: (more or less) stack based.

> 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...

That is exactly how it is done in Jal (and I assume in all other PIC
compilers). Not very difficult in itself, but hard to add to an existing
compiler that does not think that way. BTW in Jal recursion is not
possible, I don't known for other PIC compilers.

Wouter