Code Size issue - can ansibfm.lib be pared down or replaced?

[photoman]

HI, I am developing an application on an MC9S08DZ128 and have run out of user code space.  My user modules are 42793, generated code is 5450, and Libs is 58481 bytes. The only entry under "Libs" is ansibfm.lib (58481 bytes in size). 

First of all, what is this library (I find very little documentation on it on the web).  Is there an alternative library I can use that will support floating point (How do I switch the libraries?)?  Or can I take functionality (size) out of this library at compile time using options in Codewarrior? 

This library just seems huge.  There has got to be an alternative, especially needed for those using processors with 32k flash.

Does anyone have any hints or tricks for paring down code?

I am using version 6.3 of Code Warrior (Classic IDE, Basic Edition).

Thanks very much for your help.

[tonyp]

This seems to be the floating-point library, which you may not need at all as most things can be done with integer math.

I cannot offer any advice on the CodeWarrior libraries as I don't use CW but the sizes you mention are obviously far below the total capacity of the 128K chip.  The page size, however, is only 16K.  So, I suspect you need to break up (if possible) the loading of these libraries to occur in multiple pages instead of just one (which would justify the error you're getting).  In other words, it seems this is a mapping problem, not a size one.

Hope this helps.

[photoman]

Thank you Tony, yeah, that's a floating point library, but I need it because of some floating point math being performed in IEEE 754 format.  As you said, though, I could do this in integer math, but this would take a major rewrite.

Actually, I am near the capacity of the 128k chip.  42.8k+5.5k+58.5k = 107.1k.  I was sitting at 110k when I got my link errors that told me I was over size (Link Error : L1102: Out of allocation space in segment ROM2 at address.....[something]) before I optimized some code.  Data size is currently 4k, so add that to the sum and the total = 111.1k.  The register memory mapping of the processor takes up the remainder of the memory I believe.  My .map and .prm files look correct from what I can tell, i.e. I am using the full paged memory of the processor (although I don't quite understand why PPAGE=3 is not available to be used, just that it is combined with another memory block.  FYI, I am using a bootloader (AN2295), which further makes this a problem (although the size of the bootloader is small).   To address your 16k paged statement (break up files), I'm pretty confident that processor's MMU manages that seamlessly.

Back to my original question, I'm hoping other developers can give advice to choose a smaller library that still allows floating point with my processor (MC9S08DZ128), somehow defeature the ansibfm.lib, or some other tip or trick to reduce the library size (compile time options, etc).  

[giacomopetrini]

My suggestion is to not spend time trying to reduce the library (or find an alternate library), but spend the time trying to eliminate the floating point math in your code.

Very often FP is not really needed, it's just easier to use than integer math...

Bye Jack

[markkurönö]

You can rebuild the standard library. I'm not sure how much can be trimmed by compiler options, but that is probably the way to try.

I don't have CW Classic for S08, but CW for S12X has the library project at <install_folder>/lib/hc12c/. There's a project file for (re-)building the library, and a readme file that explains the options used for the prebuilt library versions.

[tonyp]

(First of all, I'm sure others who've used the same library will possibly be able to help more in this regard.)

OK.  128KB is all Flash and is all available for your app -- so, you still have plenty of room left.  (What hides behind registers, for example, is accessible as paged memory.)

PPAGE3 simply happens to be the same as the highest 16K of the directly addressable 64K (non-paged), and because it has to hold your apps vectors (etc) it's best not to be used for paged code.  (You could if you wanted -- at least from assembly language.)  You ISRs have to go to non-paged, although you could CALL functions in paged memory from within them.

The processor's MMU will not do anything to manage your app -- it's 'your' job to organize your app into pages.

However, your C compiler might.  But whether it's smart enough to split large libraries in multiple pages correctly I don't know.  I suspect it won't -- at least not automatically.  The reason is that CALLed (paged) functions may depend on local (BSR/JSR called) subroutines.  Reshuffling paged functions, if not done correctly, will break those dependencies.

But, anyway, somebody who knows CW's 'skills' will be able to answer this better.