'Squeezing it all in'
TONY NIXON 54964
|I think I just outdid myself.
A year or so ago I wrote some software for a C84 and it was full to
the brim. Then I had to modify the code to enhance it's capabilities.
This meant that I had to find no less than 60 ROM locations to fit it
all in. I must have gone over the code a hundred times and I managed
to fit it in with 1 spare location. Most of the RAM locations also
have dual functions as well.
Lately I have been asked to change the software to allow users to
be able to program for either positive or negative angles instead of just
positive ones. I told them I couldn't because the chip was bulging at the
sides with a ROM problem already and I needed to find at least
another 20 ROM locations to fit the modified code.
Anyway, with not much hope, I finally decided to have a go.
Another 40 or so tries of going over the code, a change here, a snip
and a trick or two there, and what do you know, it fits. I wouldn't
have believed it.
It's amazing what you can do with more experience hanging over the belt.
I think I'm going to have to put steel reinforcing on the chip to keep it all
For the beginner....
PicNPoke Multimedia 16F84 Simulator Assembler, and Tutorial.
Now with PicNPlay circuit simulator.
Plus animated Address Mode Tutor.
TONY NIXON 54964 wrote about crunching code into limited ROM.
I wish there were decent design tools for assembly programming.
I don't mean just an assembler, but something that would
- point out where registers can do double duty
- point out potential stack overflows
- manage code and data paging
so that I can concentrate on the application and not the
intricacies of the chip.
Compilers do a lot of automated code generation and checking.
It would be nice to have the same sophistication for assembly.
For me, limited resources are just one challenge.
I want to know if the code I write is flawed or not.
Recalling product with duff code is more expensive than
paying for slightly bigger PICs!
>It's amazing what you can do with more experience hanging over the belt.
So THAT's what's hanging over my belt! I need to tell my wife not to make
me lose any <G>.
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
|On Fri, 16 Jan 1998 11:00:34 +0000 Keith Howell <ARCAM.CO.UK> keithh
>I wish there were decent design tools for assembly programming.
>I don't mean just an assembler, but something that would
>- point out where registers can do double duty
>- point out potential stack overflows
>- manage code and data paging
>so that I can concentrate on the application and not the
>intricacies of the chip.
I am forever allocating ram (file registers) inside subroutines
(using cblock and endc, letting the assembler assign the next sequential
locations). Most of these could be automatic local variables that would
best be placed on a stack where they could be deallocated on exit. A few
are static local variables and the permanent allocation is appropriate.
It seems that having the assembler keep track of this would be extremely
difficult (without a stack). It would have to anticipate all the
possible call sequences so that a reused local variable does not get
overwritten. This all reminds me of my days of extensive Basic
programming where I'd have something in temp, do a gosub that also used
temp, then wonder why temp was corrupted on return.
Local variables are wonderful! A hardware stack seems like the
easiest way to implement them. We don't have that in the PIC (RISC and
Wim E. van Bemmel
Yes Keith !
There ARE decent tools to relieve you from all the intricacies of the device
you are programming.
We call these things "higher level languages".
"C" is an example, "BASIC" another to mention two that are around in PIC
They do the translation to assembly code for you.
They shout at you, if you are lucky, when they get out of memory, and only if
you programmed them to do so, and on systems that are able to shout.
PIC's do not shout. They do not report errors either. They just crash or run
Even highest level languages do not tell you how to stay with your program
within the limits of your hardware. How should they know?
Sorry, in Embedded World you walk alone!
See it as a challenge, and be happy, or see it as a nuisance, and find an
Keith Howell wrote:
Bill (WL) Boulton
How about hiring an "optimizing programmer". Better algorythms always beat
At 11:00 AM 16/01/98 +0000, you wrote:
|On Fri, 16 Jan 1998 19:37:44 -0500, you wrote:
>How about hiring an "optimizing programmer". Better algorythms always beat
I thought about writing a relatively simple utility to automatically
analyze code to find candidates for 'obvious' optimisation, which
didn't need much analysis of code structure.
It would just point out possible optimisations, leaving it up to the
programmer to decide if they will cause any problems (stack depth,
timing etc.), or save enough to justify reduced code readability etc.
A few eamples of some 'obvious' optimisations :
call followed by movlw, where the movlw can be omitted by retlw'ing
the appropriate value.
Shared subroutine exit code, which can be reduced by one subroutine
ending in a goto (end of other routine)
Sections of repeated code which could be put in subroutines. Even a
2-instruction sequence, if used 3 or more times, can usefully be put
in a subroutine to save space. The utility would calculate the the
tradeoff between number of repeats versus code fragment length to see
if any saving is possible, and then list all repeats in order of
multiple skip/goto combinations which could be re-arranged
Subroutines only called once, which could be changed to in-line.
Unused (un-callable) subroutines/code fragments left-over from debug
code/earlier versions etc.
The first two aren't too hard to do manually, unless you have a lot of
macros. The third would be the most useful, as you could get exact
quantative figures for savings - you tend not to consider moving very
short sequences to subroutines.
_/ L_/ Mike Harrison / White Wing Logic / netcomuk.co.uk _/ L_/ wwl
_/ W_/ Hardware & Software design / PCB Design / Consultancy _/ W_/
/_W_/ Industrial / Computer Peripherals / Hazardous Area /_W_/
Bill (WL) Boulton wrote:
> How about hiring an "optimizing programmer". Better algorythms
> always beat optimizing compilers/assemblers.
As long as they are better than the algorithms used in
the compiler. BTW where as can you buy a programmer
with as much algorimic knowledge as a modern compiler
for a fixed fee no matter how much it is used. Updates
are either free or at a very reduced cost :))
In message <juno.com>
19980116.120128.26935.1.HaroldHallikainenMITVMA.MIT.EDU writes: PICLIST
This is something that the CCS C compiler does very well. I would love
to have this in an assembler.
To Bill (WL) Boulton:
I'm not going to ask my employers to hire such a person.
My primary purpose is to put bread on my table,
not myself on the dole. :-)
I'm sure they'd have preferred a really experienced person,
but in the real world companies have to get the best they
can at reasonable notice and cost.
Better programming skills producing better algorithms
are always desirable, but note this problem is not a
typical university course problem.
I'm aware that an algorithm may vastly improve execution
times: e.g. Bubblesort vs. Quicksort.
Sorting a list of items is a single conceptually simple task.
In embedded control systems, or at least in mine,
there are not one but many tasks being done.
The single most important aspect is not execution speed.
It is robustness and reliability.
The main difficulty is not finding a better algorithm.
It is keeping track of all the possible interactions,
use of resources, etc.
This is a tedious task I'm sure even the most gifted
programmer would gladly abdicate to a computer.
I have tried to use as many ways as I can to automate
code generation, and make it easier to specify.
Macros, cblock, etc. Thanks to Harold Hallikainen for
his thought BTW.
In reply to the slightly sarcastic :-) Wim E. van Bemmel,
I would prefer a high-level language of course, but
assembler was forced upon me! I had a look at the
code output of the CCS compiler mentioned by Mike Watson,
and appreciated the ability to generate a calling tree.
It may do many other useful things to manage the code, but
the code looked very inefficient. And it hogged code space.
In my case it doubled the size of my assembly code!
I did manage to cajole it into much smaller code size,
but was not impressed at its ability to conserve code size.
I think the best bet may be to write in C, but bear in mind
assembly techniques. This gives the compiler a nudge toward
generating smaller code.
a good rule of
Mike Harrison's comments were more what I was thinking of
when I made my posting.
More... (looser matching)
- Last day of these posts
- In 1998
, 1999 only
- New search...