How to optimize CW for ColdFire 6.3 code and compiler for MFC5307?

[Veter]

I am looking for compiler optimizations in CodeWarrior for ColdFire. Is there any way of getting rid of entries like that in s19 file?

S35100170FFB0000000000000000000000000000000000000000000000000000000000000000008D
S35100171047000000000000000000000000000000000000000000000000000000000000000000040
S351001710930000000000000000000000000000000000000000000000000000000000000000000F4
S351001710DF0000000000000000000000000000000000000000000000000000000000000000000A8
S3510017112B00000000000000000000000000000000000000000000000000000000000000000005B

I am using CodeWarrior Development Studio for ColdFire Version 6.3, Build 14. My target is MFC5307.

Message Edited by J2MEJediMaster on 2007-04-12 10:31 AM

[mjbcswitzerland]

Hi Veter

It looks as though the bss section is not being used - but I don't know of any setting to stop it being used. In fact I can not force such an effect with CW6.3.

It may be that the zeros you see are not zeroed variables but code. (for example from an assember file which is keeping a range zeroed).

I suggest looking in the map file to see whether the address range is in code or in variable initialisation space. Maybe you can identify it's variable or constant name to find where it comes from. Once you know which variable array or const array it is, or whether it is code, you can possibly find an approprate way to control it.

As I said before I couldn't force the compiler to generate such code - however hard I tried!!

Regards

Mark

[Veter]

Mark,

my flashcode section starts at 40010 to D867C

next my sdram "flashdata" starts at FE000410 to FE5C4E50

the flash data includes "rodata,data,bss,COMMON" sections.

could it be my link command file?

Please see attached command file and map.

Thank you Mark!

mainboard.lcf1.txt

mainboard.elf.xMAP1.txt

Message Edited by t.dowe on 2009-10-15 01:22 PM

[mjbcswitzerland]

Hi Veter

I am not absolutely sure but I think that the variable data for the sdram are in FLASH and are copied on initialisation to their position when operating. I think that the following shows this:

FE000410 000D86C4 005C9D04 .flashdata sdram

5.9M data beginning at 000D86C4 are to be copied to their final destinations beginning at FE000410.

I suppose that the object "TheBottleInventory", with a size of 5,26Meg will be at the location you showed in the SREC.

FE06389A 00522F7A .bss TheBottleInventory (BottleInventory.cpp)

This is in .bss so should be initialised to zero. Therefore it seems really as though it should not be filling the flash with code. How many lines do you actually have with 00? It would be HUGE!!

Perhaps someone else can explain how to get rid of this since I couldn't get it to happen here. I have the optimiser set up to max optimisation with optimise for size - you could verify that but I would think that this would be performed also without any optimisation enabled.

Assuming that my analysis is indeed correct then it is not code but really zeroed variables and so look around for anything which allows .bss really not to have a copy in FLASH.

Good luck

Regards

Mark

[CrasyCat]

Hello

You need to adjust your linker file and define separate output sections for initialized and un-initialized code.

Please check how it is done in .lcf file from stationeries.

I would write:

  .flashdata : AT( ADDR(.flashcode) + SIZEOF(.flashcode) )
  {
  __DESTINATION = .;
    *(.text)
    *(.rodata)
    *(.init)
    *(.fini)
    *(.eini)
    *(.constdata)
    *(.bootcode)
    *(.bootdata)
    . = (.+15) & ~15;
   
    *(.data)
   
    ___sinit__ = .;
    *(.sdata)
    *(.sdata2)
    __SDA_BASE = .;
  } > sdram
    
 .bss :
 {
    __START_SBSS = .;
    *(.sbss)
    __END_SBSS = .;
   
    __START_BSS = .;
    *(.bss)
    *(COMMON)
    __END_BSS = .;
    
__exception_table_start__ = .;
EXCEPTION
__exception_table_end__ = .;
   
  } >> sdram
  ___SDRAM_END = .;

That will generate in the final .elf file a section  .flashdata that needs to be copied from ROM to RAM at startup and a section called .bss which do not need to be initialized from ROM.

In that case content of .bss should not appear in .s19 file.

CrasyCat

[Veter]

CrasyCat,

That didn't do it, for .bss got copied to sdram again with initial zeroes.

Should I just remove sbss and bss from the sdram?

[CrasyCat]

I have tried locally on a small project created from a stationery.

Defining .bss as I propose did not add any data with value 0 in the S record file for section .bss.

Now are you looking for a way not to initialize .bss at all?

CrasyCat

[Veter]

I think it has a vairable array that when inserted into sdram initialized to 0.

May be by removing .bss from lcf ( I can just create section called ".bss : {}" ) it will prevent copying of this array into sdram.

Do you know of any negative impact that this may cause?

Thank you!

[mjbcswitzerland]

Hi Veter

If you are sure that it is an array (BottleInventory[SIZEOFDATA] = {0} ?) then perhaps you could get this from heap so that the compiler (linker) is no longer involved.
Eg. on initialisation:

unsigned char *BottleInventory = 0;

BottleInventory = malloc(SIZEOFDATA);
memset(BottleInventory, 0, SIZEOFDATA);


This way you are guarantied to have the zeroed array which you require and the linker will any add one pointer to the download file.

Obviously it doesn't solve the issue with the linker but at least it results in a efficient downloadable without having to find out why the linker is behaving as it is.

Regards

Mark

P.S. My experience has been that zeroed arrays are put int the bss section whereas non-zeroed arrays are copied from FLASH (absolutely normal). However I have found that also non-zero arrays declared as const are handled the same way (that is copied to RAM for exectution). Strings can be kept in FLASH for execution by using the following pragma: #pragma const_strings on
I haven't found a corresponding method to keep the const data out of RAM.

[CrasyCat]

Hello

As far as I can tell if you define a constant as follows

     const int cst = 0x45;

it will be stored in section .rodata.

If in your .lcf file you specify you want to place .rodata in flash (together with the application code), constant value should not be copied over to sdram.

Am I missing something here?

I am assuming you are using CodeWarrior for Coldfire V6.3 here.

CrasyCat

[Veter]

Yes, I'm using CodeWarrior for ColdFire V6.3.

I am trying to convert *.dld (link command file used by DIAB)  into *.lcf.

Unfortunately this effort proves quite difficult.

My memory map is all confused, and resulting *.s19 file contains large amount of memory initialized to 0 and located in the .bss section.

please see attached files.

mainboard_elf_xMAP1.txt

mainboard_dld1.txt

mainboard_lcf1.txt

Message Edited by t.dowe on 2009-10-15 01:21 PM

[CrasyCat]

Hello

In one of my earlier post I recommended you to split the output section .flashdata and to place bss data in a separate output section.

This has not been done in the .lcf you sent over.

Can you please do the modification and relink?

BSs data should then be removed from the S record file.

CrasyCat

[Veter]

I know you said that.

I did as you said and it did not make any difference.

The zeros from bss were in sdram.

S319FE0BAF6EFF5A243CCE80000020016000FEBA243C4E80000052
S319FE0BAF82202E000C6000FEA80000000000000000000000004C
S319FE0BAF96000000000000000000000000000000000000000098
S319FE0BAFAA000000000000000000000000000000000000000084
S319FE0BAFBE000000000000000000000000000000000000000070

mainboard_lcf1.txt

Message Edited by t.dowe on 2009-10-15 01:18 PM

[mjbcswitzerland]

Hi CrasyCat

I am using CW6.3 for Coldfire and GCC - they are very similar but I will have to check this again to be absolutely sure - I do remember that originally all strings were being copied to SRAM and taking up quite a lot of space but could be solved with the pragma (definitely CW6.3).

When I get the chance I will check to be sure about the .rodata and inform if there is an issue. Otherwise assume that all is well when using .rodata correctly.

Regards

Mark

[Veter]

You suggested to use following declaration:

unsigned char *BottleInventory = 0;
BottleInventory = malloc(SIZEOFDATA);
memset(BottleInventory, 0, SIZEOFDATA);

BottleInventory is a class that has an array and other members.

The class itself has variable that returns instance of this class:

//
// Declare a single instance of bottle inventory and an accessor to return it
//

BottleInventory TheBottleInventory;

BottleInventory * Inventory() { return &TheBottleInventory; }

This instance is the one that causes zeroes in the .bss section and has size = 00522F7A.

Do you think I should declare it as:

BottleInventory TheBottleInventory = malloc(sizeof(BottleInventory));

memset(TheBottleInventory,0,sizeof(BottleInventory));

Please advise.

[mjbcswitzerland]

Hi Vetter

I think that you can declare a pointer to an array rather than the array itself in the object and then set this pointer to the memory block of the required size allocated by using malloc. You will just have to ensure that malloc has a heap large enough to be able to return the large block size. The heap size is also specified in the lcf file.

Although it doesn't solve the mystery of why this array is appearing as zeroed FLASH values it will certainly remove it from the SREC since the array and its size is unknown to the linker

Regards

Mark

[Veter]

On the other hand, since .bss contains uninitialized data may be I should not copy it into sdram:

.flashdata : {... *(.bss) ...} > sdram or .bss{...*(.bss) ...} > sdram, just simply omitt the entire statement.

Isn't it true, that uninitialized data is not or should not  be included into s19 file?

[CrasyCat]

Hello

You are right bss data should not be included in S record file.

There might be something with your project settings.

You need to submit a service request  for that to get one of our support engineer looking into that

Click here to submit a service request..
 
Make sure to attach  a project reproducing the issue and installed product information to the SR.

To make sure you provide all necessary project information, you can use the Pack and Go wizard.

  - Start the IDE

  - Open the Project

  - Select Help -> "Pack and Go"

  - Follow the instruction on the screen. That will generate a zip file containing all necessary

    information (including the installed product information).

CrasyCat

[CrasyCat]

OK I did not know you were using GCC.

I have no clue how GCC manages constants.

On CodeWarrior front I am only aware of a potential problem when the constant is initialized with value 0.

Per default if you define the constant as follows:

const char myConst = 0;

the constant will not be allocated in .rodata, but in .bss.

To get the constant allocated in .rodata, you need to use the pragma

#pragma explicit_zero_data on

Not sure that helps, but just in case 

CrasyCat