Unused Methods

william chan

Hi,

If a method in an object is unused, will the SPIN compiler exclude it from the final byte code to save space?

Thanks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

BradC

No

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!

william chan

Shouldn't the compiler optimize the unused methods?
That would save a lot of program space.

I mean for example if I were to include some Maths object, I probably will use only 40% of all the methods....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

hippy

Arguably it should, but imagine you have three sub objects each of which call various methods of this maths object ...

Unoptimised and the PropTool knows all three maths objects used are the same and only includes it once.

Optimised and the PropTool would have to include three optimised objects which may be up to three times larger than the single maths object.

There's no necessity to use objects as provided. The solution if you need to save space is to copy the object source into the project directory, rename the file and remove unwanted code, and use that instead.

BradC

Redundant method removal is something I've been working on though.. so it's going to come at some point (along with warnings for unused var's & dead code)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!

Timmoore

Phil's clean program removes unused routines.

Phil Pilgrim (PhiPi)

hippy said...
Unoptimised and the PropTool knows all three maths objects used are the same and only includes it once. Optimised and the PropTool would have to include three optimised objects which may be up to three times larger than the single maths object.

Using CLEAN, the math object would be cleaned of methods that are used by none of the calling objects, and the Spin compiler would include the cleaned object once. This cleaning occurs recursively. If a method gets referenced only by methods that get cleaned from other objects, it aslo gets removed, and so forth. Also, if a cleaned object uses none of the resources of an external object referenced in its OBJ section, that reference is removed.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

hippy

There you go ... checkout CLEAN and see if it does what you need

grasshopper

So I am reading this and I am confused. Unused methods take up memory after compile? Wow I hope i understand this correctly. My programs are full of extra stuff that they will never use.

Hum, can someone put it in plain bold for me. This is True , Guess , False

Timmoore

True
heres an example, a program I just compiled using F8 = 1947 longs for program. I assume variables (285 longs) doesn't take eeprom space.
Using PHil's clean I get a binary image of 1605 longs. i.e. ~18% reduction

hippy

Indeed true.

There's almost no optimisation done by PropTool except not including the same objects used multiple times. Write "var := var" and the code for that will be there. For "if true" any else clause will be included. Add a "return" at the end of a method and there will be two consecutive returns in the bytecode.

Unused methods take up image space but that's not a problem if you have plenty of memory or don't care. Most people can probably ignore the issue and not have to worry about it.

hippy

Timmoore said...
I assume variables (285 longs) doesn't take eeprom space.

They do. The Eeprom loads a full 32KB and that includes the variable space. Only the stack ( everything after code, DAT and variables ) isn't saved to the .binary file.

grasshopper

Thanks for clearing this up for me. Ill make sure to clean up my code.

Phil Pilgrim (PhiPi)

hippy said...
The Eeprom loads a full 32KB and that includes the variable space.

BTW, that's how all the VARiables get initialized to zero. It's the value their image has in EEPROM (or in the binary data loaded to RAM with F10). There's no separate variable initialization phase when the interpreter starts up.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

william chan

hippy said...
There's no necessity to use objects as provided. The solution if you need to save space is to copy the object source into the project directory, rename the file and remove unwanted code, and use that instead.

That is not a good solution if we want to improve on other's objects and return the improvements to obex.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

hippy

william chan said...

hippy said...
There's no necessity to use objects as provided. The solution if you need to save space is to copy the object source into the project directory, rename the file and remove unwanted code, and use that instead.

That is not a good solution if we want to improve on other's objects and return the improvements to obex.

In which case your primary goal isn't to save space but to improve what there already is, and as you don't know what others will want to use in the improved object you cannot really take anything out.

That the PropTool doesn't optimise nor support conditional compilation is one of the things we are stuck with ( at least for now ). If one needs to develop an object which is both for the OBEX and needs to be compact for your own project with methods removed there's possibly no choice but to maintain two separate versions of that object, or a single 'bloated version' which can be trimmed down by a pre-processing utility such as CLEAN.