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

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Switch / If Statement revisited'
2001\03\01@023433 by Simon-Thijs=20de=20Feber?=

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


2001\03\01@040151 by NDuckworth

flavicon
face
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:.....stdf23173KILLspamspam@spam@YAHOO.CO.UK] wrote:
{Quote hidden}

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


2001\03\01@094818 by NDuckworth

flavicon
face
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!

Regards,

Nigel


On Thursday, March 01, 2001 7:35 AM, Simon-Thijs de Feber
[SMTP:EraseMEstdf23173spam_OUTspamTakeThisOuTYAHOO.CO.UK] wrote:
{Quote hidden}

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


2001\03\01@095821 by Scott Dattalo

face
flavicon
face
On Thu, 1 Mar 2001, Nigel Duckworth wrote:

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

 movlw  10
 btfsc  RBO
  movlw 20
 movwf  Fred

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


2001\03\01@102810 by Bob Ammerman

picon face
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

or:

movlw 20
btfss RB0
movlw 10
movwf Fred

In fact, a good compiler should be able to generate these sequences from the
original C:

if (RB0)
  Fred = 20;
else
  Fred =10;

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

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


2001\03\01@111250 by Sam Linder

flavicon
face
It's not pretty:

    1                                  processor       16F877
    2  0000                     indf   equ     0
    3  0000                     rtcc   equ     1
    4  0000                     pc     equ     2
    5  0000                     pcl    equ     2
    6  0000                     status equ     3
    7  0000                     fsr    equ     4
    8  0000                     porta  equ     5
    9  0000                     portb  equ     6
   10  0000                     portc  equ     7
   11  0000                     pclath equ     10
   12                                  global  _main
   13                                  signat  _main,88
   14                                  psect
text0,local,class=CODE,delta=2
   15                                  psect   text0
   16                                  file
"f:\ht-pic\testpow\testpow.c"
   17                                  line    29
   18
   19  07F0                     _main
   20                           ;f:\ht-pic\testpow\testpow.c: 30: unsigned
char
                                Fred;
   21
   22                           ;      _Fred assigned to ?a_main+0
   23  0000                     _main$Fred     set     ?a_main+0
   24                           ;f:\ht-pic\testpow\testpow.c: 32: Fred =
rb0 ? 2
                                0 : 10;
   25
   26                                  line    32
   27  07F0  1283                      bcf     status,5
   28  07F1  1303                      bcf     status,6
   29  07F2  1806                      btfsc   (030h/8),(030h)&7
   30  07F3  2FF9                      goto    u11
   31  07F4  2FF5                      goto    u10
   32
   33  07F5                     u10
   34  07F5  300A                      movlw   ((0Ah))
   35  07F6  2FFA                      goto    u27
   36  07F7                     u26
   37  07F7  3014                      movlw   ((014h))
   38  07F8  2FFA                      goto    u27
   39  07F9                     u11
   40  07F9  2FF7                      goto    u26
   41  07FA                     u27
   42  07FA  1283                      bcf     status,5
   43  07FB  1303                      bcf     status,6
   44  07FC  00A0                      movwf   (((?a_main+0)))
   45                           ;f:\ht-pic\testpow\testpow.c: 36: }
   46
   47                                  line    36
   48  07FD                     l1
   49                                  global  start
   50  07FD  120A  118A  2804          ljmp    start
   51                                  FNSIZE  _main,1,0
   52                                  global  ?a_main
   53                                  psect
text1,local,class=CODE,delta=2
   54                                  psect   text1

{Original Message removed}

2001\03\01@120858 by Mike Mansheim

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

void main(void)
{
    #byte PORTB = 0x06
    #bit RB0 = PORTB.0

    unsigned int Fred;

    // first technique
    Fred = RB0 ? 20 : 10;

    // second technique
    if (RB0)
       Fred = 20;
    else
       Fred =10;

    // space saver originally suggested
    Fred = 10;
    if (RB0) Fred = 20;
}

to save space, I've cleaned up the CCS .lst file output a bit for the
results:  Note:  the compiler assigned Fred to 0x21.

first technique (6 words):

     ....................  Fred = RB0 ? 20 : 10;
0007  BTFSS  06,0
0008  GOTO   00B
0009  MOVLW  14
000A  GOTO   00C
000B  MOVLW  0A
000C  MOVWF  21

second technique (7 words):

     ....................    if (RB0)
000D  BTFSS  06,0
000E  GOTO   012
     ....................       Fred = 20;
000F  MOVLW  14
0010  MOVWF  21
     ....................    else
0011  GOTO   014
     ....................       Fred =10;
0012  MOVLW  0A
0013  MOVWF  21


space saving suggestion (6 words):

     ....................    Fred = 10;
0014  MOVLW  0A
0015  MOVWF  21
     ....................    if (RB0) Fred = 20;
0016  BTFSS  06,0
0017  GOTO   01A
0018  MOVLW  14
0019  MOVWF  21

ideal result (4 words):
>   movlw  10
>   btfsc  RBO
>   movlw 20
>   movwf  Fred

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


2001\03\01@193934 by Bob Ammerman

picon face
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)



{Original Message removed}

2001\03\01@193940 by Bob Ammerman

picon face
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)

----- Original Message -----
From: Sam Linder <TakeThisOuTSamLEraseMEspamspam_OUTIN-INC.COM>
To: <RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU>
Sent: Thursday, March 01, 2001 11:05 AM
Subject: Re: [PIC]: Switch / If Statement revisited


{Quote hidden}

unsigned
{Quote hidden}

> {Original Message removed}

2001\03\01@213658 by Dale Botkin

flavicon
face
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!)

Dale

{Quote hidden}

> > {Original Message removed}

2001\03\01@215812 by Spehro Pefhany

picon face
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"
RemoveMEspeffEraseMEspamEraseMEinterlog.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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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


2001\03\01@221318 by Bob Ammerman
picon face
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)

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


2001\03\01@221802 by Bob Ammerman

picon face
> 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)

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


2001\03\01@224708 by Dale Botkin

flavicon
face
On Thu, 1 Mar 2001, Spehro Pefhany wrote:

> 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

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


2001\03\01@231924 by Bob Ammerman

picon face
FWIW:

I tested this in Wouter's JAL and got similar results ;-(

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

{Original Message removed}

2001\03\01@233531 by Spehro Pefhany

picon face
At 09:18 PM 3/1/01 -0600, you wrote:

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

Best regards,




{Quote hidden}

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spamBeGonespeffSTOPspamspamEraseMEinterlog.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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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


2001\03\01@234006 by Andrew E. Kalman

flavicon
face
Re:

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

--

 ______________________________________
  Andrew E. Kalman, Ph.D.   EraseMEaekspamEraseMEpumpkininc.com

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


2001\03\02@004524 by Scott Dattalo

face
flavicon
face
On Thu, 1 Mar 2001, Bob Ammerman wrote:

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

http://www.dattalo.com/gnupic/sdcc.html

Scott

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


2001\03\02@015012 by dr. Imre Bartfai

flavicon
face
Hi,

what about

Fred = 10;
if(RB0) Fred <<= 1;

Regards,
Imre


On Thu, 1 Mar 2001, Nigel Duckworth wrote:

{Quote hidden}

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


2001\03\02@040933 by Kevin Blain

flavicon
face
; 9 program words.....
; input file as the file to test
; output: counter as the bit position (1-8) or 9 if the file is empty

   movlw    .9
   movwf    counter
   tstf    file
   skpnz
   goto    file_is_clear
loop:
   decfsz    counter,f
   rlf    file,f
   skpc
   goto    loop

; counter now shows number of bit positions.....
; but goes to file_is_clear if the file holds zero.

{Original Message removed}

2001\03\02@050147 by Roman Black

flavicon
face
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
RemoveMEpiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu


2001\03\02@050804 by Dan Goddard

flavicon
face
Praise the Lord... Amen :)

At 09:02 PM 3/2/01 +1100, you wrote:
{Quote hidden}

-------------------------------------------
Danny Goddard
Design Engineer
ARMA Design
Tel:(858) 549-2531
Fax:(858) 549-2594
Email: TakeThisOuTdan_goddardspamspamarmanet.com
Web: http://www.armanet.com



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.

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


2001\03\02@051430 by Adlam Frank

flavicon
face
Code portability?  Surely not only work on PIC micros?

-----Original Message-----
From: Dan Goddard [RemoveMEdan_goddardEraseMEspamspam_OUTARMANET.COM]
Sent: Friday, March 02, 2001 12:03 PM
To: @spam@PICLISTRemoveMEspamEraseMEMITVMA.MIT.EDU
Subject: Re: [PIC]: Switch / If Statement revisited


Praise the Lord... Amen :)

At 09:02 PM 3/2/01 +1100, you wrote:
{Quote hidden}

-------------------------------------------
Danny Goddard
Design Engineer
ARMA Design
Tel:(858) 549-2531
Fax:(858) 549-2594
Email: @spam@dan_goddardspam_OUTspam.....armanet.com
Web: http://www.armanet.com



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.

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

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


2001\03\02@052717 by D Lloyd

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

Dan






(Embedded     Dan Goddard <RemoveMEdan_goddard@spam@spamspamBeGoneARMANET.COM>@spam@spamspamBeGoneMITVMA.MIT.EDU>> image moved   02/03/2001 10:02
to file:
pic14199.pcx)





Please respond to pic microcontroller discussion list
     <
.....PICLIST@spam@spamEraseMEMITVMA.MIT.EDU>
Sent by:  pic microcontroller discussion list <.....PICLISTRemoveMEspamMITVMA.MIT.EDU>


To:   .....PICLISTSTOPspamspam@spam@MITVMA.MIT.EDU
cc:
Subject:  Re: [PIC]: Switch / If Statement revisited

Security Level:?         Internal


Praise the Lord... Amen :)

At 09:02 PM 3/2/01 +1100, you wrote:
{Quote hidden}

-------------------------------------------
Danny Goddard
Design Engineer
ARMA Design
Tel:(858) 549-2531
Fax:(858) 549-2594
Email: RemoveMEdan_goddardspamspamBeGonearmanet.com
Web: http://www.armanet.com



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.

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






part 2 165 bytes content-type:application/octet-stream; (decode)

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


2001\03\02@052735 by Andy Jancura

picon face
Bob Ammerman wrote:

{Quote hidden}

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.

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


2001\03\02@070643 by mike

flavicon
face
On Fri, 2 Mar 2001 02:02:58 -0800, you wrote:

{Quote hidden}

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

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


2001\03\02@083028 by Bob Ammerman

picon face
> 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)

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


2001\03\02@084716 by Alan B. Pearce

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

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


2001\03\02@085545 by Drew Vassallo

picon face
>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

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


2001\03\02@090657 by Olin Lathrop

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


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, EraseMEolinRemoveMEspamSTOPspamembedinc.com, http://www.embedinc.com

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


2001\03\02@090706 by Olin Lathrop

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


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, spamBeGoneolinspam@spam@embedinc.com, http://www.embedinc.com

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


2001\03\02@091105 by D Lloyd

flavicon
face
part 1 2843 bytes content-type:text/plain; charset=us-ascii
Hi,




(Embedded     "Alan B. Pearce" <A.B.PearcespamspamRL.AC.UK>spamspamMITVMA.MIT.EDU>> image moved   02/03/2001 13:45
to file:
pic29515.pcx)





Please respond to pic microcontroller discussion list
     <
spam_OUTPICLISTspam_OUTspamspam_OUTMITVMA.MIT.EDU>
Sent by:  pic microcontroller discussion list <PICLISTspam_OUTspamMITVMA.MIT.EDU>


To:   RemoveMEPICLISTKILLspamspam@spam@MITVMA.MIT.EDU
cc:
Subject:  Re: [PIC]: Switch / If Statement revisited

Security Level:?         Internal


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

Dan






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






part 2 165 bytes content-type:application/octet-stream; (decode)

part 3 105 bytes
--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspam.....mitvma.mit.edu


2001\03\02@093100 by Douglas Wood

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

Douglas Wood
Software Enigneer
spam_OUTdbwoodspamKILLspamkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://www.piclist.com/techref/member/DW--RA4
{Original Message removed}

2001\03\02@095000 by Scott Dattalo

face
flavicon
face
On Fri, 2 Mar 2001, dr. Imre Bartfai wrote:

> Hi,
>
> what about
>
> Fred = 10;
> if(RB0) Fred <<= 1;

 movlw  10
 movwf  Fred
 btfsc  RB0
  addwf Fred,f


Still just 4 instructions :)

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


2001\03\02@095530 by Diego Sierra

flavicon
face
Hi!

Well, another form, using CC5X compiler could be:

                       ;   W = 10;
m003    MOVLW .10
                       ;   if (RB0) W = 20;
       BTFSC 0x06,RB0
       MOVLW .20
                       ;   Fred = W;
       MOVWF Fred

Same as one could wrote in assembly, but it needs some knowledge about
how the compiler deals with W register, just in case.

Cheers,
Diego.

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


2001\03\02@111321 by Mike Mansheim

flavicon
face
My $0.02 on C vs. asm:

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

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


2001\03\02@111856 by Don Hyde

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

Conditional assignment:

  *0000006B:   Fred = RB0 ? 20 : 10;
  +0000006B: 9BB0      SBIS    0x16,0
  +0000006C: C002      RJMP    ?0003
  +0000006D: E104      LDI     R16,0x14          ; 0x14 = 0b00010100 = 20
  +0000006E: C001      RJMP    ?0004
  *0000006F:?0003
  +0000006F: E00A      LDI     R16,0x0A          ; 0x0A = 0b00001010 = 10
  *00000070:?0004

If else statement with two assignments:

  *00000070: if (RB0)
  +00000070: 9BB0      SBIS    0x16,0
  +00000071: C002      RJMP    ?0006
  *00000072:    Fred = 20;
  +00000072: E104      LDI     R16,0x14          ; 0x14 = 0b00010100 = 20
  +00000073: C001      RJMP    ?0007
  *00000074:?0006
  *00000074:    Fred =10;
  +00000074: E00A      LDI     R16,0x0A          ; 0x0A = 0b00001010 = 10
  *00000075:?0007

Assignment with if to replace if necessary:

  *00000075:    Fred =10;
  +00000075: E00A      LDI     R16,0x0A          ; 0x0A = 0b00001010 = 10
  *00000076: if (RB0)
  +00000076: 99B0      SBIC    0x16,0
  *00000077:    Fred = 20;
  +00000077: E104      LDI     R16,0x14          ; 0x14 = 0b00010100 = 20>
> > -----Original

Message-----
{Quote hidden}

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


2001\03\02@114428 by Andrew E. Kalman

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

Pumpkin, Inc.
750 Naples Street
San Francisco, CA 94112
tel: (415) 584-6360
fax: (415) 585-7948
web: http://www.pumpkininc.com
email: aekspamBeGonespamspamBeGonepumpkininc.com

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


2001\03\02@120800 by jamesnewton

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

---
James Newton (PICList Admin #3)
spam_OUTjamesnewtonSTOPspamspampiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2001\03\02@121408 by jamesnewton

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

---
James Newton (PICList Admin #3)
RemoveMEjamesnewtonspamspampiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2001\03\02@122007 by Andrew E. Kalman

flavicon
face
Re:

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

Pumpkin, Inc.
750 Naples Street
San Francisco, CA 94112
tel: (415) 584-6360
fax: (415) 585-7948
web: http://www.pumpkininc.com
email: TakeThisOuTaekspamspamRemoveMEpumpkininc.com

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


2001\03\02@122023 by jamesnewton

face picon face
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?

---
James Newton (PICList Admin #3)
jamesnewtonRemoveMEspampiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2001\03\02@132444 by Spehro Pefhany

picon face
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"

{Quote hidden}

How does the compiler determine the call tree?

Best regards,



=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
EraseMEspeffSTOPspamspamRemoveMEinterlog.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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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


2001\03\02@140316 by Andrew E. Kalman

flavicon
face
Re:

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

 ______________________________________
  Andrew E. Kalman, Ph.D.   TakeThisOuTaekRemoveMEspam@spam@pumpkininc.com

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


2001\03\02@141730 by jamesnewton

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

---
James Newton (PICList Admin #3)
spamjamesnewton.....spamspampiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

P.S. hope you don't mind a public reply to your comments.

{Original Message removed}

2001\03\05@114705 by Dale Botkin

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

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 hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\05@123233 by Scott Dattalo

face
flavicon
face
On Mon, 5 Mar 2001, Dale Botkin wrote:

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

 btfsc  rb0
  goto  l1

 movlw  10
 movwf  x
 goto   l2
l1:

 movlw  20
 movwf  x
l2:


can be represented by the rule:

target {
  btfsc  %1
  goto   %2
  movlw  %3
  movwf  %4
  goto   %5
%2:
  movlw  %6
  movwf  %4
%5:
} replace {

  movlw  %3
  btfss  %1
%2:
  movlw  %6
  movwf  %4
%5:
}

This is rather simple since it does not need to examine the subsequent flow.

But in general, rules can be added as new optimizable sequences are discovered.
As the compiler matures it will become more efficient.

Scott

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


2001\03\05@160733 by jamesnewton

face picon face
Well, that sounds good too...

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

---
James Newton (PICList Admin #3)
jamesnewtonspam_OUTspam@spam@piclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

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