Why my code increased by 3K Words if....?

[E_Blue]

Why my code increased by 3K Words if the added code is about 570 Words?

I have a huge code, about 24K lines of C code; it uses USB CDC, 2 UARTs, ADC and all the timers I also have 2 small text tables(45*16 and 45*5) and one bigger that is 256*12 characters.

A that moment the code was 45473 Words

I just added 4 new items to each tiny tables and around 570(asm) new instructions.

So 4*5+4*16+570=674

Also changed 6 bra(asm code) to 6 goto, that adds 12 more asm instructions

674+12=686.

Now is 48484 Words.

Where came out the rest of the 3K Words?

PCH v5.091
_________________
Electric Blue

[temtronic]

hmm. depending on the PIC , maybe you've crossed memory boundaries ?

you might rearrange the sequence of functions. have seen that trick get rid of the dreaded 'out of ROM' message

you can also force code to be at a certain location.....

a dump of the listing ,before and after, would show you why, or at least where, the increase has come from.

[E_Blue]

Is a PIC18F67J50.

A dump means Disassembly Listing or the HEX?

Maybe is something relative or not but I have several Subroutines that has part of the code in ASM, one of them, after the update, give an error Branch out of range so that's why I changed those BRA by GOTO.
So I think that there something that get off the FLASH page.
_________________
Electric Blue

[temtronic]

OK, 'dump' , is the listing , the 'filename.LST' file that's created when you compile.Hay, I'm a dinosaur that started when Teletypes were THE terminal. Listing will show you all the code and WHERE it's located

the branch errors suggest a 'boundary' problem.

others that code more than me will know,but my gut says you're trying to cross a memory boundary.

[E_Blue]

The listing is a "mess" the code is not in order.

For example, a routine start at 0x5000 and the next is 0x1400.

I don't understand whats the logic behind that.
_________________
Electric Blue

[temtronic]

yeah, blame the CCS compiler for the order....I'm sure others know WHY it does it.....

but....

If you remember DOS6.22, there's a 'SORT.EXE' program ( long before 'app' was cool'....), that you input filename.lst and it'd actuall sort the listing by memory location

There has to be an 'updated' way to do the sort under Windows10. I kinda gave up when I found I can't run QB45 or other 'neat' programs on this PC...
It's one reason this dinosaur keeps old computers, stuff back then WORKED ! great tomorrow I have to pull out one of my 40 year old MODEL102 laptops and see if my programs are still in it !

[E_Blue]

Same with Orcad v9.1, it runs on 16bit, so is a no go in W10 X64.

I use a virtual XP machine to use that program.
_________________
Electric Blue

[Ttelmah]

Another thing that has not been mentioned is RAM.
This came up before. A programmer changed the order of a couple of
declarations,or added a very small extra declaration, and suddenly code
size jumped up. What had happened was that the tiny increase moved
values into the next RAM bank. Suddenly hundreds of bank switch operations
had been added.....

On the code order, this is common with most compilers.

Also though you need to remove the #NOLIST from the processor
definition file, or all the internal code won't be included in the final
listing.
One suspicion is that your maths has added a maths library not otherwise
being used, and this is being called from the code you have measured
the size of, hence the jump.

[E_Blue]

Thanks. I will check this because the RAM increased from 2412 Bytes to 2583 Bytes.

Now I finished the code and disabled part of the code that helps to debug via USB using #ifdef on certain parts of the code and this are the results

49136 no debug code
49032 with debug code

This has no sense for me.
_________________
Electric Blue

[temtronic]

maybe 'debug' uses common code ( a function ? ) to print to USB while 'nodebug' require each 'print to USB' to be hard coded ?

hay, I don't know.....but I was reminded I have SEVEN clocks to 'turn back' Saturday night....

[Ttelmah]

The compiler by default optimises for speed, not size.
What is happening is with the debug present some of the outputs
become large enough that the compiler starts to configure them as
subroutines, instead of 'inlining' them. Slower, but saves space.
With them removed they are small enough that it instead uses inline
versions.

[E_Blue]

The debug mode is not from the USB library, I made my own code.

The compiler works in mysterious ways.
_________________
Electric Blue

[Ttelmah]

Doesn't have to be from the library.
It is the result of the size of the called routines.
Imaging you have ten output calls. Each is fifty bytes in size. 500 bytes.
Provided there is enough ROM the compiler inlines them.
These then grow when you add the debug code to being 100 bytes each.
Total size 1000 bytes. The compiler therefore decides that size is becoming
more important than the ultimate speed, so instead creates a called
routine. This is then 100bytes, but each call adds perhaps 12 bytes of
overhead to setup the registers and actually create the calls. So size
is perhaps 220bytes. Result the code gets smaller. but a little slower.
The compiler is quite smart on this switch. It looks at the available ROM,
how big the total routine sizes are, and what speed can be saved.

[E_Blue]

Is possible to manually set the ROM/FLASH limit?

This code has 2 ways of compile, with an USB bootloader and without it.

So, I need to let some space, that's why I'm leaving 12K Words free.
_________________
Electric Blue

[Ttelmah]

Just use #build.
The one used when you build for the booloader will move the start
address uo to clear this. To build with the same space without the
bootloader, just build with the end address moved down by the
amount the booloader occupies.