Searching \ for '[PIC]: Compiler' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Compiler'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Compiler'
2001\06\28@184831 by Patrik Husfloen

picon face
I was thinking of writing a compiler for PIC uCs
so I was curious if you guys think another programming language would be a good idea..
I'm not gonna start writing it if everyone thinks the idea sucks :)

I also figured you guys would have a lot to say when it comes to features and design since you are the eventual users.
It would be free, of course, open source, havn't decided yet.
OSS has pros and cons just like everything else.

well, your thoughts on the idea of a new language would be greatly appriciated.

just a though,

Patrik

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\06\28@191420 by michael brown

flavicon
face
Patrick,

I think that's an ambitious but great project.  Be forewarned that many here
will, in all probability, do their best to discourage you.  They will tell
you that: you are wasting your time, open source is stupid, no one needs it,
and any number of other discouraging statements.  My advice is don't let it
get you down.  If you want to write a compiler, then jump right in with both
feet and don't look back.  I wish you the best of luck. ;-)

I probably will have upset some list members by this.  Oh well, you can't
please everyone and don't bother to try.  The piclist is a wonderful
resource if you are looking for technical help or engineering advice.  If
you are looking for moral support, this might not be the best place.  After
witnessing the discouraging comments made to another member wishing to
design a freeware programmer, I feel "obligated" to warn you of this.

Good luck and go for it. ;-)

Michael Brown
Instant Net Solutions
http://www.KillerPCs.net

"In the land of the blind, he who has one eye is king"

{Original Message removed}

2001\06\28@200522 by Roy Souther

flavicon
face
There are enough C compilers, how about a Pascal compiler. Or better yet a
state model diagram programming language of your own creation.

On June 28, 2001 04:27 pm, you wrote:
{Quote hidden}

--
Roy Souther <spam_OUTroyTakeThisOuTspamsilicontao.com>

01100010 10101110 11000110 11010110 00000100 10110010 10010110 11000110
01001110 11110110 11001110 00010110 10010110 00101110 10000100 10000100

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\06\28@203657 by Drew Vassallo

picon face
Instead of starting yet another compiler, why not continue/complete the
PICLite language compiler.  It's a nice "C"-like language that seems pretty
intuitive, yet never really got to the point where lots of people used it.
I would think that if it were cleaned up and promoted a little, people might
be inclined to start using it as beginners.

I really only program in assembly, so I guess I probably wouldn't switch
over, but maybe others would.  Beginners might benefit most, I imagine.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\06\28@205407 by Mike Hardwick

flavicon
face
Well, if I had my 'druthers, I'druther have a first-class PIC Forth
compiler. Compiled Forth seems more suited to small embedded systems than
anything else I've used. Interactive debugging, small code size, high
execution speed, short learning curve, etc. One thing I would change,
tho... Forth assemblers rub me the wrong way. I would STRONGLY prefer to
use conventional assembly language inline with high-level Forth.

Mike Hardwick
http://www.decadenet.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\06\28@214420 by michael brown

flavicon
face
WARNING-Disjointed random thoughts follow:

You might look into the 'B' language from days gone by to get some ideas.  I
like Mike Hardwick's ideas also as Forth is an interesting and quite
functional language.  Perhaps some kind of object oriented low level
language where you still have the capability to run time sensitive code but
with the added pre-packaged capabilities similar to the C standard library.
I guess this would be similar to the Hitech C approach of high level
capabilities (LCD I/O, EEPROM access, ADC, statemachine'ing' etc..)

If it has to be a C type syntax, then Perl would be neat on the pic.

Of course this is all pie in the sky wishing, but just trying to offer up
some ideas. ;-)

michael

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\06\28@222416 by victor Faria

flavicon
face
Here is a thought.
there are already several compilers out there.
but software simulators there is only mplab.
it's not user friendly at all,what I was thinking is something more
graphical for new users.
all compilers make hex files so make the sim to work with hex regardless of
the compiler.
make it some thing like the alwiliams version for the basic stamp1
http://www.al-williams.com/awce/
basically there is a picture of the pic with leds and switches attached .
then if switches are toggled on and off to represent inputs andled's go on
off for outs
I doesn't tell you about memory and other things.
but what a great learning tool for beginners it gives you a chance to
experiment with software before you jump right in with hardware.
just a thought.
thank you
victor faria
{Original Message removed}

2001\06\28@235746 by Dan Michaels

flavicon
face
Mike Hardwick wrote:

>Well, if I had my 'druthers, I'druther have a first-class PIC Forth
>compiler. Compiled Forth seems more suited to small embedded systems than
>anything else I've used. Interactive debugging, small code size, high
>execution speed, short learning curve, etc.
.........

If only the Tin Man had a heart, the Scarecrow had a brain, and
the PIC had a stack.

If only.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\06\29@020510 by myke predko

flavicon
face
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 .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2001\06\29@032039 by Vasile Surducan

flavicon
face
On Thu, 28 Jun 2001, michael brown wrote:

> Patrick,
>
> I think that's an ambitious but great project.  Be forewarned that many here
> will, in all probability, do their best to discourage you.  They will tell
> you that: you are wasting your time, open source is stupid, no one needs it,
> and any number of other discouraging statements.

 Not at all ! Michael have right. There are many compilers. But what if
an user don't like any one ? ( for example I hate C, that's why I'm
working in JAL, ( http://come.to/jal ) a sort of friendly pascal.
Some of my toys, in Jal, are at http://www.geocities.com/vsurducan/pic.htm
If you want do to something really cool ( which probably will be
difficult) think to a graphic language as G or to the ancient logo ( with
turtle, remember ? ) There are a lot of hardware people which would love
to play with microcontrollers, why not in a way like Lab View does. Other
pic listers will point to picnpoke site. Ok, but this isn't free or open
project. An open project said a lot about what kind of person is the man
behind that project...
A good compiler has libraries for many devices, forget other
microcontrollers than flash types, thus you'll have fans which will write
libraries and verify your work.
I think you must try !

Sincerely yours, Vasile

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


2001\06\29@090708 by Olin Lathrop

face picon face
>>
I was thinking of writing a compiler for PIC uCs
so I was curious if you guys think another programming language would
be a good idea..
<<

Personally I think C sucks, whether for high level app code or embedded
microcontrollers.  A long time ago I had a bunch of code in a Pascal variant
and needed to make it run on systems that needed to be programmed in C.  I
originally figured I'd convert the Pascal to C and leave it that way.
However, once I learned more about C and all its shortcomings, I didn't want
to loose all the nice things I could tell the Pascal compiler but not the C
compiler.  C not only encourages bad programming practises, it prohibits
good ones.

To make a long story short, I wrote a source to source translator, then
added a Pascal front end and a C back end.  I've been using it ever since.
The translator is really half a compiler because it reads the input language
and forms in-memory structures that describe the program logic in a language
independent way.  The back end looks at this and writes out the information
in the target language.  The difference between this and a compiler is that
the translator produces source code and a compiler produces machine code.

If you decide to do this I would be willing to let you use the translator
source code for free, as long as you distribute all derived executables for
free.  If you (or anyone else) wants to use my code in a commercial product
I will want some form of payment.

This all being said, I will most likely stick to assembler on small resource
limited systems like PICs.  I MIGHT use a compiler if higher level language
and assembly source can be seamlessly integrated in the same source module.
For example, declare complex data structures in the high level language,
access in assembler, etc.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinKILLspamspam.....embedinc.com, http://www.embedinc.com

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


2001\06\29@095310 by Eric James

picon face
myke predko wrote:
>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.

This is based on the implementation.  With something like Basic18 where
assembly
is built into the language, this is not true.



__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

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


2001\06\29@112155 by Mike Mansheim

flavicon
face
> C not only encourages bad programming practises, it prohibits
> good ones.

Can you elaborate on this, or point me somewhere that discusses
this?
Thanks.

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


2001\06\29@114256 by Dan Michaels

flavicon
face
Mike Mansheim wrote:
>> C not only encourages bad programming practises, it prohibits
>> good ones.
>
>Can you elaborate on this, or point me somewhere that discusses
>this?
>Thanks.


Check out the "Great Compiler Flame Wars of 2000"
- about one year ago in the piclist archives [maybe we won't
have to go there again].

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


2001\06\29@122228 by Roman Black

flavicon
face
Patrik Husfloen wrote:
>
> I was thinking of writing a compiler for PIC uCs
> so I was curious if you guys think another programming language would
> be a good idea..
> I'm not gonna start writing it if everyone thinks the idea sucks :)
>
> I also figured you guys would have a lot to say when it comes to features and design since you are the eventual users.
> It would be free, of course, open source, havn't decided yet.
> OSS has pros and cons just like everything else.
>
> well, your thoughts on the idea of a new language would be greatly appriciated.


Hi Patrik, it's a very cool new project but could
turn out to be a lot of work. Don't let anyone put you
off if you really want to do it, the great minds of
history followed their own dreams and not someone
elses.:o)

I like assembler, it is very powerful for doing the
fast port and timer stuff the PIC is ideal for. I am
a skilled C programmer but avoid PIC C and use PIC asm.

One thing I do miss is some of the branching tests,
which can be a pain with the PIC asm and can cost time
and bugs.

Something like:
if(x>=31) goto blah
else if(x==7) goto womble

is very fast and safe to code in C but a bit of a pain
to code in PIC asm.

Maybe some "if" macros could be used to expand the PIC
assembler language and improve coding speed while keeping
the power of PIC asm hardware coding. Maybe this could
even be done within the confines of MPASM macro abilities.
One of those jobs I always reserve for a later day. :o)
-Roman

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


2001\06\29@123938 by Jerry Merrill

flavicon
face
>
>One thing I do miss is some of the branching tests,
>which can be a pain with the PIC asm and can cost time
>and bugs.
>
>Something like:
>if(x>=31) goto blah
>else if(x==7) goto womble
>
>is very fast and safe to code in C but a bit of a pain
>to code in PIC asm.
This is the point of our CVASM16 assembler.  It adds 'higher level'
instructions that handle these issues (while maintaining the lower level
opcodes).  This makes it easy to see and do what you want without having to
deal with double negatives and such.

You mean like:
        CJAE    x,#31,blah   ; Compare, Jump After or Equal
        CJE     x,#7,womble  ; Compare, Jump Equal...

Or even
        CJAE    x,y,someplace ; compare two variables

Jerry


Jerry Merrill

spamBeGonejerrymspamBeGonespamtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814   VOICE:(972) 272-9392
TechTools  PO Box 462101  Garland,  TX  75046-2101

Join our PIC discussion list at
http://www.tech-tools.com/picsource.htm

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


2001\06\29@125209 by Roman Black

flavicon
face
Jerry Merrill wrote:
{Quote hidden}

Hi Jerry, it's still not quite as instinctive as
if(x>=31) goto blah
and with that format you get each line as a self
contained bug-proof branching system. With the
low-level nature of PIC processors I often get caught
having to load a test value somewhere, then compare
it with somthing else, then branch/not branch which
again can be another level of confusion.

Although I love getting at the hardware directly
I still long for one bulletproof line of code
that does branching. It's the minimum I expect from
any decent programming language.
-Roman

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


2001\06\29@130916 by Scott Dattalo

face
flavicon
face
On Sat, 30 Jun 2001, Roman Black wrote:

> Something like:
> if(x>=31) goto blah
> else if(x==7) goto womble

Why not:

   incf   x,w
   xorlw  8
   skpnz
    goto  womble
   andlw  0xe0
   skpz
    goto  blah

Of course, this only works well with Mersenne Primes :).

Scott

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


2001\06\29@131545 by Dan Michaels

flavicon
face
Jerry Merrill wrote:
........
>You mean like:
>         CJAE    x,#31,blah   ; Compare, Jump After or Equal
>         CJE     x,#7,womble  ; Compare, Jump Equal...
>

Living testimony --> similar instructions are included with
the standard Scenix [Parallax ???] assembler, and ho boy,
does it ever make life a whole lot easier.

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


2001\06\29@131748 by Jerry Merrill

flavicon
face
One of us missed something here:

>  if(x>=31) goto blah    ==  CJAE    x,#31,blah
and
   if(x==7) goto womble  ==   CJE    x,#7,womble

'A SINGLE bullet-proof line' in each case

I agree that 'if (x==7) goto...' is more readable (especially for all of us
old C guys) than CJE.... but all of the loading, testing,
branch/not-branching is contained in that single line.


At 11:47 AM 6/29/01, you wrote:
{Quote hidden}

Jerry Merrill

RemoveMEjerrymspam_OUTspamKILLspamtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814   VOICE:(972) 272-9392
TechTools  PO Box 462101  Garland,  TX  75046-2101

Join our PIC discussion list at
http://www.tech-tools.com/picsource.htm

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


2001\06\29@132001 by Roman Black

flavicon
face
Scott Dattalo wrote:
>
> On Sat, 30 Jun 2001, Roman Black wrote:
>
> > Something like:
> > if(x>=31) goto blah
> > else if(x==7) goto womble
>
>  Why not:
>
>     incf   x,w
>     xorlw  8
>     skpnz
>      goto  womble
>     andlw  0xe0
>     skpz
>      goto  blah
>
> Of course, this only works well with Mersenne Primes :).


Hi Scott, with all due respect for your PIC
expertise, you have replaced 2 bulletproof and
simple tests with 7 slightly confusing asm
instructions. I can happily code my tests in PIC
asm, but the simplicity of branching in a "higher"
language has something going for it.

And I wish I knew what the heck "Mersenne Primes"
meant!:o)
-Roman

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


2001\06\29@133128 by Bob Ammerman

picon face
> One thing I do miss is some of the branching tests,
> which can be a pain with the PIC asm and can cost time
> and bugs.
>
> Something like:
> if(x>=31) goto blah
> else if(x==7) goto womble
>
> is very fast and safe to code in C but a bit of a pain
> to code in PIC asm.
>
> Maybe some "if" macros could be used to expand the PIC
> assembler language and improve coding speed while keeping
> the power of PIC asm hardware coding. Maybe this could
> even be done within the confines of MPASM macro abilities.
> One of those jobs I always reserve for a later day. :o)
> -Roman

Just write in "C" with inline assembly language.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

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


2001\06\29@133300 by Scott Dattalo

face
flavicon
face
On Sat, 30 Jun 2001, Roman Black wrote:

>
> Hi Scott, with all due respect for your PIC
> expertise, you have replaced 2 bulletproof and
> simple tests with 7 slightly confusing asm
> instructions. I can happily code my tests in PIC
> asm, but the simplicity of branching in a "higher"
> language has something going for it.

True, but it was all in jest. OTOH, the 2 "bulletproof" instructions are scatter
shot that get expanded into 8 pic instructions. When you know the PIC mnemonics,
then non-standard macros tend to obfuscate the flow, in my experience. My little
snippet, OTOH, was a perfect example in how not to write pic code - without any
comments it's also difficult to follow...

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


2001\06\29@133517 by Roman Black

flavicon
face
Bob Ammerman wrote:
>
> > One thing I do miss is some of the branching tests,
> > which can be a pain with the PIC asm and can cost time
> > and bugs.
> >
> > Something like:
> > if(x>=31) goto blah
> > else if(x==7) goto womble


> Just write in "C" with inline assembly language.


Huh?? But doesn't that require a PIC C compiler??
-Roman

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


2001\06\29@133714 by Bob Ammerman

picon face
<snip>

> > Of course, this only works well with Mersenne Primes :).

<snip>

> And I wish I knew what the heck "Mersenne Primes"
> meant!:o)
> -Roman

Primes with values of the form 2^N-1

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

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


2001\06\29@133732 by Roman Black

flavicon
face
My apologies Jerry, your code does indeed provide
complete single line branching. :o)

So is it possible to add a macro set that turns
CJAE    x,#31,blah
into
if(x>=31) goto blah
??
-Roman


Jerry Merrill wrote:
{Quote hidden}

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


2001\06\29@140554 by Mike Mansheim

flavicon
face
>>> Of course, this only works well with Mersenne Primes :).

>> And I wish I knew what the heck "Mersenne Primes"
>> meant!:o)
>> -Roman

> Primes with values of the form 2^N-1

Very handy, Roman, that you supplied two of these in your
blah, womble example.

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


2001\06\29@141447 by Jerry Merrill

flavicon
face
No....but you are free to write a pre-parser to do it :)

At 12:33 PM 6/29/01, you wrote:
{Quote hidden}

Jerry Merrill

TakeThisOuTjerrymspamspamtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814   VOICE:(972) 272-9392
TechTools  PO Box 462101  Garland,  TX  75046-2101

Join our PIC discussion list at
http://www.tech-tools.com/picsource.htm

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


2001\06\29@142551 by Bob Ammerman

picon face
>Bob Ammerman wrote:
> >
> > > One thing I do miss is some of the branching tests,
> > > which can be a pain with the PIC asm and can cost time
> > > and bugs.
> > >
> > > Something like:
> > > if(x>=31) goto blah
> > > else if(x==7) goto womble
>
>
> > Just write in "C" with inline assembly language.
>
>
> Huh?? But doesn't that require a PIC C compiler??
> -Roman

Sure, but it does meet your requirements quite nicely. You just have to
think of it differently.

Actually, so far I have been a die-hard assembly guy on the PIC, but I am
seriously thinking of going in this direction myself.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

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


2001\06\29@150604 by Olin Lathrop

face picon face
> > C not only encourages bad programming practises, it prohibits
> > good ones.
>
> Can you elaborate on this, or point me somewhere that discusses
> this?

The general problem with C is that it is both syntactically and semantically
too "loose".  It is therefore much more likely that a typo or other mistake
still results in legal C, which the compiler will happily compile.  C also
lacks some useful features that help you write clearer, more portable, or
more maintainable code.  More specifically in no particular order:

1 - C type checking is not very useful.  For example, you can define a
variable to be a character, then go ahead and write integers into it, not
just characters.  In fact, there is no real distinction between characters
and integers.  In Pascal, CHAR and INTEGER are two different data types.
There are built in function to "convert" one to the other when that's what
you really want to do.  Another example of useless type checking is the
ENUMs.  An ENUM is a type that can only take on specific listed values.  In
C the compiler provides no advantage to using ENUMs versus ordinary integers
because it permits ENUM values to be assigned to integer variables.  To be
most useful, type checking should be rigorous, with special mechanisms for
deliberately disabling it when that's what the programmer needs to do.
These mechanisms should be elaborate enough so that they aren't likely to
occur accidentally from typos, etc.  In Pascal, this is handled by "type
transfer" functions and related means.

2 - All C subroutine arguments are passed by value.  If you want to pass
something by reference, you "manually" pass a pointer to it.  Among other
things, you have to remember this in the code for the function and manually
dereference the pointer, usually with a "*".  Other languages allow the
passing method to be declared in the subroutine prototype, and the rest of
the code requires no syntactic changes if the passing method is changed.

3 - C has nothing equivalent to the Pascal SET data type.

4 - Most expressions are allowed to be implied assignments.  This is
absolutely irresponsible language design!  These don't lead to better code
optimization, but they can lead to hard to notice bugs.  There is no down
side to first assigning a value to I, then passing I to a subroutine in two
statements instead of one.  Forcing it to take two statements makes the
assignment more obvious to a maintenance programmer and makes it less likely
that a typo results in a legal but unwanted assignment.  I wonder how many
100s of million $$ the collective cost of writing "IF (I = 1)" instead "IF
(I == 1)" is up to by now.

5... - There's more but I've got to get back to work, stuff like cryptic
versus verbose syntax, lack of nested subroutines, etc, etc.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, @spam@olinRemoveMEspamEraseMEembedinc.com, http://www.embedinc.com

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


2001\06\29@165913 by Dale Botkin

flavicon
face
Olin,

I agree on every point...  and I'll also say I like it that way.  Call me
a control freak, I dunno...  I hate antilock brakes and traction control
too.  One of the things I *disliked* about Pascal was the number of (my
opinion) silly rules.  If I define a variable, what bloody business is it
of the compiler what I plan to use it for?  I like that I can declare
"char x" or "int x" and use it for whatever I happen to need it for,
including re-using it in the same function for completely different
things.

It took a lot to get me away from assembly, but C was what I needed.
Horses for courses, or in this case horses for owners.

Have a GREAT weekend,
Dale

On Fri, 29 Jun 2001, Olin Lathrop wrote:

{Quote hidden}

--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

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


2001\06\29@165935 by goflo

flavicon
face
Bob Ammerman wrote:
> Just write in "C" with inline assembly language.

Roman Black wrote:
> Huh?? But doesn't that require a PIC C compiler??

Peter H. Anderson put me on to using the CCS compiler
this way - Let the compiler handle register allocation,
logical and conditional tests, and so on - Write time
sensitive code in in-line asm. Works very well.
Check out his C pages if you're interested.

Last time I looked you could get a free CCS demo at
Microchips' site.

regards, Jack

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


2001\06\29@165948 by goflo

flavicon
face
Roman Black wrote:

> Huh?? But doesn't that require a PIC C compiler??

http://www.microchip.com/0/tools/picmicro/code/third/index.htm

Jack

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


2001\06\29@184835 by myke predko

flavicon
face
Hi Eric,

Could you give me a reference to this?

Any time I have tried to write a compiler (and from what I've seen in
commercial products), the need to save and restore context resources (FSR,
STATUS, PCLATH, etc.) in the language adds a significant amount of overhead
to the compiler.

Not only that, there can be significant issues with accessing declared
language variables from assembler - especially if the variables are locally
declared and stack based.  "Housekeeping" variables needed by the language
for execution may have to be place "outside" of where the user is likely to
access them, which means the execution of the language statements is less
efficient to allow for easier assembler coding.

If this is not an issue with Basic18, I'd love to see how the authors
prevented assembler statements from being a significant problem.

I'm not trying to be defensive - it's just that this has been a considerable
issue for me when I have approached writing PICmicro compilers. I'm always
interested in understanding how things are done better than what I've been
able to come up with.

myke
{Original Message removed}

2001\06\29@194635 by Scott Dattalo

face
flavicon
face
On Fri, 29 Jun 2001, myke predko wrote:

> Hi Eric,
>
> Could you give me a reference to this?
>
> Any time I have tried to write a compiler (and from what I've seen in
> commercial products), the need to save and restore context resources (FSR,
> STATUS, PCLATH, etc.) in the language adds a significant amount of overhead
> to the compiler.
>
> Not only that, there can be significant issues with accessing declared
> language variables from assembler - especially if the variables are locally
> declared and stack based.  "Housekeeping" variables needed by the language
> for execution may have to be place "outside" of where the user is likely to
> access them, which means the execution of the language statements is less
> efficient to allow for easier assembler coding.

While I haven't yet incorporated inline pic assembly in SDCC
(http://www.dattalo.com/gnupic/sdcc.html) I got around the variable housekeeping
by making the register allocation very flexible. Essentially, the SDCC PIC port
creates a call tree and analyzes the local variable requirements at each node.
As variables are needed, they're sequentially declared (until all of memory is
consumed). Overlaying is automagically taken care of by re-allocating registers
as they go in/out of scope. There is no data stack in the SDCC pic port (and
consequently recursion is not supported...).

I haven't even begun to think about the inline assembler, but when I do (or if
someone else does), I'd make it such that the assembler can use C-declared
variables (without any mangling). As long as the variables are declared in C,
the register allocation will not be an issue.

Scott

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


2001\06\29@200946 by myke predko

flavicon
face
I have an include file which provides this capability in macros.  Let me
know if you are interested in seeing it.

myke
{Original Message removed}

2001\06\29@201411 by Olin Lathrop

face picon face
> If I define a variable, what bloody business is it
> of the compiler what I plan to use it for?

That's one way to look at it, thinking of the compiler as the enemy between
you and the machine code.

But, for a moment, think of the compiler as a friend trying to help you get
to the same ultimate machine code.  If you tell the compiler how you plan on
using a variable up front, then it can point out places where you are
breaking your own rules.  You can then say "Oops, thanks for catching that",
or "no, I really do want to do this".  Now think of the poor maintenance
programmer (or you two years later).  His life will be a lot easier if he
can see you've set up rules for how you are using your variables, and he
knows the compiler verifies those rules are followed except in the cases
where there's some nice obvious syntax for the "no, I really do want to do
this" cases.

I've also noticed that when I feel like I'm fighting the type checking
rules, that I usually didn't design the software right.  In fact, I use that
sort of thing now as a flag to step back and look at the overall design
again.  Most of the time, I realize that I had been trying to hammer a
square peg into a round hole.

In short, I think that the little extra effort of some declarations and
following some rules pays back many fold  -  but only if you have the right
mindset to look at it that way.  As long as you look at type checking as a
nuisance, you aren't likely to let it help you.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinSTOPspamspam@spam@embedinc.com, http://www.embedinc.com

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


2001\06\29@214210 by Dale Botkin

flavicon
face
On Fri, 29 Jun 2001, Olin Lathrop wrote:

> > If I define a variable, what bloody business is it
> > of the compiler what I plan to use it for?
>
> That's one way to look at it, thinking of the compiler as the enemy between
> you and the machine code.

Nah...  it's not my enemy.  Well, C isn't anyway.  It's just a very
elpful, very knowledgable but not too terribly bright assistant who's good
at translating my code into binary.  There have been a few compilers I
thought were acting like my enemy.

> But, for a moment, think of the compiler as a friend trying to help you get
> to the same ultimate machine code.  If you tell the compiler how you plan on
> using a variable up front, then it can point out places where you are
> breaking your own rules.

Ah, that's where the model starts to show cracks for me.  When I'm writing
for the PIC, the rules mean just what I intend for them to mean - nothing
more, nothing less.

{Quote hidden}

Agreed.  I think a lot of my attitude toward letting the compiler do that
sort of thing springs from my typing skills (or relative lack thereof) - I
like a terse language.  And yes, I do find other peoples' C code cryptic
as hell if they have not documented well.  I write, debug, fix, THEN
comment & document, which may seem strange to yoiu but works for me.

I suppose if I were coding all the time -- which I don't, this is a hobby
and part-time sideline income for me -- I would probably better appreciate
the more picky compilers, and would probably use them similar to the way
you do.  C relieves me of the burden of needing to manage every single
register, lets me write code much faster than I coule write assembly and
produces results that, while they may not always be as elegant or as
efficient as I could do with lots more time and effort in ASM, are done on
time and work very well.  As for why I (finally) learned C to progream
PICs...  well, I saw BASIC and C compilers that supported all PIC
processors and pretty much nothing else.  I just couldn't bring myself to
write code in BASIC...

Of course, if you want NO type checking of any sort and a language that
far exceeds C in its willingness to let you screw yourself into oblivion,
there's always assembler!

Dale
--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

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


2001\06\29@232225 by Bob Ammerman

picon face
I did a LOT of development in Pascal before moving on to C/C++ and I have to
say that Pascal's tighter type checking made a lot of sense. It is only with
the newer flavors of C++ that we are approaching the protection provided by
Pascal.

OTOH, I found myself regularly working around the restrictions imposed by
Pascal, but that was a good thing ( (c) Martha Stewart ) because it made
explicit the places I was doing something 'funny'.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2001\06\30@004722 by jeethur

flavicon
face
Great Idea Patrick.

I don't think that C will be a good language for Pics.
The most obvious idea I can give you is that you can
join Scott Dattalo on his "PIC port of SDCC" Project.

SDCC is a good Open Source  retargetable C compiler which was
written by Sundeep Datta. There are many different ports of it.
These include AVR, Z80 , 8051 etc.

Scott is trying to write a PIC version of it.

C is built on functions. And calling functions needs
stacks. But pics don't have stacks which you can push and pop at your will.

So, its best to go for some other system.
JAL is a pretty good alternative. And its quite well evolved now.
JAL is specifically targeted at Low End and Mid Range PICs.
Jal Right now is not open source.
And any new suggestion or feature requested for JAL takes months to
Implement.
And the latest problem is that the Documentation of JAL is quite a lot older
than
its latest compiler (jal0435).

How about an Open Source variant of Jal ?

call it OJAL or whatever.

I always wanted to write a Peep Hole optimizer.
Maybe I could be of some help in the later stages of your Project.

Regards,

Jeethu Rao




{Original Message removed}

2001\06\30@004736 by jeethur

flavicon
face
Don't you worry Patrick,

I'm sure there are a lot of PicListers badly in need of a good freeware
Compiler.
And they'll surely encourage you (Count me in them).

Jeethu Rao

{Original Message removed}

2001\06\30@004745 by jeethur

flavicon
face
Hey,
I believe a PIC can have a stack. This is especially true for 16f877.
On a 16f877, the RAM on bank 3 is used rarely and the 80 bytes of ram in
bank 4 is used very very rarely. So, if we could write a piece of code which
could
just Push and Pop the value in the W register, we could have a working stack
of
around 75 bytes (5 bytes for housekeeping). And thats quite good for a PIC I
believe.
As a matter of fact, I've already written the code for a Stack Library with
underflow
and overflow protection. Do tell me if you are interested in it.

I had always dreamt of a Compiler for PIC 16F877s with recursive functions.
JAL can't do it (It does'nt have a stack). But PUSHW and POPW instructions
are quite
hefty. they take around 5 to 10 instructions. But I believe thats ok with
the advantage
which stack gives.

Jeethu Rao

{Original Message removed}

2001\06\30@004806 by jeethur

flavicon
face
Hi Myke,

Your ideas are very good. But I disagree with you regarding the external
Assembler.
Its best to have an internal assembler. The problem is, some errors can only
be trapped
in assembler. For instance, how do you check the syntax of Inline assembly
code ?
Its best to write a basic and low end assembler with no fancy features like
Macros and Conditional Assembly. All these things are not needed because the
assembler
will already be getting pure code from the compiler.

As for 18cxxx chips, they're high end and ain't just as cheap as 16f84 or
16f877.
I personally have never used PIC17Cxx and the PIC18Cxx.

I'm just waiting for Microchip to release their PIC18Fxxx series Flash MCUs.
I guess that is going to bring PIC18Fxx to the fame an status currently
enjoyed
by 16f87x series. But your suggestion is pretty good because when Microchip
eventually
releases the 18F series MCUs, we would atleast have Patrick's compiler (If
he develops one)
as an alternative to assembler coding.

Jeethu Rao

<snip>
myke pedko
>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.

</snip>

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu


2001\06\30@010357 by Dan Michaels

flavicon
face
Jeethu Rao wrote:
>Hey,
>I believe a PIC can have a stack. This is especially true for 16f877.
>On a 16f877, the RAM on bank 3 is used rarely and the 80 bytes of ram in
>bank 4 is used very very rarely. So, if we could write a piece of code which
>could.....


You can certainly simulate a stack in s.w., but I think you
might lose too much performance by trying to execute a language
like Forth, which is so heavily stack-dependent, on a stock PIC.
My guess is you would end up with something that would give a
Basic Stamp a good run for its money.

OTOH, maybe some of the newer PICs with better stack access
and multiple FSRs would make a more suitable platform for Forth.

[BTW, I am probably one of few piclisters who still uses Forth
regularly - any others ???].

- dan
===========


>
>{Original Message removed}

2001\06\30@015502 by Chris Carr

flavicon
face
> One of the things I *disliked* about Pascal was the number of (my
> opinion) silly rules.

In my limited experience it always pays to remember what the primary
objectives of the original language were.

Pascal was designed to teach good programming practices. The basic theory
being that once you understand good programming practices then you aware of
the implications of bending the rules.

Chris Carr

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspam_OUTspam@spam@mitvma.mit.edu


2001\06\30@025515 by Chris Carr

flavicon
face
> Jeethu Rao wrote:
> >Hey,
> >I believe a PIC can have a stack. This is especially true for 16f877.
> >On a 16f877, the RAM on bank 3 is used rarely and the 80 bytes of ram in
> >bank 4 is used very very rarely. So, if we could write a piece of code
which
> >could.....
>
Dan Michaels wrote
>
> You can certainly simulate a stack in s.w., but I think you
> might lose too much performance by trying to execute a language
> like Forth, which is so heavily stack-dependent, on a stock PIC.
> My guess is you would end up with something that would give a
> Basic Stamp a good run for its money.
>
> OTOH, maybe some of the newer PICs with better stack access
> and multiple FSRs would make a more suitable platform for Forth.
>
Hmm, I must revisit the Datasheets. Hardware Stack and 16 bits
are the main requirements if I remember correctly.

> [BTW, I am probably one of few piclisters who still uses Forth
> regularly - any others ???].
>
Own a set of reference books (all out of print), 4 Jupiter Aces, and still
wear the Kaftan. 8-)

2 projects under way at the moment using Forth

Chris Carr

> >Mike Hardwick wrote:
> >
> >>Well, if I had my 'druthers, I'druther have a first-class PIC Forth
> >>compiler. Compiled Forth seems more suited to small embedded systems
than
{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamKILLspammitvma.mit.edu


2001\06\30@044746 by Roman Black

flavicon
face
Dale Botkin wrote:

> Agreed.  I think a lot of my attitude toward letting the compiler do that
> sort of thing springs from my typing skills (or relative lack thereof) - I
> like a terse language.  And yes, I do find other peoples' C code cryptic
> as hell if they have not documented well.  I write, debug, fix, THEN
> comment & document, which may seem strange to yoiu but works for me.


C language is low level enough that it can be used
and abused. I get Olin's points completely, re the
possibility of bad C declarations and misused typecasting,
and I had the "joy" of working with a 18yr old C "expert"
on a programming team. What's a comment? Who needs them?

I write C like my assembler, with 1 to 3 lines of comments
to every line of code.

My normal programming practice in any language is to type
the thing in well commented "psuedo code", debug the entire
thing in that manner, then add the opcodes later and it
works. It was fun being on a team with young guys who code
things up very quick, then I watched them spend days trying
to find their bugs. Usually I ended up helping them debug
their code and the only way to do it was do pull it all
apart and comment it from scratch, which always showed
up the silly mistake they made from rushing it. A real
tortoise and hare scenario. :o)

So I look at C like assembler, its fantastic if it's
done right. It's the worst nightmare if done wrong.
I also have to disagree with Dale's system above, I
think good code is refined and debugged before the
opcodes are added. Separate the procedures from the
code totally, then when the procedures are perfect
any monkey can type the opcodes in. But Dale probably
produces code at 10x the speed that I do! :o)
-Roman

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspam_OUTspamRemoveMEmitvma.mit.edu


2001\06\30@074518 by Walter Banks

picon face
Writing compilers is a large exercise in attention to detail. It is also
deceptive,
a working compiler can be achieved with very little effort perhaps as little as
three
or four man days. A good effective embedded systems compiler will take
man years.

Our recent compilers have been consistently winning benchmarks against well
written hand coded assembler. Compilers in embedded sytstems have three
advantages over hand coded assembly implimentation:
 1) Allocation of resources. Computers are good at managing a processors
     resources according to some well defined allocation scheme.
 2) Compilers can use instruction set sequences that if used in assembly
language
     would be very difficult to maintain.
 3) Compilers get to create code anew every time they are used and they
     don't have to incorporate changes into previously implimented code.
     The compare sequence that Scott posted yesterday is an good example of
this.
     If the 7 or 31 constant in the compares changed then the whole code
     sequence would need to be changed. In a compiler generated code his
     code is perfectly reasonable and would change without implimentor
inervention
     if the constants changed.


> Any time I have tried to write a compiler (and from what I've seen in
> commercial products), the need to save and restore context resources (FSR,
> STATUS, PCLATH, etc.) in the language adds a significant amount of overhead
> to the compiler.

Context saving in a compiler is just as important as in assembly code and
needs the same care. There is no need for the compiler implimentation to
generate
more overhead than the assembly equivalent.

{Quote hidden}

Variable access including locals is essentially a scoping problem. In MPC
assembly code accesses C variables by name and the access is controlled by
haveing the same scoping rules as C.

Walter Banks

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspamRemoveMEmitvma.mit.edu


2001\06\30@101717 by Dale Botkin

flavicon
face
On Sat, 30 Jun 2001, Roman Black wrote:

> So I look at C like assembler, its fantastic if it's
> done right. It's the worst nightmare if done wrong.
> I also have to disagree with Dale's system above, I
> think good code is refined and debugged before the
> opcodes are added. Separate the procedures from the
> code totally, then when the procedures are perfect
> any monkey can type the opcodes in. But Dale probably
> produces code at 10x the speed that I do! :o)
> -Roman

I really doubt the end result (working, debugged, solid code) comes any
faster.  I do have to admit, though, I tend to do a lot of my software
debugging by playing with the hardware to see what the software is
doing...  I find it enjoyable, and it often leads to some interesting
ideas that I wouldn't have thought of if I were looking only at the code.

Dale
--
A train stops at a train station.  A bus stops at a bus station.
On my desk I have a workstation...

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspam@spam@mitvma.mit.edu


2001\06\30@103208 by Eric James

picon face
myke predko wrote:
>Hi Eric,
>
>Could you give me a reference to this?
>
Basic18 is available at
http://basic18.piclist.com

>Any time I have tried to write a compiler (and from what I've seen in
>commercial products), the need to save and restore context resources (FSR,
>STATUS, PCLATH, etc.) in the language adds a significant amount of overhead
>to the compiler.

The only overhead Basic18 adds to assembly language statements is setting up
the BSR register if needed to access the proper RAM bank

>
>Not only that, there can be significant issues with accessing declared
>language variables from assembler - especially if the variables are locally
>declared

 The variable is automatically renamed (or remapped) by the compiler.

>If this is not an issue with Basic18, I'd love to see how the authors
>prevented assembler statements from being a significant problem.

Download the compiler from the above link and take a look.  If you have any
questions you can email me at EraseMEejames2RemoveMEspamSTOPspamyahoo.com

>I'm always
>interested in understanding how things are done better than what I've been
>able to come up with.

Same, here

Eric


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspamTakeThisOuTmitvma.mit.edu


2001\06\30@112854 by dr. Imre Bartfai

flavicon
face
On Sat, 30 Jun 2001, Roman Black wrote:

--- [snip]----
> Something like:
> if(x>=31) goto blah
> else if(x==7) goto womble

What about the following:

       CJAE    x,#31,blah
       CJE     x,#7,womble

This is the Parallax-like dialect.

As I begun to program PIC I insisted on MPASM. Now, I do not. I use C
(CCS), PBP and CVASM16 (which supports also the dialect above).

Regards,
Imre

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspam@spam@mitvma.mit.edu


2001\06\30@213848 by Olin Lathrop

face picon face
> I believe a PIC can have a stack. This is especially true for 16f877.
> On a 16f877, the RAM on bank 3 is used rarely and the 80 bytes of ram in
> bank 4 is used very very rarely. So, if we could write a piece of code
which
> could
> just Push and Pop the value in the W register, we could have a working
stack
> of
> around 75 bytes (5 bytes for housekeeping). And thats quite good for a PIC
I
> believe.
> As a matter of fact, I've already written the code for a Stack Library
with
> underflow
> and overflow protection. Do tell me if you are interested in it.
>
> I had always dreamt of a Compiler for PIC 16F877s with recursive
functions.
> JAL can't do it (It does'nt have a stack). But PUSHW and POPW instructions
> are quite
> hefty. they take around 5 to 10 instructions. But I believe thats ok with
> the advantage
> which stack gives.

I have a software stack implemented via my PUSHREGS and POPREGS macros in
STD.INS.ASPIC at http://www.embedinc.com/pic.  These macros push and pop any
subset of the "general registers" also defined in that file.  I use the
stack mostly so that subroutines can preserve the general registers to the
caller but use them as scratch internally.  This is built into the GLBSUB,
LEAVEREST, and other macros.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinspam_OUTspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspammitvma.mit.edu



'[PIC]: Compiler'
2001\07\01@234751 by jeethur
2001\07\02@001548 by Dan Michaels
flavicon
face
Jeethu Rao wrote:
>Dan, you can't change my mind. I've become a Software Stack fanatic.
>Software Stack is worth the striving for.
>And I don't think it'll make a PIC analogous to a Basic Stamp
>in performance.Remember BS is interpreted and PIC native code.
>running even a simple a = b assignment will take atleast 20-25 cycles
>on a BS. Thats what makes Java slower than C or C++.
>

Jeethu, I wasn't really trying to change your mind. I really
would like to see a good Forth for the PIC [maybe there already
is one ???]. As I understand it, programmers in India, especially
Bangalore I believe, have a strong reputation, and I would be
interested to know what kind of performance you could milk out
of Forth.

It does have the great advantage of building compact programs,
of course. In the PC world, I would say my Forth programs are
maybe 5X smaller than if done in C [using DOS, not windoze].

However, speaking from a more practical perspective, one probably
could not make much money from a Forth compiler for PIC, if that was
their intent. Forth was popular a few years ago in the microcontroller
world, but today Basic and C appear to be the big bread winners,
so .........
============


>Anyway, your've got a good Idea out there. We can make something
>similar to the BS and we could write a specially optimized interpreter
>for the production release of that particular program. Sort of pseudo
>native code (Just like what VB 5 used to do). By pseudo native code,
>I mean that the whole program would be written as a set of calls to
>the Run Time Library.
>
>A lot faster than BS but just as easy!
>

Well that is basically what Forth does, of course. The whole program
is just stored as a series of addresses of functions, and you drill
down through the levels, passing down your parameters, and eventually
get down to the core functions, which are in native code [if you
have a fast implementation]. From benchmarks I recall seeing years
ago, Forth was typically about 2X or 3X slower than a "compiled" C or
Basic implementation, but I think on the PIC with stacks implemented
in s.w., it would be much worse. This is just my gut feeling.

cheers,
- dan michaels
http://www.oricomtech.com
========================

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\02@024158 by Dmitry Kiryashov

flavicon
face
Hi Walter.

<skipped>
> Our recent compilers have been consistently winning benchmarks against well
> written hand coded assembler....
<skipped>

This is really provocative suggestion. ;)

WBR Dmitry.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\02@083157 by Eric James

picon face
Olin Lathrop writes:

>This all being said, I will most likely stick to assembler on small resource
>limited systems like PICs.  I MIGHT use a compiler if higher level language
>and assembly source can be seamlessly integrated in the same source module.
>For example, declare complex data structures in the high level language,
>access in assembler, etc.

 That is one of the things I set out to do when I started writing my compiler
Basic18.  Assembly and Basic code can be intermixed seamlessly.

For example, here is a small Basic program mixing basic and assembly

---------------------------------------------------------------------
Include <libs\18c452.bas>

Sub main()
       Dim a As uByte

       a=10
       movlw 5
       addwf a,F

End Sub

---------------------------------------------------------------------
Compiling this program results in the following assembly file

                       ;Sub MAIN()
MAIN
                       ;Dim A As uByte
                       ;A=10
       movlw   10
       movwf   MAIN@A+0,0
                       ;movlw 5
       movlw    5
                       ;addwf A,F
       addwf   MAIN@A,F,0
                       ;End Sub
       sleep
       Goto    MAIN
       End

Eric,
spam_OUTejames2spam_OUTspamspam_OUTyahoo.com



__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\02@123648 by dpharris

picon face
I'd be interested in a Forth.  I think the new 18Fxxx series of PICs due
out (any day now) will revolutionize the field.  They are much more regular
in terms of address space, stacks etc; and getting a good Forth will be
much easier.  Basic 18 certainly looks interesting too.
David

Dan Michaels wrote:

{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\02@165609 by Bob Ammerman

picon face
Note that Walter didn't say:

> > Our recent compilers have been consistently winning benchmarks against
well
> > written hand coded assembler thats takes advantage of all sorts of
strange tricks and is nearly unmaintainable.

That would be both another story, and not necessarily a fair competition.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)


{Original Message removed}

2001\07\02@204505 by James Newton. Admin 3

face picon face
I'd like to see it...
...at piclist.com or at least linked from there.

James Newton, PICList Admin #3
jamesnewtonspam_OUTspampiclist.com
1-619-652-0593 phone
http://www.piclist.com

{Original Message removed}

2001\07\02@235544 by jeethur

flavicon
face
Hey Dan,

I guess the bottom line that anyone would consider while
going for a compiler would be the Generated Code Size
and Ram Usage. If both of them are low, I don't think people
would mind Learning a new langauge. That is one of the reasons
for the success of C. (The other is portability.)

If there is one thing which all compiler writers would love
to add to their compiler, Its a good State Analyzing Optimizer.
Not exactly the kind of Peep Hole Optimizer which most compilers
sport. But this is far too Intelligent and *slower*(well, just a bit
slower!).

I'm thinking of writing an Optimizer for PIC Hex Files.
It would take in a hex file, Disassemble it, and then
try various optimizations. It might even go ahead and
remove certain pieces of code like redundant Bank Selection code,
Page selection code etc. I've discovered that JAL0435 adds interrupt
handler code even if you don't use interrupts. It even does a lot of
redundant page selections on a 16f877. I want to go way beyond the
normal Peep hole optimizers. This I got this Idea from Scott Dattalo,
while he was writing a peep hole Optimizer for the PIC Port of SDCC.

I would prefer to target only PIC16f877, since there is a lot of scope
for optimizations on it. Later on, we could go in for other families
like PIC12,17 and 18.

About 6 months back, I had written a few libraries for Loading and saving
HEX files in Euphoria Language. I had done it for my Programmer Project.
Now, this LIB is going to be really handy in any PIC development project.
Literally all of the PIC development activity is based on the Intel Hex
format.

How about starting a thread on Peep Hole Optimization ?

Jeethu Rao



{Original Message removed}

2001\07\03@080012 by Olin Lathrop

face picon face
> I'm thinking of writing an Optimizer for PIC Hex Files.
> It would take in a hex file, Disassemble it, and then
> try various optimizations.

This is impossible in the general sense.  For example, suppose you
encountered

  MOVLW h'3A'

That could be the low or high byte of an address, or just an arbitrary
constant.  There are lots of other gotchas too.  You need to know the
original intent of the code to do any meaningful optimizations.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\07\03@105139 by Scott Dattalo

face
flavicon
face
On Tue, 3 Jul 2001, Olin Lathrop wrote:

> > I'm thinking of writing an Optimizer for PIC Hex Files.
> > It would take in a hex file, Disassemble it, and then
> > try various optimizations.
>
> This is impossible in the general sense.  For example, suppose you
> encountered
>
>    MOVLW h'3A'
>
> That could be the low or high byte of an address, or just an arbitrary
> constant.  There are lots of other gotchas too.  You need to know the
> original intent of the code to do any meaningful optimizations.

What's good about hex files is that the comments in them exactly describe what's
going on!

IMO, writing an optimizer beginning with the .hex is not the best way to start.
Olin's example above is not really clear, so let me elaborate slightly.
Optimization can't occur on single instructions. Instead it has to occur on a
block of instructions. In other words, the flow of the program must also be
analyzed. This involves disecting the code, creating call trees, etc. But there
are always cases for which a detail analysis is simply insufficient (without
knowledge of the programmer's original intent).

Here are a couple of examples:

1) Isochronous flow.
I write quite a bit of isochronous code. Often times to balance the flow you
have to stick in a few nops or goto $+1's. If you're optimizing for execution
efficiency, then these will be removed.

2) I/O bit toggling.

 bsf   ioport,iobit  ; actually, don't do this
 bcf   ioport,iobit  ; because of the rmw bug
 bsf   ioport,iobit

If you toggle an I/O pin, then it's state at the beginning of the snippet is the
same at the end. From an optimizer's point of view nothing has changed.

3) Interrupt thread processing.
Sometimes I create flags (semaphores) that are changed in an interrupt routine
and polled by non-interrupt code. I don't do this exactly:

   bcf    wait_for_some_interrupt_processing,0

   do stuff that turns on the interrupt and waits for it to trigger

   btfss  wait_for_some_interrupt_processing,0
    goto  $-1

But if the optimizer saw this it'd likely freak.

4) Lookup tables
There are just too many case to enumerate here.

I could go on and on...

Now, I don't think an assembler optimizer is a hopeless case. Certainly a
c-compiler is at liberty to optimize it's generated assembly code because it
knows the context in which the code is generated. If you wanted the optimizer to
work for hand written assembly, then to be robust a set of special optimization
directives would be needed. For example, there may be a `volatile' modifier for
volatile variables like semaphores and mutexes. Or there may be 'table
begin/end' modifiers. An 'isochronous' modifier might be useful. And finally the
'I_am_dmitry_so_do_not_waste_time_optimizing' modifier would be absolutely
necessary!

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\07\03@130523 by mike

flavicon
face
On Tue, 3 Jul 2001 07:31:25 -0400, you wrote:

>> I'm thinking of writing an Optimizer for PIC Hex Files.
>> It would take in a hex file, Disassemble it, and then
>> try various optimizations.
>
>This is impossible in the general sense.  For example, suppose you
>encountered
>
>   MOVLW h'3A'
>
>That could be the low or high byte of an address, or just an arbitrary
>constant.  There are lots of other gotchas too.  You need to know the
>original intent of the code to do any meaningful optimizations.
Not necessarily true. There are a number of 'peephole' optimisations
on short sequences of instructions that can be done with little or no
knowledge of the intent, especially on compiler output (OK the
compiler should do it, but often doesn't) , as long as you can keep
track of things like tables, jump targets and page bits.
I would think that a more realistic project might be something which
analyses the code and suggests areas where improvements could be made,
allowing the user full control.
--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\07\03@150621 by Olin Lathrop

face picon face
> >    MOVLW h'3A'
> >
> > That could be the low or high byte of an address, or just an arbitrary
> > constant.  There are lots of other gotchas too.  You need to know the
> > original intent of the code to do any meaningful optimizations.
>
> Olin's example above is not really clear, so let me elaborate slightly.

Sorry, I'll explain why this is a show-stopping gotcha.  A HEX file contains
raw instructions after address symbols have been resolved and linked.  To do
any meaningful optimizing, you will have to move instructions around.  Since
some instructions will now be at different addresses, you have to adjust the
references to those addresses.  That can be done with GOTO and CALL
instructions, but what about the example above?  Here are a few examples of
the code that could have produced that MOVLW instruction:

  MOVLW   h'3A'     ;get the official number of glorks per snorp
  MOVLW   low table ;get low byte of table start address
  MOVLW   high table ;get high byte of table start address
  MOVLW   low blog+3 ;get address of the count field in the BLOG structure

You're screwed because there is no way to distinguish these cases, so you
have no idea how, if at all, to adjust the 3Ah value.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinspamBeGonespam.....embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\07\03@195455 by Scott Dattalo

face
flavicon
face
On Tue, 3 Jul 2001, Olin Lathrop wrote:

{Quote hidden}

Actually, Olin, I think you mean ADDLW, IORLW or XORLW instead of MOVLW.
Consecutive RETLW's make sense for tables. It makes no sense to have two MOVLW's
in a row unless there is a jump that some how chooses which is executed:

   skpc
    movlw   42
   movlw    69

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\07\03@212215 by Doug Joel

picon face
{Quote hidden}

The consecutive MOVLW's are just examples with the literal 3A meaning 4 different things.
At the hex file stage, there isn't any way for the optimizer to determine what the 3a refers to.
If it's a constant, don't change it.  If it's the start address of a data table and the optimizer moves
the table, then the 3a has be be changed to the tables new address.  It's easier to do at the
source stage or object code stage if we have it.

Doug

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\07\04@081435 by Olin Lathrop

face picon face
> > Sorry, I'll explain why this is a show-stopping gotcha.  A HEX file
contains
> > raw instructions after address symbols have been resolved and linked.
To do
> > any meaningful optimizing, you will have to move instructions around.
Since
> > some instructions will now be at different addresses, you have to adjust
the
> > references to those addresses.  That can be done with GOTO and CALL
> > instructions, but what about the example above?  Here are a few examples
of
> > the code that could have produced that MOVLW instruction:
> >
> >    MOVLW   h'3A'     ;get the official number of glorks per snorp
> >    MOVLW   low table ;get low byte of table start address
> >    MOVLW   high table ;get high byte of table start address
> >    MOVLW   low blog+3 ;get address of the count field in the BLOG
structure
> >
> > You're screwed because there is no way to distinguish these cases, so
you
> > have no idea how, if at all, to adjust the 3Ah value.
>
> Actually, Olin, I think you mean ADDLW, IORLW or XORLW instead of MOVLW.
> Consecutive RETLW's make sense for tables. It makes no sense to have two
MOVLW's
> in a row unless there is a jump that some how chooses which is executed:
>
>     skpc
>      movlw   42
>     movlw    69

I guess I'm really having a problem being clear today.  The four MOVLW lines
above are *INDIVIDUAL* examples of a source line that could have produced
the *SINGLE* MOVLW instruction I was using as an example.  Of course the
same reasoning applies to ADDLW, IORLW, etc, etc, etc.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, KILLspamolinspam.....embedinc.com, http://www.embedinc.com

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


2001\07\04@092238 by jeethur

flavicon
face
Hi Olin,

I liked your constructive criticism.But there are two solution for
the problem you pointed out.

Solution 1:

As soon as the whole Hex File has been loaded and Disassembled,
the Optimizer could search for a pattern like

BSF EECON1,EEPGD
;...(Any or No instructions that Don't modify EECON1)...
BSF EECON1,RD

If this sequence is detected, The optimizer might set a flag.
later on while optimizing, it could ignore instructions which
seem absurd to it.

Solution 2:

There is one more way of detecting it.
Its prudent programming practice to have a goto to skip a table
or any "data" in instructions.

it could be like:

goto skip_table
table:
addwf PCL
dt "0123456789"
skip:
;..(Any instructions)...


Or you might place the table at the end of the program.

If anyone does not do this, most probably his program won't work
as he wants it to(Unless he is someone like Dimitry).

The optimizer could identify these skips and Ignoe the code between them.

But, removing tables which are never called *MUST* be done.

The end user will always have full control over what Optimizations should
be done and what should not be done.

And for a novice user, all optimizations will be realtively safe.
You can always disable the optimizations which you don't like.

Jeethu Rao


{Original Message removed}

2001\07\04@092242 by jeethur

flavicon
face
I got it Scott.

But I'll have to generate a call tree for any serious optimization.

As for the Semaphores, they can be detected by a simple algorithm.

The optimizer won't try to optimize a piece of code waiting for a semaphore
if:

a) If the semaphore you are waiting for is in PIR1 or PIR2 or ADCON0 or
TXSTA etc,


b) If the bit or byte you are waiting for is being written by the ISR
section of the
  code.

I guess these two tests would be quite adequate.

Another culprit is movf x,f .
this instruction may seem unnecessary.
But what if its done to test the Z bit ?

Simple. this can be solved by checking for any
instruction which can modify status register (addlw,andlw,xorlw etc)
before any code which reads status reg.

if status is modified, the movf x,f can be safely removed.

I don't want to complicate the matters for Coders.
Hardcore coders may not need an Optimizer. But I believe
there are a lot of novices and people who use HLLs.
For instance, JAL generates a lot of dead code like
twin gotos,redundant page selection etc.

So, the optimizer won't be needed by everyone.
but anyone who needs it, can use it.

There should also be GUI interface front end programs for
X-windows and Win32.That'll take make it easy for novices.

I'll start a new thread on Assembly Optimization.

Jeethu Rao


{Original Message removed}

2001\07\04@093933 by Eric James

picon face
Jeethu Rao writes

>Its prudent programming practice to have a goto to skip a table
>or any "data" in instructions.
>
>it could be like:
>
>goto skip_table
>table:
>addwf PCL
>dt "0123456789"
>skip:
>;..(Any instructions)...

This might be the case for non 18Xxxx processors, however I usually use a
method similar to the one found at
http://www.piclist.com/techref/microchip/18c/tables.htm

In a case like this it would be very hard for the optomizer to seperate the
table from the instructions.

Eric


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

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


2001\07\04@110612 by Scott Dattalo

face
flavicon
face
On Wed, 4 Jul 2001, Olin Lathrop wrote:

> I guess I'm really having a problem being clear today.  The four MOVLW lines
> above are *INDIVIDUAL* examples of a source line that could have produced
> the *SINGLE* MOVLW instruction I was using as an example.  Of course the
> same reasoning applies to ADDLW, IORLW, etc, etc, etc.

got it...

It'd really be hard for hex optimizer to distinguish whether or not one of the
MOVLW pertains to an address or not. I use this trick and all of the others
mentioned earlier in www.dattalo.com/technical/software/pic/pwm256.txt
. I'd be curious to see what a hex optimizer would do to it! (Actually, I'd
think an assembly level optimizer would have a time with it. [Really actually,
it gives me a headache everytime I look  at it!])

Conclusion: a general purpose hex optimizer is impossible. A general purpose
assembly optimizer would be extremely difficult (impossible) without special
assembler directives describing the programmer's intent. An assembly optimizer
that works off the output of a high-level compiler is possible, but tedious.

Scott

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


2001\07\04@113140 by Scott Dattalo
face
flavicon
face
On Wed, 4 Jul 2001, Jeethu Rao wrote:

> I got it Scott.
>
> But I'll have to generate a call tree for any serious optimization.
>
> As for the Semaphores, they can be detected by a simple algorithm.
>
> The optimizer won't try to optimize a piece of code waiting for a semaphore
> if:
>
> a) If the semaphore you are waiting for is in PIR1 or PIR2 or ADCON0 or
> TXSTA etc,
>
>
> b) If the bit or byte you are waiting for is being written by the ISR
> section of the
>    code.
>
> I guess these two tests would be quite adequate.

Unfortunately they're quite inadequate.

I usually don't wait on individual bits in the SFR's. Instead I create flags in
the general purpose registers. That way I can do some of the "micro" processing
in an interrupt and save the "macro" processing for the non-interrupt code. Now
imagine that I'm tight on ram and rom:


interrupt:
  if a2d interrupt call read_and_store

 end of interrupt


main:

 use the variable "FLAG" as a loop counter to initialize
 something.


 call read_and_store N times to fill up a sample's array
loop:
 clear FLAG
 enable interrupts

wait_flag:
 if FLAG is clear then goto wait_flag

 disable interrupts

 use the variable "FLAG" as a loop counter again
 do something with A2D data

 goto loop


read_and_store:
 read a2d converter,
 store result in an array
 set FLAG after N samples
 return


Here, the variable called "FLAG" is not only a semaphore, but because of RAM
constraints it doubles as a loop counter. The fact that the routine that sets
the flag is called from an interrupt and from the non-interrupt code clearly
obfuscates FLAG's use as a semaphore.

This is a contrived example that I whipped out. But I'm quite certain that I and
others can contrive many other examples that prohibit a general purpose hex
optimizer from working.

{Quote hidden}

This is a simple example and as you suggest, following the flow of the code can
determine whether this instruction can be removed. There are other little
snippets that are easily optimized:

  btfsc  some_bit
   goto  L1
  goto   L2
L1
  incf   some_reg
L2

Can be optimized:

  btfss  some_bit
   incf  some_reg

But as Olin noted, removing those two instructions can have a catastrophic
affect on code elsewhere.

Scott

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


2001\07\04@210629 by Olin Lathrop

face picon face
> As soon as the whole Hex File has been loaded and Disassembled,
> the Optimizer could search for a pattern like
>
> BSF EECON1,EEPGD
> ;...(Any or No instructions that Don't modify EECON1)...
> BSF EECON1,RD
>
> If this sequence is detected, The optimizer might set a flag.
> later on while optimizing, it could ignore instructions which
> seem absurd to it.

I don't see what this does for you.  So you can detect code secquences that
might be attempts to read or write the program memory.  Even if you got this
100% right it doesn't address any of the show stopping issues I described.

{Quote hidden}

Again, this is addressing only a tiny part of the problem at best.

> And for a novice user, all optimizations will be realtively safe.

I don't think there are any meaningful optimizations that can be performed
on the final instructions only that are safe.  As soon as you move an
instruction, you could be breaking references to that address with no way to
detect some of those references.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinspamBeGonespamRemoveMEembedinc.com, http://www.embedinc.com

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


2001\07\05@081244 by jeethur

flavicon
face
Hi Olin,

Detecting and Adjusting references is one of the most basic things an
optimizer should be capable of doing. This is especially true on a PIC
since there are only 2 instructions capable of directly modifying the
program counter, CALL and GOTO. And there might also be instructions
which add/move/subtract(i've never seen this) to the PCL register.
This should be no trouble detecting.

Jeethu Rao


> I don't think there are any meaningful optimizations that can be performed
> on the final instructions only that are safe.  As soon as you move an
> instruction, you could be breaking references to that address
> with no way to
> detect some of those references.

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestSTOPspamspam@spam@mitvma.mit.edu


2001\07\05@081257 by jeethur

flavicon
face
Eric,
Do remember that the optimizer is for PIC16 family. Not PIC18s right now.
But it could be possible in the near future.
And, you'll have quit a lot time before you bump into the bounds of PIC18s,
Since they have a lot more Program memory, RAM and Instructions to play
with.

Jeethu Rao

> {Original Message removed}

2001\07\05@081301 by jeethur

flavicon
face
Scott,

As you had suggested earlier, you can always use the
"-im_a_dimitry_dont_waste_time_optimizing" command line option if
you write real tight and terse code.

But, the prime targets for optimizations are the code generated
by compilers (JAL code can be quite heavily optimized).
Many JAL coders are new to PICs have little or no experience in
assembly coding and optimizations. If something could optimize
compiler generated code for them, it would be a great boon to them.
Why JAL, I think even commercial C compiler generated code might be
optimized.

And, I've actually worked out an algorithm to compensate addition/removal
of code. Even the most rudimentary optimizers must be able to compensate
for Addition/Removal of code. The key to this is Addition/Removal of code
one word at a time and then running an analysis pass on the whole code to
fix
the errors caused by Addition/Removal of the word. It will be a bit slow,
But it
certainly is possible.

Jeethu Rao

> {Original Message removed}

2001\07\05@090753 by Olin Lathrop

face picon face
> Detecting and Adjusting references is one of the most basic things an
> optimizer should be capable of doing. This is especially true on a PIC
> since there are only 2 instructions capable of directly modifying the
> program counter, CALL and GOTO. And there might also be instructions
> which add/move/subtract(i've never seen this) to the PCL register.
> This should be no trouble detecting.

I think we're going in circles here.  A few posts ago I should, as an
example, a MOVLW instruction that might or might not need to be adjusted
depending on the program intent.  The problem is that there is no way to
know that intent by just looking at the final instructions.  It's not just
instructions that modify the program counter that matter.  Any reference to
a program memory address needs to be adjusted, and there is no way to find
all the instructions that do this.

I've been trying to say basically the same thing for several posts in a row.
Maybe I'm not explaining this well, but either way I'm getting tired of it.
Perhaps others can jump in here, I'm done responding to this issue.  Believe
what you like.  Go ahead and try it.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinspamBeGonespamspamBeGoneembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspammitvma.mit.edu


2001\07\06@235455 by Bob Ammerman

picon face
Jeethru said:


> > Detecting and Adjusting references is one of the most basic things an
> > optimizer should be capable of doing. This is especially true on a PIC
> > since there are only 2 instructions capable of directly modifying the
> > program counter, CALL and GOTO. And there might also be instructions
> > which add/move/subtract(i've never seen this) to the PCL register.
> > This should be no trouble detecting.

Olin responded:

> I think we're going in circles here.  A few posts ago I should, as an
> example, a MOVLW instruction that might or might not need to be adjusted
> depending on the program intent.  The problem is that there is no way to
> know that intent by just looking at the final instructions.  It's not just
> instructions that modify the program counter that matter.  Any reference
to
> a program memory address needs to be adjusted, and there is no way to find
> all the instructions that do this.
>
> I've been trying to say basically the same thing for several posts in a
row.
> Maybe I'm not explaining this well, but either way I'm getting tired of
it.
> Perhaps others can jump in here, I'm done responding to this issue.
Believe
> what you like.  Go ahead and try it.

I add:

Olin is 100% right. Object code is not the place to start doing these
optimizations. In general, it is IMPOSSIBLE to determine the intent of a
specific instruction like his MOVLW's.

As he said -- if you think you can do it go ahead and try. But I will be
_highly_ surprised if you succeed.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\07\07@010807 by jeethur

flavicon
face
Ok Olin,

We'll get out of the Circle at once. The whole point in a HEX file
optimizer is that hard core assembly coders won't just need it.
Well written assembly code is always better than HLL generated code.
When anyone codes in assembler, he is supposed to know what he is doing.

But unfortunately, compilers are at the moment not as smart as Humans.
And this is especially true for compilers on PICs. PC compilers are
constantly evolving and new technology and AI is being put into compilers.
PC compilers are big business. If there is a good compiler for Win32, you
might expect millions of copies to be sold(If its commercial!).
PIC compilers OTOH have a smaller market and Thus, there aint a lot of
Competition the PIC compiler segment. So, there ain't a lot of expectation
from PIC compilers. And likewise, the generated code is very very poor in
quality compared to assembler code.

So, the primary target for Optimization is Compiler generated code.Just
check
the code generated by JAL if you don't believe me. I don't know about other
compilers. But JAL0435 just inspired me to think of a good soultion to this
problem. It simply generated a hell lot of redundant PAGE selections. This
I believe could be very easy to remove. And compilers unilke the human
brain,
generate exactly the same code for a specific input. I.e compilers don't
have
mood swings, bright ideas and other Advantages/Disadvantages which we humans
get quite often.

Right now, I'm learning Standard Template Library and some advance features
of
C++. Once I'm done with that, I'll be writing the optimizer in C++. Knowing
STL
would make this task a lot easier.

I'm quite sure that a compiler will not write ultra smart code which humans
can write. And one of the biggest advantage that PIC poses for an optimizer
is that there won't be any self modifying code. On x86s, self modifying code
is nearly impossible to optimize. Although it is theoritically possible to
write
such code on PIC16f87x devices through flash writes, I'm sure no one is
gonna do
it(Its way too inefficient).

I hope this gets us out of the infinite recursion.

Jeethu Rao

> {Original Message removed}

2001\07\07@093504 by Olin Lathrop

face picon face
> ... self modifying code ...
> Although it is theoritically possible to write
> such code on PIC16f87x devices through flash writes,
> I'm sure no one is gonna do it (Its way too inefficient).

Ha, never say never!

My code uploader for the 16F parts modifies one of its own instructions.
The uploader runs for a short time after a reset to allow the host a chance
to upload new code before the main code is run.  It then checksums the main
code and compares the result to the expected value.  The main code is only
run if it checksums correctly, otherwise the uploader restarts itself in an
infinite loop until new code is uploaded.  This is to protect against data
errors, power loss, etc, during an upload.

However, the upload code as written in the source code, and therefore as
programmed into a new chip, contains a GOTO to skip the checksumming of the
main firmware and always run it.  This speeds things up when debugging,
especially with the ICE which does direct flash reads/write *VERY* slowly.
The GOTO is overwritten with a NOP as soon as an upload request is received,
which causes the main code to be checksummed forever after.  This method
seemed to be simpler and smaller than writing a flag someplace then
explicitly checking it at run time.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, spam_OUTolinSTOPspamspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\07\10@162917 by uter van ooijen & floortje hanneman

picon face
> I was thinking of writing a compiler for PIC uCs
> so I was curious if you guys think another programming language would
> be a good idea..

Note that that's two statements: I want to create a new language AND I want
two write a compiler!

I do not want to discourage you too much, but try to get an idea of what you
are getting yourself into. My compiler (Jal) is now about 14k lines of C
(total lines, incl. blanks and comments), but it is still quite primitive
compared to for instance a full C compiler, does not even come near to
targeting all PICs, and I am still not satisfied with the optimizations. But
it is fun!

Maybe you should consider contributing to the SDCC project?

But if you really want to jump into this we might have some nice talks about
language architecture, compiler writing, the horrors of efficient PIC code
generation, avoiding stack use, etc.

Wouter

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamspammitvma.mit.edu


2001\07\10@162923 by uter van ooijen & floortje hanneman

picon face
> I did a LOT of development in Pascal before moving on to C/C++ and I have
to
> say that Pascal's tighter type checking made a lot of sense. It is only
with
> the newer flavors of C++ that we are approaching the protection provided
by
> Pascal.
> OTOH, I found myself regularly working around the restrictions imposed by
> Pascal, but that was a good thing ( (c) Martha Stewart ) because it made
> explicit the places I was doing something 'funny'.

Definitely me too. Imagine how the world would look now if Stroustroup would
have woked at Borland...
Wouter

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestspamspamRemoveMEmitvma.mit.edu


2001\07\10@165103 by Eric James

picon face
wouter van ooijen wrote

>I do not want to discourage you too much, but try to get an idea of what you
>are getting yourself into. My compiler (Jal) is now about 14k lines of C
>(total lines, incl. blanks and comments), but it is still quite primitive
>compared to for instance a full C compiler, does not even come near to
>targeting all PICs, and I am still not satisfied with the optimizations. But
>it is fun!

I agree, writing a reliable compiler is more work than I originally thought,
(Not to mention the manual).  My compiler (basic18) is over 22k lines of code
and only targets the 18Xxxx series.  It has taken about 1 year to write.  I
hope the dsPIC version goes a bit faster!  Even though it has been a lot of
work, it has been fun.

Eric


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamspamspam_OUTmitvma.mit.edu


2001\07\10@181841 by Patrik Husfloen

picon face
I have since then thought about it and I'm trying to do something new, not just another language
I mean there's Jal, C, Basic, etc..why does code have to be written in text page up and page down..
so I have some really weird ideas on how to continue this, project. However I just got a job offer and I already have several things on the back-burner that needs some more attention so it will have to wait for now.

Also, if I was to write a conventional programming language I would probably ANTLR.
Which would remove a lot of the work including parsing the lanugage.

Patrik


{Original Message removed}

2001\07\10@182326 by Bob Ammerman

picon face
> Definitely me too. Imagine how the world would look now if Stroustroup
would
> have woked at Borland...
> Wouter

Yeah, but the guy that did work for Borland is the creator of C# ! ! !

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestRemoveMEspammitvma.mit.edu


2001\07\17@012437 by jeethur

flavicon
face
Sorry Olin,
I could'nt download mail for a week.And hence I'm replying this message
late.
The Checksum Idea is great. I was how to detect and possibly fix errors
caused
by power failures.

But, how long does it take to checksum a long block of code (say 6K words) ?

If you are curious, the application is a UPS system which is flash
upgradable
through RS232 uplink to the PC its powering.
But when the code is being updated, the PIC will just have to sit like a
dumb moron
forgetting all its complex functions and it won't be able to switch to
battery power
if the power is to fail.

I could possibly do something like write all the code in a particular page
into an
unused page and then copy the code from there to page 0 and 1(This is
because I know
that my code won't exceed 4K words).

As for the Assembly optimizer, I don't have time for writing it now. Maybe
it'll have
to wait some 6 months. But I am serious about it and am convinced that it
will work for
JAL generated code. Just check the assembly output of JAL0435 with 16f877 as
the target processor
and i'll bet you'll believe me. I have not used SX chips but I think JAL has
the same weakness
on SXs. It simply generates a hell lot of redundant page selection code.
Merely removing these
redundant page selections can reduce code size by 30%. Add to it multiple
chained gotos (I hope you
get it) which JAL sometimes generates. This may be optimized and a further 5
to 10% code size may be
reduced. I've already worked out ways to adjust other calls and gotos to
compensate adding/removing
of code by the optimizer.

Anyway,
Thnx for the cool idea on BootLoaders

Jeethu Rao

> {Original Message removed}

2001\07\17@083410 by Olin Lathrop

face picon face
> But, how long does it take to checksum a long block of code (say 6K words)
?

It only takes a few instructions to read a program memory location, so add
some overhead for the loop and test conditions and figure it out yourself.
I haven't done this calculation myself, but my uploader checksums 8000
instructions instantaneously in human time.

> If you are curious, the application is a UPS system which is flash
> upgradable
> through RS232 uplink to the PC its powering.
> But when the code is being updated, the PIC will just have to sit like a
> dumb moron
> forgetting all its complex functions and it won't be able to switch to
> battery power
> if the power is to fail.

Is that really such a big deal?  Uploading new code only takes a minute or
two, is a rare occurrance, and is only done when the user explicitly
requests it, right?  If so, a human is right there and can manually deal
with a power failure at that time.  Of course the PIC code will have to
protect itself from a partially uploaded program.

> I could possibly do something like write all the code in a particular page
> into an
> unused page and then copy the code from there to page 0 and 1(This is
> because I know
> that my code won't exceed 4K words).

No matter what you do, there will be some window of vulnerability.  This
method will make that window short but not eliminate it.  My units will be
field upgradable by end customers, so they have to be fail safe.  They can
still be messed up, but that would require a data error or power fail during
upload, AND hit the one in 16,000 chance of the checksum matching a random
number.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, EraseMEolinSTOPspamspamRemoveMEembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...