Searching \ for '[PIC]: How efficient Asm vs PB etc Pt 2' 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 Pt 2'.

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

flavicon
face
Just wanted to revive this thread and ask/ponder on a few things.

I have a fairly simple little program I am playing with in PBPro
(cd8.14/PBP2.42)
It's all of 135 lines including loads of remarks (about 50 lines actual
code) and
about 610 instructions. This is pretty much my complete program.

With remarks its 3.5k If I drop all the remarks its 1.1k. The resulting hex
file
after I compile and assemble is 3.5K. Which might prove interesting fitting
into 1K of space unless I have things wrong and it will fit?.

That is the reason I am curious as to what compiler will put out the
smallest code.
I'm wondering if anyone would be interested in creating a test set and
compiling them.
Ie a simple common task using the same test pic type ie 628, the code is
frozen and
 just compiled and compared.

Of course each  language would have its own test set but there would be as few
changes as possible made to make it work on each compiler. The C should be
the most
portable with few changes.

I know this is a bit of a time waster but the results might be worth knowing.

Dave

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\09\29@073802 by Wouter van Ooijen

face picon face
> about 610 instructions. This is pretty much my complete program.
>
> With remarks its 3.5k If I drop all the remarks its 1.1k. The
> resulting hex
> file
> after I compile and assemble is 3.5K. Which might prove
> interesting fitting
> into 1K of space unless I have things wrong and it will fit?.

Your figures are a bit confusing. 610 instructions = PIC instructions?
In that case it will obviously fit in 1k.

> That is the reason I am curious as to what compiler will put out the
> smallest code.

Post your specifications and the program so we can take up the glove!

Wouter van Ooijen

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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\09\29@083302 by Olin Lathrop

face picon face
> The resulting hex
> file
> after I compile and assemble is 3.5K. Which might prove interesting
fitting
> into 1K of space unless I have things wrong and it will fit?.

You can't go by the size of the HEX file.  It has much overhead.  The data
itself is stored as hexadecimal ASCII digits, so each byte takes a factor of
2 right there.  Then there is an additional overhead of at least (from
memory, so this may be a little off) 1 colon, 2 length, 4 address, 2 type, 2
checksum, and 2 end of line characters for a total of 13 overhead bytes per
line.

The right way to find the code size is by looking at the load map.


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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\09\30@004252 by Bill Westfield

face picon face
   With remarks its 3.5k If I drop all the remarks its 1.1k. The
   resulting hex file after I compile and assemble is 3.5K. Which might
   prove interesting fitting into 1K of space unless I have things wrong
   and it will fit?.

   That is the reason I am curious as to what compiler will put out the
   smallest code.

One of the problems with a compiler is that it is trivially easy to
"accidentally" end up including some library that causes the code size to
get quickly out of control.  (the usual example being something like:
'printf("Hello World");' in C yanking in an entire printf library, complete
with floating point, etc...  Use instead 'puts("Hello world");' and things
might be much better.)

So you can look through your code and see if you've done something similar,
and whether there is an easy substitute to a big function.  Hopefully your
compiler has some reasonable diagnostic output (symbol tables and segment
size information) that you can learn to read to help point out the guilty
parties...

The same principle works the other way for environments with a significant
run-time environment.  Consider a basic stamp (or Java); you've already
"paid the price" to have all sorts of functionality "available", so actual
"programs" can be quite tiny indeed...

BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\09\30@012839 by Wagner Lipnharski

flavicon
face
William Chops Westfield wrote:
{Quote hidden}

Hya Bill, how ya doing partner?
At a recent Atmel meeting in Orlando, the famous CxASM discussion was made
star, and after little time (thanks God), both parties agreed that probably
after 6 to 8kBytes of code, compilers start to make sense over asm, since
after that, compilers can make better use of the variables, routines and
optimizations start to shine bright.  In some tied oppressive conclusion
for the compiler party, it went clear that you can write a very small and
fast code in assembly, LCD, keyboard, Uart, sensors reading, table
conversion and linearization, hex to dec conversion, math processing
routines and all, in less than 800 instructions, of course, unbeatable by
compilers.  Everybody ended the subject with orange juice and coffee (very
black), to refuel the nerves shacking - I was laughing in a corner (of
course).  I still saying;  ScrewDrivers and Hammers represent different
ages, but both still being part of our life. However, never use a Hammer to
push a screw, or a ScrewDriver to pull a nail.  When in doubt - go for
assembly... another rush!  :)

/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Wagner Lipnharski - UST Research Inc
Orlando FLorida - USA - http://www.ustr.net
/_/_/_/ Atmel AVR Consultant /_/_/_/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\09\30@061636 by Bill Westfield

face picon face
For me, now, the BIG advantage of high level languages is portability.
I once wrote a large (>100k source code, I think) assembly language com
program for the IBMPC (a "commercial" effort that never quite made it.)
While I think this was good, well, written, easilly understandable and
very efficient code, it was of no use whatsoever when the business side
of the effort started to make noise about aiming at the "macintosh" thing
instead.  Nor was it very portable to the PC/AT environment when that
came out (and the design goal of running on a 64k machine became laughable),
nor would anything by a re-write be suitable for a windows (any sort)
environment...  I fact, having once been a "systems programmer" for a
mainframe programmed nearly exclusively in assembler, I have tapes full
of vaguely interesting programs that I can't do anything with.

I like hacking around in assemblers.  But I don't intend to write large,
commercial products in assembler, ever again...

BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics



'[PIC]: How efficient Asm vs PB etc Pt 2'
2002\10\02@135616 by Eric Bohlman
picon face
9/30/02 5:14:55 AM, William Chops Westfield <spam_OUTbillwTakeThisOuTspamCISCO.COM> wrote:

>For me, now, the BIG advantage of high level languages is portability.
>I once wrote a large (>100k source code, I think) assembly language com
>program for the IBMPC (a "commercial" effort that never quite made it.)
>While I think this was good, well, written, easilly understandable and
>very efficient code, it was of no use whatsoever when the business side
>of the effort started to make noise about aiming at the "macintosh" thing
>instead.  Nor was it very portable to the PC/AT environment when that
>came out (and the design goal of running on a 64k machine became laughable),
>nor would anything by a re-write be suitable for a windows (any sort)
>environment...  I fact, having once been a "systems programmer" for a
>mainframe programmed nearly exclusively in assembler, I have tapes full
>of vaguely interesting programs that I can't do anything with.

There's a law of genetics known as Fisher's Fundamental Theorem of Natural Selection which says
that the better adapted an organism is to its current environment, the less of a change in its
environment it can survive.  The result is that most organisms are reasonably well-adapted to
their environments, but not optimally adapted; evolution selects for "good enough" rather than
"optimal."  Species that start to get optimized find themselves optimized out of existence.

Gerald Weinberg has observed, in his classic _The Psychology of Computer Programming that this
applies to human creations as well, particularly to programs.  He gave a really good example where
a systems programming team for an early computer was writing an assembler and they discovered that
they could create a perfect hash function that would map the mnemonics for the instructions into a
compact range of integers without the need to do chaining or probing or any of the other sort of
stuff a standard hash lookup routine needs to do.  They were very proud of themselves, but then
the next version of the hardware came out, with one or two extra instructions, and all of a sudden
there was no perfect hash in sight.  So the team had to go ahead and write the standard hash table
stuff, and all the work on the perfect hash turned out to be wasted effort.

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


2002\10\07@011337 by Bill Westfield

face picon face
Have y'all seen the latest "Circuit Cellar" magazine?  There's an article in
there that makes an interesting case study, WRT to the ASM vs compiler (and
related) questions.  It'a about a simulated candle (for use on-stage) using
an LED.  The simulation is based on some flame science, and includes a
random number ("White noise") generator and a floating point SW
implementation of a low pass filter, samples a self-heated thermistor to get
air current info, and drives a single PWM output.  It's done on an atmel
AT90S8535, which is a somewhat sizeable AVR (8K memory, 40pin device) to
support the single input, single output, and of course a good deal of
floating point support and compiler library support for the PWM and A-D
peripherals on the chip.

It's hard to argue with the design choices here, for a one-piece item where
the designer's time undoubtably cost a lot more than the parts.  But it's
also a design that just cries out for a "cost reduction effort"; there's no
reason I can think of that it wouldn't run in an 8-pin PIC, given some
attention to size and clever use of fixed point math.  (OTOH, Bob Pease or
other analog expert could probably convert it to a code-less design based
around a $0.30 quad op-amp, but that's another issue entirely :-)

BillW

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


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