I am one of the poor basterds that writes in C instead
of assembler. Just out of convenience.
At the moment i am struggling with the amount of code
space in my 16F84 so i am trying to find ways to
reduce it.
I found out that i can save 19 program words when i
use a switch instead of multiple IF's.
The switch has 7 cases.
and yes, when all fails i have to manually improve the
assembler code.
grtz,
Simon
____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
> Gents,
>
>
> I promissed i would do this.
>
> I am one of the poor basterds that writes in C instead
> of assembler. Just out of convenience.
>
> At the moment i am struggling with the amount of code
> space in my 16F84 so i am trying to find ways to
> reduce it.
>
> I found out that i can save 19 program words when i
> use a switch instead of multiple IF's.
> The switch has 7 cases.
>
> and yes, when all fails i have to manually improve the
> assembler code.
>
> grtz,
>
>
> Simon
>
>
> ____________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> or your free @yahoo.ie address at http://mail.yahoo.ie
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body
> Gents,
>
>
> I promissed i would do this.
>
> I am one of the poor basterds that writes in C instead
> of assembler. Just out of convenience.
>
> At the moment i am struggling with the amount of code
> space in my 16F84 so i am trying to find ways to
> reduce it.
>
> I found out that i can save 19 program words when i
> use a switch instead of multiple IF's.
> The switch has 7 cases.
>
> and yes, when all fails i have to manually improve the
> assembler code.
>
> grtz,
>
>
> Simon
>
>
> ____________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> or your free @yahoo.ie address at http://mail.yahoo.ie
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
> These days I only use C too (HI-TECH), a trick I've used when running short of
> program memory is to preset the result of a test, for example;
>
> Fred = 10;
> if(RB0) Fred = 20;
>
> uses 3 program words less than,
>
> if(RB0) Fred = 20;
> else Fred = 10;
>
> Beware of any interrupt routine which uses Fred though!
What code do these two snippets generate? In assembly, I'd write:
> Hey, would somebody with HI-TECH C try this and see how efficient it is:
> Fred = RB0 ? 20 : 10;
> In fact, a good compiler should be able to generate these sequences from
the
> original C:
> if (RB0)
> Fred = 20;
> else
> Fred =10;
I use CCS, not HI-TECH, but here's the results if anyone is interested.
Not
too bad, in my opinion. It helps with the CCS compiler to declare RB0 as a
"short" - what CCS calls a 1 bit variable. Another note: if Fred is
declared
at the end of a long list of variables, it could end up in another bank.
Then
all of these results are longer because of the bank switching.
Well, CCS certainly did a better job than HiTech on this.
What none of these compilers seem to be able to do is recognize when a
conditional operation can be performed in a single instruction, and thus
allow the 'skip' operation to directly perform the conditional operation.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
I'm just glad I'm using CCS instead of some other compiler <grin>... I may
be able to write slightly smaller code in ASM, but at least in C i
actually get things finished, unlike when I write asm code. Guess we're
just wired differently, Bob! (and you should be thankful!)
At 08:37 PM 3/1/01 -0600, you wrote:
>On Thu, 1 Mar 2001, Bob Ammerman wrote:
>
>> Now I know why I do my PIC development in ASM!
>
>I'm just glad I'm using CCS instead of some other compiler <grin>... I may
>be able to write slightly smaller code in ASM, but at least in C i
>actually get things finished, unlike when I write asm code. Guess we're
>just wired differently, Bob! (and you should be thankful!)
I wish they would get someone like Bob to review the code coming out
of the compilers and suggest improvements and optimizations.
While, for some applications these days I can justify tossing half the
clock cycles and ROM out the window, it sure would be nice to get closer
to what a skilled assembly programmer can do. The more familiar you are
with a processor, the more stupid the emitted code tends to look, even
on expensive professional compilers.
Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..." "The Journey is the reward" RemoveMEspeffEraseMEEraseMEinterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
My concern isn't so much the clock cycles involved. It's mostly the ROM
consumption that gets my goat.
I have looked at output of several different C compilers for the PIC, and I
have yet to see one of them that takes advantage of skips when a conditional
operation can be performed in one instruction. This is such a basic on the
PIC that it is really surprising they haven't figured it out.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
> While, for some applications these days I can justify tossing half the
> clock cycles and ROM out the window, it sure would be nice to get closer
> to what a skilled assembly programmer can do. The more familiar you are
> with a processor, the more stupid the emitted code tends to look, even
> on expensive professional compilers.
I have a lot of experience in writing X86 asssembly language, and I am
actually quite impressed with the output of modern C/C++ compilers on that
platform.
They still do some stupid things, but they also do a lot of smart things
(especially in the 32 bit world, where the X86's addressing methods are both
more complicated and more usable).
It may be that compiler vendors for micros don't spend a lot of time on
processor specific optimizations. They know that really performance
constrained apps will write the juicy bits in assembler anyway.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
> I wish they would get someone like Bob to review the code coming out
> of the compilers and suggest improvements and optimizations.
I agree.
> While, for some applications these days I can justify tossing half the
> clock cycles and ROM out the window, it sure would be nice to get closer
> to what a skilled assembly programmer can do. The more familiar you are
> with a processor, the more stupid the emitted code tends to look, even
> on expensive professional compilers.
Half the clock cycles and ROM? Only if the compiler TRULY sucks. I
always go through the generated assembler code when I'm finished, looking
for glaring problems. They're few and far between, really. I can usually
tweak it a little bit, but I seldom actually *need* to, from a speed or
space standpoint. If I'm that close to the edge on performance or code
space, I start to think carefully about the processor selection -- what
happens when the next feature gets added, or the next bug needs a few more
lines of code to fix?
I did see one C compiler (which shall remain nameless) that generated a
ton of really, truly bad code, but so far I've been pretty impressed with
CCS. As for asm-vs-C, I have always stuck to assembly up until recently,
first on the 8080, 8085, Z80, then 8048/8051, then the PIC. I only
decided to learn C when I had a project that was rapidly turning really
ugly in ASM, but is pretty simple and easy to maintain in C. For me, it's
well worth the very minor trade-offs.
Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
-- Isaac Asimov
>Half the clock cycles and ROM? Only if the compiler TRULY sucks. I
>always go through the generated assembler code when I'm finished, looking
>for glaring problems. They're few and far between, really. I can usually
>tweak it a little bit, but I seldom actually *need* to, from a speed or
>space standpoint. If I'm that close to the edge on performance or code
>space, I start to think carefully about the processor selection -- what
>happens when the next feature gets added, or the next bug needs a few more
>lines of code to fix?
I've found that the difference is much closer to 2:1 than the claims of
2% or whatever that the compiler suppliers make. OTOH, I routinely find
that the compiler makes more efficient use of RAM than I do because it
keeps better track of when it can reuse storage allocated to automatic
variables.
It depends a bit on whether you get into the "C" way of doing things and
make extensive use of library functions or whether you use it as kind of
a high level assembler.
I just finished a small project using an 8051 derivative. I *know*
I could have fit it into 1K if I'd used assembler. But it filled
something like 2.5-3K using C51 (partly because I used sprintf()).
It probably ran less than half the speed (but fast enough)
BFD, the memory size is 4K, and that's the chip I was going to use
regardless, so it cost nothing and probably saved me 2-3 days. All
the ISR's, everything, were written in C, not a byte of assembler.
Anyway, if I look at a PIC16F876-20, in (say, 100 quantity at Digikey),
it is USD5.15, if I could pack it all into a PIC16F873-04, it would be
USD4.45, a whopping 70 cent (15%) saving. If I was all that concerned about
a few quarters, I'd not be using Microchip parts anyway, most likely.
Similarly, with 8051's, the cost of going to a 32K ROM memory is often
not much over a 16K, and as you say, it's also a good thing to have
room for bugs and features to be added and subtracted.
Of course that's assuming there's a processor available that is bigger
than would otherwise be required.
The trade off is that you *may* be able to get the product out faster,
(which can be a lot more important than the development cost), the
code *may* cost less to develop a and the code *may* be more
reusable and maintainable. The latter is underrated IMHO.
>I did see one C compiler (which shall remain nameless) that generated a
>ton of really, truly bad code, but so far I've been pretty impressed with
>CCS. As for asm-vs-C, I have always stuck to assembly up until recently,
>first on the 8080, 8085, Z80, then 8048/8051, then the PIC. I only
>decided to learn C when I had a project that was rapidly turning really
>ugly in ASM, but is pretty simple and easy to maintain in C. For me, it's
>well worth the very minor trade-offs.
>
>Dale
>---
>The most exciting phrase to hear in science, the one that heralds new
>discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
> -- Isaac Asimov
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email listservSTOPspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
>
>
>
>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..." "The Journey is the reward" spamBeGonespeffSTOPspamEraseMEinterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> > > Hey, would somebody with HI-TECH C try this and see how efficient it is:
>> >
>> > Fred = RB0 ? 20 : 10;
>> >
>> > The compiler should be able to generate:
>> >
>> > > movlw 10
>> > > btfsc RBO
>> > > movlw 20
> > > > movwf Fred
> > >
etc.
I came across something similar where PIC C was movwf'ing to the same
var over and over again, when it could have simply movlw'd and then
did a single movwf at the end. I passed it on to Clyde, and they're
looking at incorporating it into a future set of optimizations.
The C source looked like this:
if ( byte & 0x80 ) var = 8;
if ( byte & 0x40 ) var = 7;
...
if ( byte & 0x01 ) var = 1;
It's a very crude find-the-most-significant-set-digit routine ...
This is the only case (so far) that I've found a really obvious
potential for relatively simple PIC C optimization.
> I have looked at output of several different C compilers for the PIC, and I
> have yet to see one of them that takes advantage of skips when a conditional
> operation can be performed in one instruction. This is such a basic on the
> PIC that it is really surprising they haven't figured it out.
>
Agreed. Wait 'til I get through with the SDCC port to the pic:
> These days I only use C too (HI-TECH), a trick I've used when running short of
> program memory is to preset the result of a test, for example;
>
> Fred = 10;
> if(RB0) Fred = 20;
>
> uses 3 program words less than,
>
> if(RB0) Fred = 10;
> else Fred = 20;
>
> Beware of any interrupt routine which uses Fred though!
>
> Regards,
>
> Nigel
>
>
> On Thursday, March 01, 2001 7:35 AM, Simon-Thijs de Feber
> [SMTP:.....stdf23173spam_OUTYAHOO.CO.UK] wrote:
> > Gents,
> >
> >
> > I promissed i would do this.
> >
> > I am one of the poor basterds that writes in C instead
> > of assembler. Just out of convenience.
> >
> > At the moment i am struggling with the amount of code
> > space in my 16F84 so i am trying to find ways to
> > reduce it.
> >
> > I found out that i can save 19 program words when i
> > use a switch instead of multiple IF's.
> > The switch has 7 cases.
> >
> > and yes, when all fails i have to manually improve the
> > assembler code.
> >
> > grtz,
> >
> >
> > Simon
> >
> >
> > ____________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> > or your free @yahoo.ie address at http://mail.yahoo.ie
> >
> > --
> > http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> > email TakeThisOuTlistserv.....TakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email TakeThisOuTlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body
>
>
>
>
Bob Ammerman wrote:
>
> Now I know why I do my PIC development in ASM!
>
> Bob Ammerman
> RAm Systems
> (contract development of high performance, high function, low-level
> software)
The more months I use PIC asm the more I find I am
using 5 asm instructions and 25 lines of comments,
such is the power of a few well placed asm
instructions. And i'm not a beginner to programming
either.:o)
Can't see why anyone would use non-asm in a PIC?
Maybe for really large apps, but then why use a PIC?
Other controllers are much better for larger apps.
Maybe my opinion will change but I still think PIC
C programming is a poor solution.
-Roman
>Bob Ammerman wrote:
> >
> > Now I know why I do my PIC development in ASM!
> >
> > Bob Ammerman
> > RAm Systems
> > (contract development of high performance, high function, low-level
> > software)
>
>
>The more months I use PIC asm the more I find I am
>using 5 asm instructions and 25 lines of comments,
>such is the power of a few well placed asm
>instructions. And i'm not a beginner to programming
>either.:o)
>
>Can't see why anyone would use non-asm in a PIC?
>Maybe for really large apps, but then why use a PIC?
>Other controllers are much better for larger apps.
>Maybe my opinion will change but I still think PIC
>C programming is a poor solution.
>-Roman
>
>--
>http://www.piclist.com hint: To leave the PICList
>spamBeGonepiclist-unsubscribe-request@spam@spam_OUTmitvma.mit.edu
The information contained in this electronic message is private and may
contain privileged, confidential or inside information. Any distribution,
copying or forwarding or use of this communication by anyone other than the
intended recipient(s) is strictly prohibited and may be unlawful.
>Bob Ammerman wrote:
> >
> > Now I know why I do my PIC development in ASM!
> >
> > Bob Ammerman
> > RAm Systems
> > (contract development of high performance, high function, low-level
> > software)
>
>
>The more months I use PIC asm the more I find I am
>using 5 asm instructions and 25 lines of comments,
>such is the power of a few well placed asm
>instructions. And i'm not a beginner to programming
>either.:o)
>
>Can't see why anyone would use non-asm in a PIC?
>Maybe for really large apps, but then why use a PIC?
>Other controllers are much better for larger apps.
>Maybe my opinion will change but I still think PIC
>C programming is a poor solution.
>-Roman
>
>--
>http://www.piclist.com hint: To leave the PICList
>EraseMEpiclist-unsubscribe-request@spam@mitvma.mit.edu
The information contained in this electronic message is private and may
contain privileged, confidential or inside information. Any distribution,
copying or forwarding or use of this communication by anyone other than the
intended recipient(s) is strictly prohibited and may be unlawful.
part 1 2709 bytes content-type:text/plain; charset=us-ascii
>Maybe my opinion will change but I still think PIC
>C programming is a poor solution.
@ the risk of the C vs Assembler debate.......
1. Portability (ooh, that old chestnut)
2. Quick (first) to market (Yes, we all know that if you have a massive
library of assembler "functionality" because you have been doing it for
5x10^6 years that can be bolted together, that is as fast as developing in
C. However, for people new to the device...................)
3. Universally understood - not everyone understands PIC assembler,
especially where people are new to a project or they have to 'pic'k
something up when the "PIC wizard" has left abruptly.
Don't get me wrong, assembler should be used over C where necessary....
>Bob Ammerman wrote:
> >
> > Now I know why I do my PIC development in ASM!
> >
> > Bob Ammerman
> > RAm Systems
> > (contract development of high performance, high function, low-level
> > software)
>
>
>The more months I use PIC asm the more I find I am
>using 5 asm instructions and 25 lines of comments,
>such is the power of a few well placed asm
>instructions. And i'm not a beginner to programming
>either.:o)
>
>Can't see why anyone would use non-asm in a PIC?
>Maybe for really large apps, but then why use a PIC?
>Other controllers are much better for larger apps.
>Maybe my opinion will change but I still think PIC
>C programming is a poor solution.
>-Roman
>
>--
>http://www.piclist.com hint: To leave the PICList
>piclist-unsubscribe-requestEraseME@spam@mitvma.mit.edu
The information contained in this electronic message is private and may
contain privileged, confidential or inside information. Any distribution,
copying or forwarding or use of this communication by anyone other than the
intended recipient(s) is strictly prohibited and may be unlawful.
>
>Now I know why I do my PIC development in ASM!
>
>Bob Ammerman
>RAm Systems
>(contract development of high performance, high function, low-level
>software)
>The more months I use PIC asm the more I find I am
>using 5 asm instructions and 25 lines of comments,
>such is the power of a few well placed asm
>instructions. And i'm not a beginner to programming
>either.:o)
>
>Can't see why anyone would use non-asm in a PIC?
>Maybe for really large apps, but then why use a PIC?
>Other controllers are much better for larger apps.
>Maybe my opinion will change but I still think PIC
>C programming is a poor solution.
>-Roman
Hi guys,
one question, how about
double x = sqrt(ln(cos(2*PI*(double)AD_result)???
in asm?
What I would say, the C compiler is in this case much faster and better,
just press the compile button.
Andrej
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>Praise the Lord... Amen :)
>
>At 09:02 PM 3/2/01 +1100, you wrote:
>>Bob Ammerman wrote:
>> >
>> > Now I know why I do my PIC development in ASM!
>> >
>> > Bob Ammerman
>> > RAm Systems
>> > (contract development of high performance, high function, low-level
>> > software)
>>
>>
>>The more months I use PIC asm the more I find I am
>>using 5 asm instructions and 25 lines of comments,
>>such is the power of a few well placed asm
>>instructions. And i'm not a beginner to programming
>>either.:o)
>>
>>Can't see why anyone would use non-asm in a PIC?
>>Maybe for really large apps, but then why use a PIC?
Because they're cheap, available and familiar.
>>Other controllers are much better for larger apps.
Not if the app will fit a smaller one - ok it maybe easier to do some
things on bigger chips if you have that luxury, but component cost and
power consumption are almost always major issues.
>>Maybe my opinion will change but I still think PIC
>>C programming is a poor solution.
Horses for courses. It all depends on the application. For low-level
bit-bashing C is terrible and ASM is usually much quicker to write,
but doing lots of maths or complicated flow-control is a royal pain in
asm. I use Asm unless there is a good reason to use C, and then often do
the twiddly bits in ASM. Fortunately most MCU C compilers allow bits
of ASM to be added very easily without having to mess with linkers
etc. Now if only someone would do it the other way round and write an
assembler that allowed little bits of C to be included....!
> Hi guys,
>
> one question, how about
>
> double x = sqrt(ln(cos(2*PI*(double)AD_result)???
>
> in asm?
>
> What I would say, the C compiler is in this case much faster and better,
> just press the compile button.
>
> Andrej
You are correct.
Horses for courses.
I'm just glad my courses tend to fit the ASM horse!
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
>2. Quick (first) to market (Yes, we all know that if you have a massive
>library of assembler "functionality" because you have been doing it for
>5x10^6 years that can be bolted together, that is as fast as developing
Until you find "module A" uses a different data format to "module B" which is
different again to "module C" which is different again ...... because they all
come from different projects over the years which all had different programmers
who never new each other because of staff turnover etc etc etc.
>3. Universally understood - not everyone understands PIC assembler,
>especially where people are new to a project or they have to 'pic'k
>something up when the "PIC wizard" has left abruptly.
The high level language is always generally easier to see what is going on with
less effort than trying to get to the same level of understanding with
assembler. Especially when coming back to it a year or two later when the
customer wants some improvements or subtle changes to bring out a new variant or
model of the product.
>one question, how about
>
>double x = sqrt(ln(cos(2*PI*(double)AD_result)???
>
>in asm?
>
>What I would say, the C compiler is in this case much faster and better,
>just press the compile button.
But would it even FIT in a PIC?? Try fitting a code snippet like that into
a 12C508 or something similar. Sometimes, some of the more complex math
routines can be rewritten/modified for the specific math calculation that
needs to be done or specific problems with the application (or processor)
that need to be addressed. For example, there are many 16x16bit multipliers
out there, some of which use less RAM/more program memory, and vice versa.
Depending on how much space/RAM you have to work with, one might be
preferable over the other.
Also, depending on the accuracy you need, you can make concessions with the
cosine or PI approximations in your example. Granted, typing out what you
want and pressing "compile" is much easier and faster than the hours and
hours (+ skill) required to do this in assembly. Personally, I don't think
I'd want to do complex math too often in asm.
On the other hand, try doing precision PWM cycling, delay loops, or freqency
timing in C. You'll be begging for assembly in those cases.
--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
> I have a lot of experience in writing X86 asssembly language, and I am
> actually quite impressed with the output of modern C/C++ compilers on that
> platform.
I think this is mostly a matter of volume. Look at the total number of
copies sold of Microsoft Visual C++ versus all the PIC compilers put
together. MS can afford a large team of people that agonize over optimizing
every little instance.
I have also done lots of assembly language programming on both PICs and the
x86, especially in 32 bit mode. The x86 instruction set is the richest I've
ever programmed, and therefore requires more knowledge and skill for a human
to optimize. A good set of rules in the compiler optimizer can compare well
against a human who might miss a little thing in any particular instance.
I've been generally impressed with what the MSVC compiler produces at high
optimization level. The main code is usually pretty good, and I've
occasionally learned a few tricks from it. My main issue is with the
somewhat heavyweight subroutine linkage the compiler wants to use.
> I've found that the difference is much closer to 2:1 than the claims of
> 2% or whatever that the compiler suppliers make. OTOH, I routinely find
> that the compiler makes more efficient use of RAM than I do because it
> keeps better track of when it can reuse storage allocated to automatic
> variables.
I use a different scheme for allocating RAM than what I think most others
do. The Microchip (and I think the compilers) strategy is to statically
allocate local variables, but overlay the regions of routines that are never
called from each other. This seems very dangerous to me unless you have an
automated tool that can determine the call tree for certain. This also
means that all source code needs to be viewed by the tool at once, making
separate modules cumbersome. A good compiler should be able to do this as
long as you don't call thru pointers, but having a human do this is asking
for trouble.
Many of the 16C parts have the last 16 bytes of each bank mapped to the same
storage. These 16 bytes can therefore be accessed without regard to the
current register bank setting. I reserve a chunk of these bytes (13
usually) as general "registers" REG0 thru REG12. Routines use these as
general scratch and temporary local variables, and as subroutine input and
output parameters. Each routine is responsible for preserving these
registers from the caller's point of view, except the ones explicitly
documented as returned parameters. I use a software stack to facilitate
this.
The end result is that subroutines almost never need statically allocated
temporary storage. 13 bytes is usually far more than enough. The only
statically allocated values are persistant state. The number of bank
switching instructions is also reduced, since the most frequently accessed
variables don't require any particular bank setting. The flip side is that
you have to allocate some memory for the stack, and spend cycles
saving/restoring registers on subroutine entry/exit. However, I've used
this scheme on many projects and find it very effective.
I've created a lot of macros that facilitate this scheme. They are
available at http://www.embedinc.com/pic in STD.INS.ASPIC. See the
definition of the general registers REGn and associated support. For
subroutine linkage, see the GLBSUB, LEAVEREST and related macros.
>2. Quick (first) to market (Yes, we all know that if you have a massive
>library of assembler "functionality" because you have been doing it for
>5x10^6 years that can be bolted together, that is as fast as developing
Until you find "module A" uses a different data format to "module B" which
is
different again to "module C" which is different again ...... because they
all
come from different projects over the years which all had different
programmers
who never new each other because of staff turnover etc etc etc.
## Is this not what documentation and version control is for? ;-) Being
serious, yes...that is always going to be a problem. If the application
layer is designed to be flexible, however, you can get away with plug in
functionality at the lower levels to overcome this.
>3. Universally understood - not everyone understands PIC assembler,
>especially where people are new to a project or they have to 'pic'k
>something up when the "PIC wizard" has left abruptly.
The high level language is always generally easier to see what is going on
with
less effort than trying to get to the same level of understanding with
assembler. Especially when coming back to it a year or two later when the
customer wants some improvements or subtle changes to bring out a new
variant or
model of the product.
## Hmmm. That sounds familiar. Even at that, though, I find that it is hard
to track a problem in C when some abstract problem has been papered over.
This is typically done when a fudge is required and programmers seem very
reluctant to document flaws in their design; instead they produce some
convoluted bodge that is indecipherable 2 months down the line.
I find the biggest problem is seeing the "intention" (i.e. whole picture)
of other people's code; in my experience, people tend to document things
like:
// Set I/O
Initialise_IO();
// Obtain the power up time
PowerUpTime = Read_RTC();
Why bother with the comments? It is blatantly obvious what is going on!
Much more useful would be to educate people to write down the intention of
what is going on in some obscure section of code (and no, that example was
not obscure)......no matter if in C or assembler or.....
> >3. Universally understood - not everyone understands PIC assembler,
> >especially where people are new to a project or they have to 'pic'k
> >something up when the "PIC wizard" has left abruptly.
>
> The high level language is always generally easier to see what is going on
with
> less effort than trying to get to the same level of understanding with
> assembler. Especially when coming back to it a year or two later when the
> customer wants some improvements or subtle changes to bring out a new
variant or
> model of the product.
Let's not wonder too far from the "design" issue; while understanding a
particular language better than another might help gleen an understanding of
the program in question, I contend that if you don't understand the "design"
or "architecture" of the system, it's less important which language gets
used. I always want to know what the architecture of a design is first,
before I start plowing through pages and pages of code listings; if I don't
have this basic understanding, I will spin my wheels just staring at code.
- I'm not a consultant - I work for a company and my boss wants
stuff written in 'C' so others down the road can more easily
see what is going on. I just use inline asm when necessary.
I have to admit that it tends to be easier to get the big
picture when looking at C, although I don't ever like trying
to figure someone else's code out. Olin style commenting is
the best bet in either case.
- I absolutely don't buy the portability argument for C. There
is too much interaction with i/o ports, timers, interrupts
and other peripherals & hardware for code to be portable to
anything other than another pic - and then C doesn't buy you
anything anyway.
- which one is quicker to write depends entirely on the nature
of what needs to be written, as we've seen with the complex
math statement. I think I saw a statement from Andrew Warren
once that he was the fastest asm programmer he knew, yet
there were still some things he could do faster in C.
Does anybody have IAR C for PIC? If so, does it work as well as the one I
have for Atmel?
I realize that this compiler is far too ferociously expensive for any
experimenter/hobbyist (several K$), but I'm mostly interested in a
professional tool. I'm doing everything else in assembly, but I can see a
huge improvement in my productivity using C, so it just might be possible to
get my boss to spring for one if it works well enough.
It might also mean I could use the same code for both the Atmel processor
and PIC, so I could choose the processor for the project based on which
works better rather than which I already have code written for.
I have one for a project I'm doing with an Atmel 163, and it seems to do a
pretty good job, using the Atmel's equivalent to BTFSC.
THIS IS NOT PIC CODE, IT IS FOR ATMEL ATMEGA 163.
Makes the same 5 instructions either way, or 3 for the rewritten version,
just like I would have written in assembler.
>I use a different scheme for allocating RAM than what I think most others
>do. The Microchip (and I think the compilers) strategy is to statically
>allocate local variables, but overlay the regions of routines that are never
>called from each other. This seems very dangerous to me unless you have an
>automated tool that can determine the call tree for certain. This also
>means that all source code needs to be viewed by the tool at once, making
>separate modules cumbersome. A good compiler should be able to do this as
>long as you don't call thru pointers, but having a human do this is asking
>for trouble.
I'll just note here that Salvo compiled under HI-TECH calls tasks
through pointers and has absolutely no trouble with RAM vars, etc. In
fact it's quite efficient at overlaying var usage.
It handles services called from inside of ISRs, too (they're not
overlayed if also called from mainline code, of course!).
--
______________________________________
Andrew E. Kalman, Ph.D.
Or... (get ready, big drum roll, trying to keep from shouting)
Maybe it would be a good idea to open source a C compiler so that list
members could help build a HUGE central database of optimizations just like
this one or much more complex than this one so that we could all benefit
from C code that compiles to the tightest fastest code from the most
brilliant PIC programmers in the world (PICList members).
I have repeatedly offered to work with ANY open source compiler vendor to
make the routine library at piclist.com available in a format that could be
automatically incorporated into a compiler while at the same time remaining
centralized and expandable by all users.
And open source C compiler that can be easily changed to generate better ASM
code would be just as good, I think...
If you gave it some C code and then looked at the ASM it generated and
re-wrote it, why couldn't the compiler LEARN from your changes and apply
your ASM code the next time it compiled the C code that matched it.
>Does anybody have IAR C for PIC? If so, does it work as well as the one I
>have for Atmel?
>
>I realize that this compiler is far too ferociously expensive for any
>experimenter/hobbyist (several K$), but I'm mostly interested in a
>professional tool. I'm doing everything else in assembly, but I can see a
>huge improvement in my productivity using C, so it just might be possible to
>get my boss to spring for one if it works well enough.
We have both IAR and HI-TECH in-house. They both produce very good
code, and are similarly full-featured. The IAR Workbench has a more
"professional IDE" appearance, but frankly I prefer to work in my own
mixed environment of CodeWarrior / MPLAB / command-line execution of
HI-TECH PIC C.
Also, the IAR is dongle-ware, which many people detest.
--
______________________________________
Andrew E. Kalman, Ph.D.
If the result didn't fit into a PIC, you should be able to take the result,
look for optimizations (at piclist.com) and tell the compiler to use them
next time.
Properly defining the size of the parameters to a function also helps to
define the accuracy needed. Most C compilers will use EXACTLY the same code
to generate a SQRT no matter if the incoming value is a char or a long. The
routine library at piclist.com has SQRT routines ranging from 53
instructions and 19 cycles worst case for a char all the way up to 58 words
439 cycles worst for a 32bit long. I'll bet no C compiler even comes close
to that.
Why isn't there an easy way to teach a compiler to use the best code
available from a large, open, massmind optimized library?
At 08:36 AM 3/2/01 -0700, you wrote:
>Re:
>
>>I use a different scheme for allocating RAM than what I think most others
>>do. The Microchip (and I think the compilers) strategy is to statically
>>allocate local variables, but overlay the regions of routines that are never
I think he means "statically allocate _global_ variables"
>>called from each other. This seems very dangerous to me unless you have an
>>automated tool that can determine the call tree for certain. This also
>>means that all source code needs to be viewed by the tool at once, making
>>separate modules cumbersome. A good compiler should be able to do this as
>>long as you don't call thru pointers, but having a human do this is asking
>>for trouble.
>
>I'll just note here that Salvo compiled under HI-TECH calls tasks
>through pointers and has absolutely no trouble with RAM vars, etc. In
>fact it's quite efficient at overlaying var usage.
How does the compiler determine the call tree?
Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..." "The Journey is the reward" EraseMEspeffSTOPspamRemoveMEinterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >I'll just note here that Salvo compiled under HI-TECH calls tasks
>>through pointers and has absolutely no trouble with RAM vars, etc. In
>>fact it's quite efficient at overlaying var usage.
>
>How does the compiler determine the call tree?
How? I don't know ... but the map file generates a full "graphical"
call graph, including the indirect function calls via
call-by-pointer, functions in interrupots, etc ... - it's quite
interesting to look at.
If/When the compiler detects that the same function is in both a
mainline call graph and is also called from an interrupt, it issues
an error unless the function has been preceded by PIC C's
interrupt_level pragma. In that case, it knows to keep the auto
variables and parameters separate ...
--
A setting that removes the optimizations would make it easy to detect that
problem in the future. In fact, there should be settings for
A) no opts.
B) speed opts. only if the opt is faster
C) size opts. only if the opt is smaller
D) all opts. any.
Also, I would think that when the hand coded routine was "taught" to the
compiler, you could specify that it would apply to
A) any call of the function
B) any call of the function with that size / type parameter
C) any call of the function with that specific parameter name.
D) any call of the function in this specific project.
> And open source C compiler that can be easily changed to generate better ASM
> code would be just as good, I think...
>
> If you gave it some C code and then looked at the ASM it generated and
> re-wrote it, why couldn't the compiler LEARN from your changes and apply
> your ASM code the next time it compiled the C code that matched it.
Wow... a "create-your-own-compiler-bugs" feature! I could break ANYTHING
with this!
Seriously... I could fix a few things too, but I surely could not expect
the manufacturer of the compiler to ever support the product again, and I
would think any updates would be problematic. It'd be a nice wish-list
feature though.
Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
-- Isaac Asimov
> On Fri, 2 Mar 2001, James Newton wrote:
>
> > And open source C compiler that can be easily changed to generate better ASM
> > code would be just as good, I think...
> >
> > If you gave it some C code and then looked at the ASM it generated and
> > re-wrote it, why couldn't the compiler LEARN from your changes and apply
> > your ASM code the next time it compiled the C code that matched it.
>
> Wow... a "create-your-own-compiler-bugs" feature! I could break ANYTHING
> with this!
>
> Seriously... I could fix a few things too, but I surely could not expect
> the manufacturer of the compiler to ever support the product again, and I
> would think any updates would be problematic. It'd be a nice wish-list
> feature though.
>
One of the difficulties with this approach is the way compilers work in
practice. I can't speak for Hi-tech or Byte Craft or any compiler for which I
don't have the source, but the ones I have seen break the C source into tiny
manageable chunks. By the time the assembly code is generated, the compiler has
all but forgotten what the original source looked like.
A better approach imo, is to convey as much information from the original source
to the final assembly output. This is what I'm trying to do with SDCC at the
moment. For example, the C-compiler knows where functions begin and end, where
the loops are etc. It also knows how the variables are overlayed, what thier
scope is, and so on. It should be possible to use this information to further
optimize the code.
One of the things I'm attempting with SDCC is to create an "intelligent" peep
hole optimizer. SDCC currently has a peep hole optimizer, but can't cope with
program flow that is beyond the scope of a peep hole rule. The example I like to
give is this:
movwf some_reg
movf some_reg,W
This sequence appears quite often in SDCC. It seems like you can just delete the
second instruction since W already contains the same value as
'some_reg'. However, if this sequence is followed by:
skpz
Then the movf can't be removed. So some mechanism is required to examine the
code that follows and see if the Z bit is needed as an 'input'. The PIC port of
SDCC now can handle this simple case.
The way to 'teach' a compiler is by providing these peep hole rules. The example
given the other day:
..the thing that bugs me is not being able to add these optimization rules
myself in an easy way. I don't care if they get added before, during or
after the compiler does it's thing, I just want to be able to add them and
do so in a semi automatic way.
In Scott's example below, you ought to be able to select a range of output
asm, have a utility subroutine in the IDE replace the labels and operands
with the %# notation and produce a template for the rule. Then you can code
the optimized version and hit a button to record it for future use. It
shouldn't just be the compiler developers who are doing this stuff. We can
all help.
It is just as important that each optimization be reported back to the
compiler developer or distribution point automatically. Maybe it needs to be
reviewed or maybe just the authors name (and reputation) attached to it.
Other users should be able to say "if Scott Dattalo or Nik or Dmitry or
etc... posted an optimization, then I want to use it; but if James Newton
posted it, I want to look at it first." <GRIN>
Seems like you could do that before, during and after the compilation. My
SQRT example previously posted should be valid as a part of the compilers
action. I still don't see why not.
And before compilation it would be nice to have a "grammar checker" of C
code that is known to be stupidly written. How many times has someone posted
"...if you write it this way it compiles to something that works better..."
or just seen a newbie write a book in C that can be expressed cleanly in one
line.
These improvements are being lost because we have no automated way of
applying them
And again, it doesn't have to be an always do it, totally automatic thing.
You could just generate a warnings listing that says "boy, it seems like
this would be better" so that you can go back and look at it when you have
time and need code space or cycles.
mitvma.mit.edu with SET PICList DIGEST in the body
