Hi Folks,

I've been watching this thread with a lot of interest and I just wanted to
add my two cents worth.

I've gone through three compilers of my own, each with varying levels of
success.  In the next week or so, I will be releasing a beta of a BASIC
interpreter for the PIC16F87x that is a reflection on some of these points.


Here are some points that I have learned in compiler development that you
should make part of your planning process:

1.  Clearly and minutely define the language.  One of my big problems has
been to start writing before I have fully defined what I have wanted the
compiler to do.

When I say fully define, think through how you are going to handle variables
in arithmetic statements and how you are going to pass them to functions and
subroutines.  If you don't have this well thought out, you are going to find
you are inventing things at a time when you don't want to.

2.  Figure out how you are going to support all the different PICmicro MCUs
out there.  One of the biggest problems with supporting PICLite was trying
to come up with a way of handling all the different PICmicro part numbers.

This is not a trivial item.  I found that to do a register definition file
correctly, I would spend two or three hours per file.  Multiply this by the
number of PICmicro MCU part numbers there are out there.

Ideally, your language should use the Microchip MPLAB .inc files so you
don't have to do any of the work.

3.  Put in the hooks for MPLAB right from the start.  A compiler without
MPLAB's source level simulation or emulation is basically useless for any
kind of sophisticated application development.

You can create your own simulator, but note that it will require at least as
much effort as the compiler itself.

4.  Contact Microchip's lawyers on any names you are planning to use to make
sure they approve.  This probably sounds ridiculous, but I have had a
significant amount of heartache dealing with Microchip's lawyers over the
past year.  I've talked to a number of people on and off the list that have
had to change product names or functions based on demands from Microchip's
legal department - you will have to get approval from them for your
documentation because you will be using their registered marks.

PICLite is a case in point, Microchip's lawyers consider my "PICLite" to be
in conflict with Hi Tech's "PICC Lite", which Microchip owns the marks for.

5.  Keep your first attempts as simple as possible.  If you compare the
arithmetic processing capabilities of PICLite to "professional" compilers,
you will see that it has some capabilities that are in different devices
(and were very hard to implement).

This also includes data types.  Don't feel bad if your first pass only
supports single, 8-Bit variables.

6.  Define your performance targets.  This is in the area of execution speed
and hex file size.  When you start out, plan to achieve the same level of
performance as the BS1 and look for opportunities from there.

7.  Decide whether or not you want linkable object files.  Personally, I
would never write a compiler that had linkable objects - instead I would
include all external modules and compile them at the same time.

I know I'll get flamed for this one, but I do not believe that the
traditional reasons and advantages for linking object files applies to small
MCUs.

8.  Consider developing the compiler for just the PIC18Cxxx - this chip
could probably benefit from a new compiler and it will be the easiest of the
PICmicro devices to write one for.


As for a compiled language itself, I would like to see one that:

1.  Was object orientated in an intelligent way.  Ideally, I would like to
see objects defined in such a way as they can be used from the low-end
architecture devices to the PIC18Cxxx.  Objects should be able to built from
pre-existing objects.

I'm not sure about the need to dynamically instantiate objects in an MCU
environment - comments?

2.  This may be redundant with the previous point, but make the language
procedural with local variables (and the memory they use) separate from
other functions or subroutines.

3.  Allowed re-enterent Interrupt handlers that can call functions and
subroutines anywhere in memory.  This should not be difficult to do for the
PIC18Cxxx, but will be a considerable challenge for the earlier
architectures.

4.  Decide how you are going to handle assembler.  I am coming to the
conclusion that high level PICmicro languages should not have any - it is
just too difficult to decide which resources have to be saved before
executing assembler.

Depending on the amount of resources that have to be saved, you will
probably find that it is almost impossible to add efficient assembler code
to the application.  Depending on the variable memory scheme that you use,
it may be a challenge for the programmer to come up with their own code that
can access the application's variables.

5.  During compilation, dynamically determine what is the best memory
allocation scheme.  You may find that for small applications, simply
assigning a register file for each variable (global or local) is most
efficient.  For larger applications, you may find that you have to implement
a data stack.

6.  At least have 16 bit arithmetic variables and have the arithmetic
operations support them.  Note that this can be very complex depending on
the size of the data types in a statement's parameters as well as
definitions.

Ideally, you should also have array variables of 8 and 16 bit values.


I'm wearing my asbestos suit so let me know what you think,

myke

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body