Avoiding libs

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Avoiding libs

3,168 Views
BAN
Contributor II
Hi!
 
In my project I'm trying to separate two code blocks as much a possible and this is done by not sharing functions between the blocks. This is easy to fulfill in the C code but the compiler sometimes decides to use lib functions as _FPCMP and _LCMP from ansibi.lib, out of my control. Is there any way to avoid these function calls and force the compiler to use them as inline functions??
 
//BAN
Labels (1)
Tags (1)
0 Kudos
7 Replies

848 Views
fleik
Contributor I
Hello Ban,
It's simple to separate areas of code using the linker and the #pragma command... here's how it works:
in the linker you can create and seperate different segments:
SEGMENTS /* Here all RAM/ROM areas of the device are listed. Used in PLACEMENT below. */
            APPCODE              =  READ_ONLY   0xC000 TO 0xEFFF;
            BOOT                     =  READ_ONLY    0xF000 TO 0xFF2F;
END
//and then you select what code is placed where:
PLACEMENT
          DEFAULT_ROM, ROM_VAR, STRINGS       INTO  APPCODE;
          BOOTCODE                                                  INTO BOOT;
END
 
once this is set, code will be placed by default into the appcode area, but anything that you want to be placed into the boot code should have this before the function:
#pragma CODE_SEG  BOOTCODE
void function(void){}
and once you want to return to the app code, return it to the default value:
#pragma CODE_SEG DEFAULT
 
 
This same principle also applies for RAM(DATA_SEG) and constants(CONST_SEG)
 
fleik
0 Kudos

848 Views
CompilerGuru
NXP Employee
NXP Employee
Hi Ban,

Which cpu are you targeting? S12? S08?
It's not possible in general. Optimizing for speed may use less runtime calls. There is also a message which can be set to a warning with #pragma MESSAGE so you don't have to look for runtime calls but the compiler tells you.

Why do you split up your application into two parts? If it is in order to implement a loader and a application which can be replaced at runtime, then I would suggest to split up those two separate pieces into separate elf files/build targets/applications to make 100% sure changing the application has no effect whatsoever on the loader. This way the interface between the loader and the application (entry point, interrupt handlers) have to be explicitly managed, but I think that has to be done actually anyway in the "single ELF for loader and app" setup case.

I remember that there were some threads with this subject in the past in this forum.

Daniel
0 Kudos

848 Views
BAN
Contributor II
Hi Daniel!
 
My target is S12 and you are quite right, I'm trying to split the code into a laoder and application part.
 
We have also considered to split them into separe targets but thought that this will make it impossible to debug the application in the debugger. Maybe it's not a problem, we just don't now the trick.
 
Do you remember when the threads covering this subject where active?
 
 
//Bengt ANdersson
0 Kudos

848 Views
Lundin
Senior Contributor IV
There is a compiler option ""Create sub-functions with common code". If you disable this, I think you will get rid of those functions entirely.
0 Kudos

848 Views
CompilerGuru
NXP Employee
NXP Employee
Actually that is a different topic, that is a compiler optimization which only changes the internals of a function. Disabling it can help quite a bit to easy debugging, but the compiler will use runtime routines independently of this.

A note to debugging a loader and an app at once. I always thought that once the loader works fine, you would never ever change it and there should not be much to debug. A few assembly instructions at each interrupt entry for the redirection maybe, but in the end the app code and the loader code should be quite separate.
However with the most resent HC12 tools (V4.7) it is now possible to load the debug information from multiple elf files. I never used it (needed to use it). Here's the snippet from the release notes of 4.7.

>List of new Features
>--------------------
>- Added support for loading multiple executable files and symbol tables
> (additional option ADD_SYSMBOLS in LOAD command).
>  Only the entry point of the first loaded file will be used to initialize the program counter (PC).

Here's a thread which matches the subject (its about HC08, but its the same topic)
http://forums.freescale.com/freescale/board/message?board.id=CW816COMM&message.id=2144

Here's another one which might be of interest.
http://forums.freescale.com/freescale/board/message?board.id=16BITCOMM&message.id=441

http://forums.freescale.com/freescale/board/message?board.id=CWCOMM&message.id=1220
http://forums.freescale.com/freescale/board/message?board.id=CW816COMM&message.id=2149

Daniel
0 Kudos

848 Views
BAN
Contributor II
For the moment the interrupt handling feels tricky for me. Can you give me some further explanation to your expression "A few assembly instructions at each interrupt entry".
 
//Bengt   
0 Kudos

848 Views
BAN
Contributor II
Hi!
 
I tried the "Create sub-functions with commn code" option immediately but without success.
 
Do you know if there are any useful Application Notes for this subject??
 
//Bengt
0 Kudos