Can I put my program on a code diet?

4Alex

Hi all,

I have a question that bugged me for some time now and I can't find a clear answer. Certainly someone knowledgeable from this forum can answer it for me.

Say you write a program for the propeller. Now, you write your own piece of code in a main spin file. Then, instead of re-inventing the wheel, you simply add-up fine & dandy librairies already written by much more seasoned programmers than you are. It works just fine, great. Now, there's a ***lot*** of functions, and features, and wonderful pieces of coding coming with these librairies that my program don't use or call in anyway, shape or form.

Here's my question: when the whole program is compiled and transferred to the propeller, is it all the coding PRESENT in the program (including the un-used functions in librairies) that is compiled or it is rather ONLY the pieces of coding that are actually being used by the program? Reason for my question is that I'm quite tight in memory use at this point and I'd like to get a smaller program. Is getting rid of functions not in use going to help at all?

Thanks for your help.

Cheers,

Alex

Sapieha

Hi 4Alex.

Yes all code is compiled and added to binary file.

You can omit all unnessesary code and save many longs in HUB

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

StefanL38

Hello Alex,

that's easy to find out

hit F8 to compile your code and see the memoryusage

if you comment out a method that you do not use and hit F8 again you can see how many bytes
are used now.

If you comment out any method that is used by your program the complainer will compile - eh vice versa )

best regards

Stefan

4Alex

Hi Sapieha and Stefan.

Thanks for your quick replies. I already use F8 quite a bit! So, it seems that I really have to dig into the bowels of each and every librairy in use, check if something is used or not, and remove bloating code. That's quite a task!

I half-hoped that the compiler would ignore (to an extent) what's not being used...

Oh well, back to the threadmill then. BTW, if I do get rid of the librairy code that is not being used, does it means that my program will actually run faster?

Thanks a lot.

Cheers,

Alex

Mike Green

The Propeller Tool has no way to leave out unused methods, but the 3rd party compilers (I'm not certain about BST though) have options for doing this if it's important.· There are other, more complicated, ways to save memory.· Most of the common objects (display drivers, serial drivers, keyboard drivers, floating point package) have substantial assembly language routines that are not needed once the driver is loaded into its cog and executed.· It's possible though awkward at best to reuse this space.· It's possible to load these from a separate area of EEPROM with some work.· The routines have to be written or modified for this purpose.· With 4 drivers, you could have 8K bytes tied up in assembly code.

Leaving out unused code will not speed up your program unless you can use the extra memory to improve your code.

4Alex

Good evening Mike,

Thanks for your reply. If I do get rid of the librairy code that is not being used, does it means that my program will actually run faster?

Cheers,

Alex

Sapieha

Hi 4Alex.

Not faster but it can have more space to other things.
After You cut all unessesary code ... You still run same efective code length

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

4Alex

@Sapieha:

Thanks. I guess its going to be quite a cut-and-test job!

There must be a way to make some sort of external program to analyse the overall code and detect what is unused... I could definitely see use for such a post-processor.

Cheers,

Alex

mctrivia

as mike said there are several 3rd party compilars that will find what code is not used and not include it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5

Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.

Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.

Mike Green

It's a relatively difficult problem if a method is called internally. It's easy if the method is only called externally. If it's called internally, you have to make sure that the routine that calls it is itself not called by anything else. Basically, you have to simulate the program and do what's called a path analysis to see if there's any path through the program that results in a call to a particular method. If not, then the method can be eliminated. This sort of thing is done all the time with an optimizing compiler which the Spin compiler is not. Optimizing compilers are usually large, complex, and relatively slow because of all this extra work they have to do. Many of the GCC compilers have this ability as an option (because they need more memory and are slower when it's enabled).

4Alex

Hi all,

Ok, great. I get it. Now I do understand what involved in creating a lean machine. Thanks.

Cheers,

Alex

Timmoore

There is an earlier thread that discusses the various options to leave out routines - bst leaves the function table but removes unused code, clean removes both, dont remember offhand the other options. See http://forums.parallax.com/forums/default.aspx?f=25&m=355737

heater

Mike that kind of cleaning is pushing to hard isn't it ?
Surely in Spin if a method is defined somewhere but is never referenced by it's containing object or any external object then the compiler could always safely remove it? After all Spin has no way to call a method through a pointer which just happens to be sneakily created at run time to point to it (like one might manage to do in C)
It could be a method is referenced by some other code but that code never actually gets executed, yes that is tricky to detect as we would have to seriously analyse the thing to see if it ever called or not.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Mike Green

@heater,
I was really describing the ideal case for removing unneeded code. You're correct that the easy cases are indeed easy and, in Spin, fairly common. In included objects, there are often small interface methods that are never called and they're rarely if ever called internal to the object, so they're easy to locate and safely remove. I don't think you'll save a lot of space, but sometimes that's all you need. I do think that recovering the assembly driver space is at least as important since that comes out to 4 bytes per instruction and many assembly routines are several hundred instructions.

BradC

Mike Green said...
@heater,
I was really describing the ideal case for removing unneeded code. You're correct that the easy cases are indeed easy and, in Spin, fairly common. In included objects, there are often small interface methods that are never called and they're rarely if ever called internal to the object, so they're easy to locate and safely remove. I don't think you'll save a lot of space, but sometimes that's all you need. I do think that recovering the assembly driver space is at least as important since that comes out to 4 bytes per instruction and many assembly routines are several hundred instructions.

It's not that difficult to remove unused methods in SPIN. The compiler simply reference counts each method as the code is compiled and then goes back and re-compiles, reducing all methods with a reference count of 0. This process continues iteratively until no more methods are removed.

bst[noparse][[/noparse]c] does this at the moment, but leaves the method in the method table (which costs 1 long) and reduces the spin method to a simple return (which costs 1 byte). I've figured out how to remove these also, but it'll be a while until I get a chance to update the compiler to do it.
Removing anything in assembly is a much more dicey proposition as self modifying code can perform all sorts of nasty tricks that might fool the compiler into doing something wrong. It's easier to leave it untouched.

In some applications where lots of pre-assembled objects are simply bolted together, redundant object removal can save a significant amount of space. In code where the author has taken care and spent some time on planning, the compiler can rarely (if ever) beat a human.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!