Post by thread:Squeezing it all in

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 in. Tony For the beginner.... PicNPoke Multimedia 16F84 Simulator Assembler, and Tutorial. Now with PicNPlay circuit simulator. Plus animated Address Mode Tutor. http://www.dontronics.com/picnpoke.html

TONY NIXON 54964 wrote about crunching code into limited ROM. Congratulations. 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 - etc. 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!

On Fri, 16 Jan 1998 11:00:34 +0000 Keith Howell <spam_OUTkeithhTakeThisOuTARCAM.CO.UK> writes: >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 >- etc. >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 all...). Harold

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 world. 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 away. 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 other toy! Keith Howell wrote: {Quote hidden}> TONY NIXON 54964 wrote about crunching code into limited ROM. > > Congratulations. > > 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 > - etc. > 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!

How about hiring an "optimizing programmer". Better algorythms always beat optimizing compilers/assemblers. Bill :-) At 11:00 AM 16/01/98 +0000, you wrote: {Quote hidden}>TONY NIXON 54964 wrote about crunching code into limited ROM. > >Congratulations. > >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 >- etc. >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! >

On Fri, 16 Jan 1998 19:37:44 -0500, you wrote: >How about hiring an "optimizing programmer". Better algorythms always beat >optimizing compilers/assemblers. > >Bill :-) 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 bytes saved. 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 / .....wwlKILLspam@spam@netcomuk.co.uk _/ L_/ _/ 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 :)) Walter Banks http://www.bytecraft.com

In message <19980116.120128.26935.1.HaroldHallikainenKILLspamjuno.com>> .....PICLISTKILLspam.....MITVMA.MIT.EDU writes: {Quote hidden}> On Fri, 16 Jan 1998 11:00:34 +0000 Keith Howell <EraseMEkeithhspam_OUTTakeThisOuTARCAM.CO.UK> > writes: > > >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 > >- etc. > >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 > all...). > Harold, This is something that the CCS C compiler does very well. I would love to have this in an assembler. Regards, Mike Watson

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.