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.
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.
> 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.
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
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.
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. ;-)
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}
>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.
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,
> 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 !
>>
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.
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/
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].
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.
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
>
>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
>
> >
> >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...
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
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.
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.
>Jerry Merrill 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
> > >
> > >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...
>
>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 RemoveMElistservEraseMEEraseMEmitvma.mit.edu with SET PICList DIGEST in the body
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
> 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)
>
> 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...
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
>
> 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:
> >Jerry Merrill 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
> > > >
> > > >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...
> >
> >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 EraseMElistservEraseMEmitvma.mit.edu with SET PICList DIGEST in the body
>
> Jerry Merrill
>
> @spam@jerrym@spam@spam_OUTtech-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 spamBeGonelistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body
>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:
> >
> > 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:
> > >Jerry Merrill 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
> > > > >
> > > > >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...
> > >
> > >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 TakeThisOuTlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body
> >
> > Jerry Merrill
> >
> > .....jerrymRemoveMEtech-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 RemoveMElistservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email spamBeGonelistserv@spam@spam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
>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)
> > 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.
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.
> > > 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@olinspam_OUT.....embedinc.com,http://www.embedinc.com
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email spamBeGonelistservEraseMEmitvma.mit.edu with SET PICList DIGEST in the body
>
>
--
A train stops at a train station. A bus stops at a bus station.
On my desk I have a workstation...
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.
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.
> 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.
> 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.
> > 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.
> 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.
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...
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)
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.
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.
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.
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 ???].
> 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.
> 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}
> >>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: To leave the PICList
> spamBeGonepiclist-unsubscribe-request@spam@mitvma.mit.edu
>
>
> 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
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.
>
> Not only that, there can be significant issues with accessing declared
> language variables from assembler - especially if the variables are locally
> declared .... "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.
>
> I'd love to see how the authors
> prevented assembler statements from being a significant problem.
>
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.
> 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...
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.
> 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.
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.
>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
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
> 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
> > 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)
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 ?
> 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.
> > 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
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!
>> 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.
> > 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.
> > > 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.
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:
> On Tue, 3 Jul 2001, Olin Lathrop wrote:
>
> > > > 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.
>
> 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
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.
> > 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.
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.
>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)...
> 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.
> 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.
>
> 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.
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:
> 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.
> 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)...
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.
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.
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.
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.
> 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.
> > 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
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.
> ... 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.
> 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.
> 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
>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/
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.
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.
> 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.
silicontao.com>
