Optimize tricks?

T Chap

Out of ram and a long way from home.

Looking for any suggestions on ways to shrink the binary.

For example, I just learned that using a repeat(n) uses less room that putting the same command multiple times in a row (ie waitcnt).

Also going through all your objects commenting out unused code reduces size.

Post Edited (TChapman) : 5/30/2009 11:07:46 PM GMT

Phil Pilgrim (PhiPi)

As you point out, anything you can do to parametrize identical or similar code segments is good. Also, in a DAT section, if a variable doesn't need to begin with a certain value, be sure to use res instead of long or its shorter kin, since reses don't take up any hub memory. Pare VARs to their minimum necessary size. Use local variables in methods wherever possible, since they only occupy room on the stack when the method is running. Pay closer attention to stack length. Does that stack really need 100 longs? Shorten I/O buffers and other arrays to the minimum necessary to operate. strings can take up gobs of hub memory. Shorten or eliminate as many as you can get by with.

'Just a few ideas...

-Phil

SRLM

I like to abstract common tasks into functions. For some programs, you're doing similar things in lots of different places. Figure out the commonalities, and toss it into a function.

lonesock

Things I try to do to save on space:

* If you are using objects from the exchange (or any outside source for that matter), consider saving a modified version where you pare out any functions not used in your application.
* If you can take the speed hit, use Spin instead of PASM (this can include everything from using the Spin Float object instead of the faster PASM one. Also, copying the initialization values for a PASM DAT block to hub RAM before starting a cog (using longmove) so those values get loaded into the cog during the cognew, instead of using par and a bunch of PASM instructions to load in an array of (for example) variable locations).
* always use long/word/bytemove and long/word/bytefill over rolling your own loops

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

Post Edited (lonesock) : 5/30/2009 11:08:15 PM GMT

jazzed

Reuse DAT PASM space for buffers if possible .... Always use constant() on things like n := 3*CON_MULTIPLE ....
Other advanced things can be done if you need more Spin code space and have big PASM blocks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Timmoore

I use a program by Phil called clean, it looks at the routines in use and deletes the routines not used at compile time. Allows you to kept standardized objects without the overhead. I normally see 40% code size saving using that. I believe Brad's bst does the same.

T Chap

Yes I am using bst, but I notice that when I delete unused routines manually from the main program or objects, that there is a reduction in size. Thanks for the the ideas above.

Clean? Never heard of it.

Timmoore

Clean - see http://forums.parallax.com/forums/default.aspx?f=25&p=1&m=278123
It generates temp files with the unused code removed and then compiles that so it should be the some as you deleting the routines

T Chap

Clean is a significant benefit. I had already manually dropped from a barely able to compile size of 7858 down to 7300. Clean took it to 6700. Thanks for the reference, although I am not sure why Phil didn't mention it in his response, as it is a simple fix that anyone should be using when hitting the wall.

Cluso99

You could load the pasm code into the cogs from the upper section of the eeprom (presuming you are using 24C512).

Perhaps an explanation of what you are trying to do may help.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Timmoore

Yes, my current project is too big for the propeller tool, it will not compile it. With clean it works no problem. Clean also allows you to use a pre-processor. I use the visual studio C++ preprocessor for #ifdef support. My current project is about about 60% of the propeller tool size with clean but thats because I haven't manually deleted anything from my standard objects.

T Chap

All my own stuff is Spin with the exception of a few objects. It is possible now to finish out the project with the improvements already today.

"always use long/word/bytemove and long/word/bytefill over rolling your own loops"

Does this apply to Spin? Not clear on what "rolling my own loops" means:

T Chap

Just some experimenting info:

After manually doing what I could I went from 7850 to 7338 with BST and NO optimizers turned on (folding, deleting unused, etc first 4 options under compiler prefs UNchecked).

Turn on the first 4 optimizers in BST under complier prefs and the result is: 6915.

Run clean in the file, reload clean file into BST without and compile without BST optimizers: 6717

Turn on BST optimizers on the Clean file: 6705

The Clean app seems to work but hangs up each time, errors that maybe 6 files were expected to have unique names. Sometimes it lists a row of longs from my vars, other times a row of words. Not a big deal as it saves the file and the file appears top run fine.

Phil Pilgrim (PhiPi)

Could you post the code that Clean chokes on, please? I'm curious what might be causing it to hang.

Also, I'm sorry for neglecting to mention it from the get-go. It's just been off my radar for so long, I didn't think of it. Besides, a third party recommendation carries more weight anyway!

-Phil

virtuPIC

Years ago Chris Fraser wrote some papers on code compression using LZ-something algorithms. The decompressors are tiny pieces of code and they are fast. Would be interesting for the prop in general.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys

BradC

bst takes an easy route to unused-method removal and leaves the method in the method table. So each unused method still costs one long (method table entry) and one byte (return bytecode). I'm assuming clean will remove those also. I've looked on and off at how to easily refactor the code at compile time but I've never really found a clean way to do it. (not that I've tried *that* hard as the current method does a nice enough job for me)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!

lonesock

Here's a silly one, gaining you (at most) 1 long!

As you know, you can't have PASM constants using more than 9 bits, so those constants are typically defined as a long and pre-initialized, e.g.:

negativeone long -1

where in the code it is used:

mov x, negativeone

There are some tricks you can use for cases like this:

' the obvious one, lower 9 bits
mov x, #128
' good for storing "negative" 9-bit numbers, e.g. store -1 ($FFFFFFFF) into x
neg x, #1
' good for setting bits 17..9
movd x, #511
' good for setting bits 31..23
movi x, #511
' note that movs is basically equivalent to mov, for our purposes, as it only sets bits 8..0

So, in summary, in PASM and for certain constant values only, you can get away without defining a constant long, saving you a whopping 4 bytes, yay.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.