Searching \ for 'Compiler Efficiency' 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/index.htm?key=compiler+efficiency
Search entire site for: 'Compiler Efficiency'.

Truncated match.
PICList Thread
'Compiler Efficiency'
1996\04\13@155946 by myke predko

flavicon
face
Hi Gang,

I've just received the April 1996 issue of "Nuts & Volts" and the first
article is Scott Edward's "Stamp Applicatoins".  The start of the article
discusses a speed problem with an application and then goes on to discuss
ways around speed problems other than being a genius with Assembler and that
is to use a compiler to create the code.

In the article, he uses the code fragment:

again:
 b1 = b1 + 1
 toggle 0
 goto again

to benchmark various flavours of Stamp to a 16C84 Running at 4 Mhz.  When I
look at the results, I am comfortable with what the Stamps do (vanilla, a
little less than 700 usecs per instructions in the loop - which translates
to approx 1500 instructions per second, which is in the range of what
Parallax advertises for the Stamp).

But, when the 16C84 with compiled code was put on there, the results were
significantly better - a 15x improvement in speed.

But, I would have expected an *astoundlying* improvement in the loop.  Scott
says "compiled code is rarely as efficient as code written by a crafty
assembly-language programmer".  But, I would have expected significantly
better performance from the Compiler.

I would have expected any decent compiler to create the following code from
this source:

again:
 incf b1, reg                  ;  b1 = b1 + 1
 movlw 1                       ;  toggle 0
 xorwf portx, reg
 goto again

This takes 5 instruction cycles (1 each for data instruction, 2 for the
goto).  And if it was running on the C84 running at 4 MHz, this would yield
200,000 loops per second (versus 7215 for the compiled C84 in the article
and 479 for the Stamp).  I would expect the compiled code to be 417.5x
better than the Stamp, not the 15x of the compiled version.

Being a "crafty assembler-programmer", I would code this as:

 movlw 1                        ;  Setup the Bit for the toggle.
again:
 incf b1, reg
 xorwf portx, reg
 goto again

This lowers the in-loop cycle count to 4 cycles, for a loop speed of 250,000
loops per second.  Which improves the (my) expected compiler code by only
1.25x (which seems reasonable to me, based on what I've seen in terms of PC
Compiler technology).

So, the net result of all this is, is this reflective of the current PIC
compiler technology?  If it is, I'd like to understand what the PIC is doing
throughout that loop.

I'm also concerned because code produced by such a compiler must be an
absolute bitch to debug, because you probably have no idea what's going on
in the code, when you run the simulator on it.

I'm not trying to cut anybody down, but I would have thought that the
compiler would be able to produce significantly better code.

Myke
Myke

"We're Starfleet officers, weird is part of the job."

Capt. Catherine Janeway

1996\04\13@203741 by Martin Darwin

flavicon
At 03:57 PM 96-04-13 EDT, you wrote:

[munch...]

>But, when the 16C84 with compiled code was put on there, the results were
>significantly better - a 15x improvement in speed.
>
>But, I would have expected an *astoundlying* improvement in the loop.  Scott
>says "compiled code is rarely as efficient as code written by a crafty
>assembly-language programmer".  But, I would have expected significantly
>better performance from the Compiler.

Don't forget that the Basic Stamp must first fetch the next instruction from
the EEPROM before it can actually interpret what the commmand does.  This
contributes to a massive slow down in execution speed.

MD
--
Martin Darwin   Second Year Computer Engineering
spam_OUTs721099TakeThisOuTspamaix2.uottawa.ca      University of Ottawa
"When in doubt -- Mumble"       Ottawa, Ontario

1996\04\13@212622 by Don McKenzie

flavicon
face
On Sat, 13 Apr 1996, myke predko wrote:
> I've just received the April 1996 issue of "Nuts & Volts" and the first
> article is Scott Edward's "Stamp Applicatoins".  The start of the article
> discusses a speed problem with an application and then goes on to discuss
> ways around speed problems other than being a genius with Assembler and that
> is to use a compiler to create the code.
------snip-------snip------
> But, I would have expected an *astoundlying* improvement in the loop.  Scott
> says "compiled code is rarely as efficient as code written by a crafty
> assembly-language programmer".  But, I would have expected significantly
> better performance from the Compiler.
------snip-------snip-----^^^^^^^^^^^^^
> Myke

Don't get N&V in Australia in a hurry Myke. What Compiler is Scott using
for these speed comparisons?

Don...

Don McKenzie .....donmckKILLspamspam@spam@labyrinth.net.au
DonTronics Tullamarine, Australia

This home page has many links to PIC/Stamp sites and data.
http://www.labyrinth.net.au/~donmck

1996\04\14@005636 by Clyde Smith-Stubbs

flavicon
face
myke predko <mykespamKILLspamPASSPORT.CA> wrote:

> I would have expected any decent compiler to create the following code from
> this source:
>
> again:
>   incf b1, reg                  ;  b1 = b1 + 1
>   movlw 1                       ;  toggle 0
>   xorwf portx, reg
>   goto again

That's precisely what a decent compiler does produce; herewith a C file:

#include        <pic.h>

main()
{
       unsigned char   c;

       for(;;) {
               c = c+1;
               PORTA ^= 1;
       }
}

and here's the unretouched generated assembler code:

       psect   text
_main:
;       _c assigned to ?a_main+0
l2:
;x.c: 5: unsigned char c;
;x.c: 7: for(;;) {
;x.c: 8: c = c+1;
       incf    ?a_main
;x.c: 9: PORTA ^= 1;
       movlw   1
       xorwf   5
;x.c: 10: }
       goto    l2

The optimizer has not shifted the movlw outside the loop - that's a
useful touch that can be added.

Clyde

--
Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: +61 7 3300 5011
.....clydeKILLspamspam.....hitech.com.au      | P.O. Box 103, Alderley, | Fax:   +61 7 3300 5246
http://www.hitech.com.au | QLD, 4051, AUSTRALIA.   | BBS:   +61 7 3300 5235
----------------------------------------------------------------------------
For info on the World's best C cross compilers for embedded systems, point
your WWW browser at http://www.hitech.com.au, or email EraseMEinfospam_OUTspamTakeThisOuThitech.com.au

1996\04\14@105708 by myke predko

flavicon
face
Don,

It's the "PBASIC" Compiler by Micro Engineering Labs.  I was a little
reluctant to include the name because I didn't want it to be perceived that
I am knocking them.  My question really was, what is the current state of
Compiler technology and are these results representative of what's available?

Just out of curiosity, *is* Scott Edwards on this List Group and should he
be invited to join (Seeing as how he has established himself as an expert on
the Stamp and other things PIC-related)?

Myke
{Quote hidden}

Myke

"We're Starfleet officers, weird is part of the job."

Capt. Catherine Janeway

1996\04\14@205558 by Don McKenzie

flavicon
face
On Sun, 14 Apr 1996, myke predko wrote:
> Don,
> It's the "PBASIC" Compiler by Micro Engineering Labs.  I was a little
> reluctant to include the name because I didn't want it to be perceived that
> I am knocking them.  My question really was, what is the current state of
> Compiler technology and are these results representative of what's available?

No that's fine. To my knowledge, this will be the first PIC Basic
Compiler available. Being Stamp-1 code syntax compatible with intermediate
Mchip and Parallax Source code generation, I'm sure it will fit a gap in
the market. I feel it can only enhance Stamp sales. Develope the code on a
Stamp, then Basic compile to a PIC chip, perhaps the 84!

I know there is a speed trade-off for this liberty. It falls somewhere
between a Stamp Interpreter chip reading a serial EEPROM, and a fine
piece of artwork that has been hand assembled.

If we were all fine machine code generators, the Stamp products wouldn't
sell in the quantities they do. On the other hand, I know of many good
programmers that use the stamp as a quick (and software cheap) solution to a
problem.

To hardware speed things up a whisker, I have found that I can run all 84
devices on an 8Mhz crystal, and 12Mhz on one of those 4 pin tin can
oscillators. I know Scott pushes the Stamp-1 to 16Mhz (which is a 16c56/xt),
but I'm not sure if this is 100% successful. In all cases, work outside
the MicroChip specs., and you are flying solo.

> Just out of curiosity, *is* Scott Edwards on this List Group and should he
> be invited to join (Seeing as how he has established himself as an expert on
> the Stamp and other things PIC-related)?

Scott is a lurker of this list, so I dare say he picks up on most of this
stuff. As he is running a Business, it may not allways be practicle to
jump in on every mention of his goods and findings, but I'm sure he will
if the need arises.

Don...

Don McKenzie @spam@donmckKILLspamspamlabyrinth.net.au
DonTronics Tullamarine, Australia

This home page has many links to PIC/Stamp sites and data.
http://www.labyrinth.net.au/~donmck


'Compiler efficiency'
1997\07\03@134735 by mbonner
flavicon
face
I find myself eating my words.  I supported ByteCraft in a recent
compiler thread, with the caveat that even though MPC generated
excessive bank switching code, it hadn't caused me any problems yet.
That was then.  This is now.

Adding the equivalent of 65 bytes of assembler generates an additional
349 bytes of assembled code (17 bytes too much to fit in a '74).
Granted, the extra code might shift things around a little, but a
five-fold increase?

There were multiple instances of the following:
 BCF PCLATH,3
 BCF PCLATH,3
(Just to make extra sure it was cleared, I guess)

And the following
 BCF PCLATH,3
 BSF PCLATH,3

Any suggestions?  (Other than editing the assembly directly - I chose C
so that I could maintain in it years to come.)  Maybe ORGing modules or
rearranging some code?  I know it's hard to make suggestions without
seeing the actual code, but some general comments would be greatly
appreciated.

Walter B - why did you have to go on holiday now?

--Matt

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