Searching \ for '[PIC]: How efficient Asm vs PB etc' 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/languages.htm?key=asm
Search entire site for: 'How efficient Asm vs PB etc'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: How efficient Asm vs PB etc'
2002\09\26@053757 by Dave King

flavicon
face
This is a simple question and I doubt I'll get a simple answer but here goes..
I hope I phrase things the right way here.

It's a given that tight ASM code is always the most efficient, ie few if any
wasted instructions.

If I write and compile a pogrom from a higher language such as C or
PicBasic how
will it compare to the ASM version? I'd assume the C version should be better
than the PB version with the amount of benefit related to how good the
compiler is.
I've not done enough (or tried to do enough) ASM lately to be able to tell
and I have
no C compiler to play with. I

'd assume other than a critical timing situation or perhaps
something involving interrupts the basic version wouldn't be too bad. I don't
know how far off the mark I am but I'd like to get an idea of what
situations require
or need  Sort of along the lines of if ASM is 100% then C would be 90% ie
10% wasted
or inefficient code and say basic might be 75%.

I hope I asked that clear enough. I'd just like to have a rule of thumb
derived from
experience  on when one language is clearly needed or better suited than
the other.

Tnx.

Dave

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


2002\09\26@085252 by cdb

flavicon
face
Not an easy answer as it will depend upon the actual compiler
produced.

What I can say is that I use MBasicPro and Fored 'C as well as ASM.

That particular basic loads a lot of macros in and produces a hex
file 1.5 to 2 times larger than the equivalent C program - which is
also about 1.5 times more than if written in asm.

Other compilers will give you different results.

In basic from a compiling point of view (support is a different
matter) the CH compiler from Celestial Horizons or the
PicBasic/Letbasic compiler from Crownhill produce reasonble code plus
they produce an actual ASM file as they go along, MBasic only
provides you with tons of Macro headers in a dot lst file. OTOH
MBasic provide superb support for any problem that you may have.
(Mr Nathan I'll have a new V3.0 programmer for that thank you) o :))

There is also a German company that produces a good Pascal compiler
though they charge an arm and 7 legs for it (750DMs IIRC) and no
longer support it. If your an Atmel man on the side, then they do
support their Pascal Atmel compiler.

Hope that has made things even muddier than they were before.

Colin
--
cdb, spam_OUTbodgy1TakeThisOuTspamoptusnet.com.au on 26/09/2002

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


2002\09\26@101826 by llile

flavicon
face
Dave wrote:
>Sort of along the lines of if ASM is 100% then C would be 90% ie
10% wasted
or inefficient code and say basic might be 75%.


I got paid a good amount of money to take a 1.6K program written in
Microengineering labs PicBasic and squeeze it into a 1K program using C. I
was amazed at how inefficient the ASM generated by the Basic compiler was,
for instance it used the FSR register to work with all variables.

Now, C will never be as tight as ASM written by a good coder.  But most of
us (except for Scott Datallo) are not the greatest ASM coders ever
spawned, so how efficient is our ASM code anyway?  I think you will not
see a huge difference between C and ASM unless your ASM is pretty good,
considering that C compilers can do some tricky optomization you might not
think of.  Your productivity will be far higher using C (or PicBasic for
that matter) and that counts for a lot.

Now, I don't look forward to writing a printf() function in ASM, so I use
C for pretty much everything.

-- Lawrence Lile





Dave King <.....kingdwsKILLspamspam@spam@SHAW.CA>
Sent by: pic microcontroller discussion list <PICLISTspamKILLspamMITVMA.MIT.EDU>
09/26/02 04:33 AM
Please respond to pic microcontroller discussion list


       To:     .....PICLISTKILLspamspam.....MITVMA.MIT.EDU
       cc:
       Subject:        [PIC]: How efficient Asm vs PB etc

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


2002\09\26@124145 by o-8859-1?Q?Tony_K=FCbek?=

flavicon
face
Hi,
Lawrence Lile wrote:
<snip>
>Now, I don't look forward to writing a printf() function in ASM, so I
use
>C for pretty much everything.

well, the point is that you rarely ever need an 'full' printf function.
In asm you have much more power to actually tailor the bin->ascii
conversion for the exact purpose. For example take a look at:
http://www.piclist.com/techref/microchip/math/radix/index.htm

where one can find 'canned' routines for most conversions needs.
( it's lacking in ascii->bin however, but that will be remided soon :) )
Normally i find that in an particular project, data conversion tends to
be
fairly 'fixed', i.e. input size is the same, and output can be
generalized.
Then using an tailored 'printf' would certainly be very effective.

For example the 24 bit, fixed dp, bin to ascii routine is about
290 instructions and uses about 2 bytes of ram (+ string ofcource).
Now I would be impressed if an c-library could provide such an routine
of similar size :). I know I'm streching it, but my point is that,
both c and asm have their uses, personally I haven't seen much benefit
from c concerning pic's in particular, but planning to use that for the
dspic's
as that arcitecture is more suited for c ( IMHO ).

Bottom line: going 'up' in language level will speed up the coding
process but most likely make the generated code larger and perhaps even less
effective.
So as with many other things, an euqaibrium is achived when the program
is written in several languages, time-constrained pieces in asm, and the
bulk in c(or other).

/Tony

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


2002\09\26@130007 by Olin Lathrop

face picon face
> well, the point is that you rarely ever need an
> 'full' printf function.

I agree.  Unless the PIC is going to talk to a dumb terminal or whatever
directly, you don't need ASCII conversion at all.  I've done dozens of PIC
projects, and this has not come up even once.  Many projects do communicate
via RS-232, but these tend to exchange data with a host.  The communications
protocol is optimized for minimizing the PIC code and pushing as much
complexity as possible onto the host.

The closest I've come to any sort of text conversion was for driving 7
segment displays directly from the PIC.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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


2002\09\26@130211 by chucksea

picon face
This was floating around when I was in college 20 some years ago:

http://www.cs.bgu.ac.il/~omri/Humor/RealProg.html

"Strong typing is for weak minds."

I wouldn't stick "C" totally in the strong typing category but it is much more
so that assembler.

An "assembler programmer" (vs. someone who programs in assembler) can program
just as fast, if not faster than a EE using a higher level language like "C"
or BASIC.

The advantage of the higher level languages is to allow someone that's not a
"real programmer" to write software.

chuckc


On Thu, 26 Sep 2002 18:41:40 +0200 =?iso-8859-1?Q?Tony_K=FCbek?=
<EraseMEtony.kubekspam_OUTspamTakeThisOuTFLINTAB.COM> wrote:

{Quote hidden}

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


2002\09\26@131718 by Wouter van Ooijen

face picon face
> Now, C will never be as tight as ASM written by a good coder.

Keep in mind that it all depends (to a large extent, anyway) on the
amount of effort you put into it. Take just assembler. When assigned to
do a one-off project where enginering cost must be minimised I'll write
fast and produce a different kind of assembler than for a 1M units
project, where I can spend months to squeeze the code into the next
smaller chip. Bottom line: there is no *the* effeciency of asm or C,
there is a wide range of effort versus code density (and of course there
are many more variables: quality, execution speed, ease of modification,
etc).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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


2002\09\26@135407 by Dale Botkin

flavicon
face
On Thu, 26 Sep 2002, Olin Lathrop wrote:

> I agree.  Unless the PIC is going to talk to a dumb terminal or whatever
> directly, you don't need ASCII conversion at all.

It does come in awfully handy for some projects, though.  In some cases I
have not used any character I/O at all.  In others I've needed to send
everything from text to integers to floating point numbers to various
devices, including matrix LCDs.  Using printf, for example, gives me one
piece of code that handles all of it and gets reused for every case,
including spitting data out via serial ports and sending the resulting
formatted output to various LCD driver functions.  Of course a lot of
projects only communicate with other PICs, or other systems for which I
just need to conform to some established protocol, and that's pretty
simple too.

> I've done dozens of PIC projects, and this has not come up even once.
> Many projects do communicate via RS-232, but these tend to exchange
> data with a host.  The communications protocol is optimized for
> minimizing the PIC code and pushing as much complexity as possible
> onto the host.

Obviously we're working on different projects <grin>.  I avoid host
complexity like the plague, because that's one more piece of software to
write and maintain -- but it has to run on God only knows what, or the
user is locked into one platform.  I can at least control the PIC side, so
I generally use the lowest common denominator on the host side.

> The closest I've come to any sort of text conversion was for driving 7
> segment displays directly from the PIC.

Mine was (is) a full menu driven user interface used with anything capable
of more or less looking like a dumb terminal over RS-232 or logic levels,
including PCs, pocket organizers, Psion, Palm, etc.  I can be reasonably
assured that as long as asynchronous serial ASCII data can be sent and
displayed on something, somewhere, my device will still be usable without
alteration or updating.  I don't have to care whether Windows, Linux, Java
or anything else comes and goes, my customer is set.

I *can* program in assembler, been doing it since the late 70s on various
processors starting with the 8080.  I did all of my 8748 and 8051
development in assembler.  For whatever reason, I never got comfortable
with PIC assembly, it's just too twisted or I'm too used to machines with
conditional branching and such.  The C compiler has enabled me to do
projects an order of magnitude more complex on a less than straightforward
architecture in the least amount of time...  I call that a winner.  I've
never once run out of memory, and I've only needed to include assembly
code once for an unusually time sensitive task (though I could do it now
without resorting to assembly).  Some people can, I'm sure, do just as
well in assembly, but not me, so I use the tool that gets the job done.

Dale

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


2002\09\27@050407 by Alan B. Pearce

face picon face
>I can be reasonably assured that as long as asynchronous serial
>ASCII data can be sent and displayed on something, somewhere,
>my device will still be usable without alteration or updating.
>I don't have to care whether Windows, Linux, Java or anything
>else comes and goes, my customer is set

I agree. The current project I have is for a PIC to communicate with
something written in C running on windows, so I specified the link to run
only with printable characters, and all variables passed across as hex
characters. Makes link debugging easy, and deciding which end is at fault
even easier. Also meant I could do my development with a dumb terminal.

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


2002\09\28@150941 by sergio masci

flavicon
face
> This is a simple question and I doubt I'll get a simple answer but here goes..
> I hope I phrase things the right way here.
>
> It's a given that tight ASM code is always the most efficient, ie few if any
> wasted instructions.

This is not always true. Simply having a smaller number of instructions
does not necessarily make the section run faster. Consider:

          for (j=0; j<5; j++)
          {        a++;
          }
/*
</techref/postbot.asp?by=thread&amp;id=%5BPIC%5D%3A+How+efficient+Asm+vs+PB+etc&amp;tgt=browse>*/
and
          a++;
          a++;
          a++;
          a++;
          a++;

>
>
> If I write and compile a pogrom from a higher language such as C or
> PicBasic how
> will it compare to the ASM version? I'd assume the C version should be better
> than the PB version with the amount of benefit related to how good the
> compiler is.

I would agree that it is totally dependent on how good the compiler is
but I would not agree that a C compiler would necessarily generate
better code than a BASIC compiler.

>
> I've not done enough (or tried to do enough) ASM lately to be able to tell
> and I have
> no C compiler to play with. I'd assume other than a critical timing situation or perhaps
> something involving interrupts the basic version wouldn't be too bad.

Even with critical timing situations and interrupt handling a good BASIC
compiler should produce respectable code that should do the job just as
well as the equivalent C compiler. Unfortunately in this cost sensitive
industry users  spec MCUs that can just about manage the task required
of them so there tends to be very little tolerence for inefficiency.
Bottom line - a loss of only a few percent in performance gives the
impression that code generated by a compiler can't hack it whereas code
hand crafted by a skilled assembler programmer can.

>  I don't
> know how far off the mark I am but I'd like to get an idea of what
> situations require
> or need  Sort of along the lines of if ASM is 100% then C would be 90% ie
> 10% wasted
> or inefficient code and say basic might be 75%.

In my experience a good compiler will produce code that will knock the
crap out ofcode produced by an average assembler programmer so perhaps
we should redefine your 100% Let us say that given a single high level
statement  a highly skilled expert assembler programmer will producing
equivalent code that cannot be further optimised is 100% In this case I
have seen many compilers (not necessarily for the PIC) that will
routinely produce 100% efficient code (say about 90% of the time) and
that the efficiency drops down to about 80% for less common strange C or
BASIC source. It tends to drop in steps of about 5% this is mainly
because of the way high level source statements map into small sequences
of assembler instructions. So a C statement that maps to 5 assembler
instructions is 80% of the equivalent 4 instructions produced by the
highly skilled expert assembler programmer. You can see that there is
not really much give here for the poor compiler even though it is only
out by one instruction.

From this you should conclude that most good compilers should produce
code that is optimal to better than 95% So how come everyone still
claims 90% tops ? The answer is that the highly skilled expert assembler
programmer tends to optimise large sequences of instructions in
combination. A good compiler will also optimise sequences of
instructions. But the assembler programmer knows the intent of his code
whereas the compiler is trying to work it out. The assembler programmer
knows properties about the problem that the C or BASIC programmer cannot
comminicate to thier compiler so the compiler has to produce safe code
in all cases, it cannot take unsafe short cuts. You can get around this
problem by using higher level languages or mixing your high level
language with a lot of assembler.

The XCASM assembler actually allows you to enter high level statements
and it generates optimised code for these in situ (often to 100%). It's
kind of like using intelligent macros within your assembler source code.
The great thing about this is that it doesn't interfere with the overall
optimisation unless you need to maintain W and FSR intact for a long
sequence of assembler. But even then the use of FSR is predictable and
restricted to use with pointer dereferencing (yep XCASM knows about
pointers), and W is such a scarse resource it would be very difficult
even for a highly skilled expert assembler programmer to reserve its
exclusive use for a long sequence of instructions.

XCASM will convert
      A = A | 4
to
       bsf    A,2

and
      A[j+3-1] = A[j+3-1] + 1
to
      movf    j,w
      addlw    A+2
      movwf    FSR
      incf    INDF


If you're interested you might like to look at the Hi-Tech C compiler,
the SDCC (Scotts) C compiler and my own XCSB structured BASIC compiler.
XCSB does actually optimise single high level instructions very well. It
uses XCASM for the back end so mixed mode (ASM/BASIC) programming should
kick butt. XCSB and XCASM both know about pointer arithmetic and early
out operators (just like the C logical AND and OR operators). The LITE
version of XCSB is free of charge for personal non-commercial use.

Regards
Sergio Masci

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


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