Dead code removal with ICCProp?
Nick Mueller
Posts: 815
Hi!
I'm still using the Demo-version (since about 10 days), so this *might* be the reason.
Happily coded along and started more and more to wonder, why the linker says "device is 11.62 % full" or similar low numbers until "out of _bss segment" (or such). OK, the percentage is wrong. You'd have to add flash + SRAM to get the right number.
Anyhow, looking at the map file to see where all that code is coming from, and playing around, I discovered, that the linker includes code that is definitly not used. How that? Tried to build a .lib in the hope that only required code is linked in, but failed. Demo version?
Also found functions that certainly aren't used by me. _FSqr, _FFloat, _log, _log10, _islower ... And no, I'm using the most simple version of printf.
Do I have to buy the Prof-version?
No problem with that, but I'd like to know in advance wether I can do the project. From that moment on, I'd use it frequently (something elder waiting to be ported to C, and new stuff...).
Any insights?
THX,
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I'm still using the Demo-version (since about 10 days), so this *might* be the reason.
Happily coded along and started more and more to wonder, why the linker says "device is 11.62 % full" or similar low numbers until "out of _bss segment" (or such). OK, the percentage is wrong. You'd have to add flash + SRAM to get the right number.
Anyhow, looking at the map file to see where all that code is coming from, and playing around, I discovered, that the linker includes code that is definitly not used. How that? Tried to build a .lib in the hope that only required code is linked in, but failed. Demo version?
Also found functions that certainly aren't used by me. _FSqr, _FFloat, _log, _log10, _islower ... And no, I'm using the most simple version of printf.
Do I have to buy the Prof-version?
No problem with that, but I'd like to know in advance wether I can do the project. From that moment on, I'd use it frequently (something elder waiting to be ported to C, and new stuff...).
Any insights?
THX,
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Comments
There's nothing that the linker can do about this. As far as it is concerned, the extra routines are referenced, therefore they're used.
Having a command line or IDE switch to turn it on/off would be good, but I haven't found it yet.
I propose the switch to turn it on be called "USE_PROPELLER_TO_MANAGE_BANK_ACCOUNT_TO_7_SIGNIFICANT_DIGITS" or "YES_I_REALLY_NEED_LIMITED_PRECISION_FLOATING_POINT_INSTEAD_OF_SCALED_INTS" [noparse]:)[/noparse]
Buying the professional version will not help.
@Mike, ICC has those specialized small printfs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
As I wrote, I'm using the most simple lib for printf. No formaters, no float. Only decimals and strings. Barabone. "small, (int only, no modifier)". Also, I'm using no floats at all in my project. In the case of printf (if I *would* have used the one with floats) it's clear that float-stuff would show up in the map. Because it is referenced by printf, and there is (almost) no way to detect what format-strings printf will receive.
But code that isn't referenced (out of my own libs) should not generate code. If I comment the unused parts out, the size shrinks. I do not intend to wade through library-code to strip it down.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
You forgot to append "_POSITIVES_ONLY"
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I guess they do come from the "C Library Cog" that does handle low-level floating point routines. (As stated in the manual, look for "C Library Cog").
So a different non-float-c-lib-cog-code (we Germans are champions in building long words*)) would come handy.
Still leaves enough dead code ...
Different thing:
In my atempt to reduce code size, I came up with the following (albeit not working, but RSN) scheme:
Write some kind of "bootstrap" that is only a program that writes the binary image of all additional Asm-cogs code (like serial etc) into EEPROM (sure enough out of reach of the Prop code).
Then flash the real program. It only needs a I2C-driver (hacked this one smaller and added a C-interface).
Now load the code from EEPROM into some free storage and point to that area. For that I changed StartSerial to StartSerialFromImage that passes along a pointer to that area.
The problem I do have right now is that it try to reuse the memory the i2c-driver occupied (this code should no longer be needed after starting the i2c cog). This even works ... kind of ... the FullDuplexSerial is getting alive, but then the system hangs.
Any idea what my problem is? Well, I could temporarily allocate memory ... will try that.
Nick
*)"Donaudampfschiffartskapit
For focus, here is a snip from the summary post. It talks about reclaiming Spin space, but C can also benefit. I'm a fan of the "Baker Flush" option "E".
Here are some choices and comparisons (choice descriptions follow): Spin Code Spin Data Implementation/ Reclaimed PASM Waste/ COGs Choice Usable HUB For Loader Use Difficulty Spin Code KB Rewrites Wasted A.SL ~30KB-EE&Loader 2KB Easy Up to ~14K None None B.PHL 30KB 2KB Moderate Up to ~14K None 1 B2.PHL 31.5KB 0.5KB Moderate Up to ~15K None None C.PL 32KB-EE-loader Loader size Hard Up to ~15K All None D.APL 32KB-EE/4-loader Loader size-EE Hardest Up to ~15K Some? None E.BF 32KB None Moderate Up to 16K None None F.POS 32KB None Done Up to 16K None None G.NIL 32KB-PASM None Done None None NoneA. Spin-loader (SL)
1. Allocate 2K of HUB DAT for COG load space.
2. Spin includes EEPROM read (or other) code.
3. Spin loads HUB and starts each COG.
4. Spin uses 2K for Heap or other purposes.
B. PASM-HUB-loader (PHL)
1. Allocate 2K of HUB DAT for COG load swap space.
2. 2K HUB initially holds PASM loader.
3. PASM loader includes EEPROM read code.
4. PASM loads HUB and starts each COG.
5. Spin uses 2K for Heap or other purposes.
B2. PASM-HUB-loader (PHL) @Cluso99
1. PASM stub loader and COG load swap space in hub (target total <0.5KB)
2. PASM loader includes EEPROM read code.
3. PASM loads COG and starts each COG.
No other cogs used.
C. PASM-loader (PL)
1. Spin includes PASM loader.
2. PASM loader includes all loader/EEPROM read code.
3. PASM loads its cog-enumerated block.
4. PASM restarts itself.
D. Alternate PASM-loader (APL)
1. Spin includes Primary/Secondary role PASM loader.
2. Spin launches PASM loader on all COGs.
3. COG number (1 or 7?) determines PASM role.
4. Spin includes EEPROM read (or other) code. Spin = PASM/4.
5. PASM Primary manages Spin load of Secondary cog-enumerated blocks.
6. PASM Secondaries contains mem-copy and re-start command code.
7. PASM Primary loads and restarts itself.
E. Baker-Flush (BF)
1. Target program with API wrappers live in upper 32K.
2. Loader and all target PASM code boot normally.
3. One PASM section loads upper 32K to HUB and reboots Spin.
4. Target boots and can load one PASM driver.
F. Prop-O/S (POS)
1. Use Mike's Prop-O/S -OR-
2. Use another loader feature O/S
G. Do nothing
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Thanks!
Now it works! It came to my mind, that I do have a static buffer that isn't needed right at that early moment of startup. So I use it as a scratchpad.
Read from EEPROM (the first two bytes contain the length to be read) into that buffer and pass along to SerialStartWithImage.
Only need to write a nice little helper that keeps the images up to date on EEPROM. No big deal.
As I need the i2c anyhow, it's OK to be loaded. But it just came to my mind, that I could kick it out after reading all the setup-stuff from EEPROM. Don't need it anymore then.
If I only could find a way to read the i2c ASM from EEPROM.
Ummm ... the i2c in pure C might be smaller and is good enough for bootstrapping. I don't think I'll waste time with that idea.
About reclaiming the space from the I2C ASM, I'll read the thread ...
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Looking at the map-file, I see that there is debug-info included. About 7k in my case. Not as much as I intend to waste. Well, let's deselect that ... deselect ... can only compile with debug-info. But there's no debugger. Anyhow, I wouldn't need a debugger.
OK, change the make-file ... remove -g (= generate debug-info)... make ... remove -g ... the makefile seems to be made new at every make and re-append the "-g" option.
I'm not dumb, I'll call the make from the command-line with my modified .mak-file... doesn't work "Can't open $MyProject.mak". Am I dumb?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Post Edited (Nick Mueller) : 7/1/2009 5:58:23 PM GMT
--Rich
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Firstly, Nick, I'm not sure why floating point libs are being dragged in based on what you wrioe. If you can email me privately with some info, we will hash it out.
Second, generally speaking, in fact, I am adding support for unused function elimination right at this moment, first for the AVR and M8C compilers. Not sure when it will make it to the Prop compiler yet. PRO version only though and we need to put food on the table.
As for why should anyone battling with tools that are supposed to help. No one should. Our primary support is through email and I do go to various vendors' forum to check on things from time to time. However, in a high traffic forum like the Propeller, a post like this can come up and and get pushed down very quickly. Any case, Propeller is still a new tool, and there could be bugs or unintended interactions. It's best to email support @imagecraft.com or use our own mailing list (http://www.dragonsgate.net/pub/mailman/listinfo) on compiler specific issues. You'd get much faster response that way.
// richard
- the linker currently eliminates unused FILES (.o) from a library. So if you split your functions into multiple files, they would get eliminated.
- there is NO debug info presented in the code per se. Whatever you see is probably not debug stuff.
Please email me. Thanks.
// richard
In the map file, there are 3 sections:
.debug_info, size 0x1baf
.debug_abbrev size 0x2dc
.debug_line size 0xc76
If it's in the map-file, it should be in the binary. I also do have files ending with ".dbg"
Furthermore, in projects->Options->Compiler->Output Format, I can only select "Binary with Debug" and "Intel Hex with Debug".
I'll send you an eMail ...
Thanks,
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO