Huge main() - Why?

[bgpartri]

Below is the asm listing for my main(). It is listed in statistics as taking up 2900 bytes. What is going on here?

There must be something going into main that I just don't understand. Global variables maybe? I have some big float arrays.

I am trying to optimze my program, and would like to know where to start with this routine.

wake_up_init() is listed as taking 36 bytes, and time_calculations() shows 3106 bytes.

Its a 18F452 and I am using 3.180 at the moment.



.................... void
.................... main ()
.................... {
*
6C14: NOP(FFFF)
6C16: CLRF FF8
6C18: BCF FD0.7
6C1A: BSF 0D.7
6C1C: CLRF FEA
6C1E: CLRF FE9
6C20: MOVLW 06
6C22: MOVWF FC1
.................... int8 i, j;
....................
.................... init ();
*
7788: MOVLB 0
778A: GOTO 3618
.................... while (TRUE)
.................... {
.................... if (just_woke_up)
.................... {
778E: BTFSS 24.7
7790: GOTO 779C
.................... wake_up_init ();
7794: GOTO 3A90
.................... }
.................... else
.................... {
7798: GOTO 77A0
.................... time_calcultions();
779C: GOTO 5FF2
....................
.................... } // if (just_woke_up){
.................... } //while
77A0: GOTO 778E
.................... }//main
....................

[PCM programmer]

Your .LST file will give separate values for RAM and ROM usage.
It will show something like this:

[bgpartri]

Thanks. I'll look at that info.

Unfortunately, I think I have to use floating point.

I'm using expressions like exp(-(ln(2)/halftime[i]*time). Two of the floating point calculation routines take up half of the memory. 300 lines of a 4000 line program take up half the memory because of the floating point calcs.

Its a pretty common expression used to track everything from cooling to radioactive decay. I think that if it could be simplified, someone would have done it by now.

Although I'm sure its possible to do all of these calcs in int32, it seems like a big job Basically, I'd have to understand the calculations to the level of the compiler writer which kind of defeats the purpose of using a high level language.

And if I understand it correctly, I would have to get rid of EVERY float divide (for example) to get rid of the float divide routine.

[SherpaDoug]

Can you use exp() and ln() in base 2? Then you can use shifting instead of floating point functions. I have done a quick-and-dirty linearizing of a thermistor by counting how many bit shifts it takes to make the A/D reading zero. It turned a non linear 12 bit reading into a fairly linear 4 bit one.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Guest]

Yes, I can use base 2 probably. I have certainly seen the log as a base 2 for this expression.

I will look into this more.

But I am still of the opinion that I will have to get rid of EVERY float number to get rid of the float routines. I think it will be very hard to get rid of all of the float.

[SherpaDoug]

Try commenting out the lines that use exp() and ln() and see how much the ROM size is reduced. That will tell you if it only loads part of the floating point library. I expect it does.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[bgpartri]

It looks like this is going to be too valuable in terms of speed and ROM space to ignore, so I have started converting.

I have identified a bunch of chunks that can be converted relatively easily, so I will start with those.

That in itself will start to improve the code. Just getting rid of my two uses of ceil() saved about 1k!

Commenting out uses of ln() and exp() definitly reduces the code size. But that is also probably the hardest to convert. There is some low hanging fruit, so I will go after it first.

But I am also trying to figure out how to get rid of some of the 4K of main. I still don't know what I will have to do to reduce that.