C28x Legacy code warning

Cristian Bogus said:

I get the warning:

 "linking files with different page sizes, blocking may be incorrect"

 

1. Is there anything I could do to avoid this warning?

2. What to do to avoid the warning potential unpleasant consequences? An assembler directive of type .align 2 before the C24x code is enough ?.  What are the risks (for the pipeline, code execution, etc.)  of executing legacy code?

hmm the 24x and the 28x have different data page sizes.  The error sounds like the linker has detected two object files with mismatched data page size. Do you have any pre-compiled libraries in the project that could differ in how they were built? (24x compatible vs 28x native)?

Hi Lori,

Thanks for your reactivity. No, I do not have any c24x library. Besides even an empty file compiled with the -m20 option generates the warning.

The warning is related to the file:

>> warning: linking files with different page sizes, blocking may be incorrect
            (file
            'C:\\CCStudio_v3.3\\MyProjects\\eZdspF28335\\projects\\Debug\\ASM2407.obj')

The file ASM2407 is empty.

If you want to reproduce the problem you can add an empty file to a working project and then click on "File Specific Options" in CCS3.3 or "Properties" in CCS4.1.1 and select the C24x compatibility (option -m20).

Regards,

Cristian

Cristian,

Cristian Bogus said:

No, I do not have any c24x library. Besides even an empty file compiled with the -m20 option generates the warning.

The warning is related to the file:

>> warning: linking files with different page sizes, blocking may be incorrect
            (file
            'C:\\CCStudio_v3.3\\MyProjects\\eZdspF28335\\projects\\Debug\\ASM2407.obj')

The file ASM2407 is empty.

Double check under build options -> linker -> libraries.  Make sure there isn't something like rts2800_ml.lib included in the "include libraries" path.   If it is there, this library is built for 28x so It will conflict with -m20.

-Lori

Lori,

  The library under build options->linker-libraries->   is:    rts2800_fpu32.lib. Deleting the library does not remove the warning! Additionnaly I get the error message:

undefined                        first referenced
 symbol                              in file
---------                        ----------------
_c_int00

    Under these conditions I doubt that the project can work without the library. The C environnement appears to be initialised by the library (containing boot.asm + etc.) Besides the C28x is supposed to be able to mix C2XLP code with native code... If it is impossible to use the C28x native libraries... when importing isolated C2XLP functions there is definetly an undocumented problem with the code portability...

   Please note that the -m20 option is applied to a single (empty) file and not to the whole project. I cannot see how this can interfere with the libraries which are already object files. Moreover, the C2XLP code does not call functions from the library.

Regards,

Cristian

Cristian Bogus said:

undefined                        first referenced
 symbol                              in file
---------                        ----------------
_c_int00

Since this is an all assembly project you can change the auto init model to "no autoinitilization" to remove this error.   This option is under the linker tab, basic options.

I created a project with a single .asm source with 24LP code.  It built fine using codegen 5.2.4.  I've attached the project.   Hopefully it will help.

Regards

Lori

Lori,

Sorry if I was misleading. The project I'm working at is not an all assembly project.

It is a "real life" project containig C code, C28x assembler optimised code and legacy F2407A assembler code. I could not notice any problem in executing mixed C28x and C24x assembler code either on F2812 or F28335. But I do not know the potential consequences of the warning and what are the things I should lookout for.

Specifically the warning is fired for what reasons ? What are the "caveats" in mixing C28x assembly and F24x assembly with F28335 C code? I red the migrating instructions but I could not find something related to this warning.

Anyway thanks for the example project! It is interesting to see an all assembly project. Never tried before :-) !

Regards,

Cristian

Chris,

Cristian Bogus said:

Sorry if I was misleading. The project I'm working at is not an all assembly project.

It is a "real life" project containig C code, C28x assembler optimised code and legacy F2407A assembler code. I could not notice any problem in executing mixed C28x and C24x assembler code either on F2812 or F28335. But I do not know the potential consequences of the warning and what are the things I should lookout for.

I understand.  The warning is coming from having C28x addressing mode code in the same project as 24x compatible addressing mode code in the same project.  The 28x has a different page size than the 24x code.   I think that if you properly switch between the addressing using the

    .lp_amode
    LPADDR

    <24x compatible code>

   .c28_amode
    C28ADDR

     <return back to 28x code>

it will be ok, but I am going to check with the compiler team to see if there is anything else to consider.  The warning makes me think it may be the way the linker assigns variables to memory that is the concern.

Regards,

-Lori

The blocking flag is not honored when mixing C28x and C24x input sections into the same output section.  For example, if you have .bss sections from both C28x and C24x object files that have the blocking flag set and these sections will be placed in the same output .bss section, the blocking flag is ignored.  These input sections will not be blocked.  This is the reason for the warning.  I haven't researched why the linker was set up in this manner.  I do know this was a deliberate design decision to not support blocking in this scenario at least 6 or 7 years ago. 

Well,

I do not have separate .bss sections. As I told you in a previous message even an EMPTY file (no variables, no code) when compiled with the -m20 option generates the warning.

The (only) .bss section in the project is allocated like this:

.bss : > L4SARAM, PAGE = 1

where

L4SARAM : origin = 0x00C000, length = 0x001000

I do not see any alignement problem. Besides I'm practically not using the .bss. In order to preserve the data page information (the functions are in C+ native assembler+C24x assembler) the variables are declared in 64 words sections like:

CNTL_1b : > M0SARAM_2, PAGE = 1

where:

M0SARAM_2 : origin = 0x000040, length = 0x00040 /* 64w M0 SARAM */

I also tried to put the C24x in a separate program section (different from .text). Same warning. I also tried to put a ".align 2" directive before the C24x code without any success.

I realize that the decision to fire the warning was taken 6-7 years ago and some memories are lost forever... But this is becoming a QUALITY issue!!! Please just imagine explaining this situation to a custommer (automotive, avionics, transportation) ...

Is it correct to treat this warning as a linker BUG?

Regards,

Cristian

I don't think I explained the warning message as well as I could.  Sorry.  The warning is being generated by the linker as it is processing the input files.  Since the input section, a c24x object file (even an empty file), has a different page size than the final output file, a 28x .out file the linker is just outputting a warning that if the blocking flag is set in the 24x object file it is not going to be honored.  There is no attempt by the linker to do anything with a 24x blocking flag so the warning is there in case the 24x code is expecting say  a bss input section that must be blocked.  It isn't a matter of alignment but rather if for some reason a 24x section has to be contiguous within a page or, if greater than a page size, start on a page boundary this will not occur in the linker output.  But there is no analysis or processing done by the linker to try to duplicate the 24x blocking in some way in the final 28x output file. Another way to interpret the warning is that if you have 24x data and code that relied on 24x blocking, this will not work when mixing this code and data with 28x object files.  This linker does not attempt to identify in any way 24x data or code that has this condition, so a very general warning is output.

I think we need to update our documentation to say that any mixing of 24x object files and 28x object files will generate this warning.  If you are sure that there are no issues with blocking the warning can be turned off by adding the --diag_suppress=16024 switch after the -z linking switch.

Lori helped me by providing some additional information.  There are basically 2 ways to generate C28x object code, in terms of page size:

1. -v28 with C/C++ or C28x assembly: page size = 64

2. -v28 -m20 with C/C++, or C28x assembly, or C2XLP syntax: page size =128

When linking, if all source and assembly files are compiled with -v28, or situation 1 above, there will be no linker warning.  If all source and assembly files are compiled with -v28 -m20, situation 2, there will be no linker warning.  Combining source and assembly files from situation 1 and 2 will generate the warning because there are conflicting page sizes.  The page size could be an issue if you are relying on blocking for some reason as I described in the previous post.  Also, Lori pointed out another critical problem if you mix pages sizes.  If the generated code assumes a 128 word page and data is crossing page boundaries since mixing sets the default to 64 words, there will be missing DP loads.

Thomas, Lori,

Thank you for your input.

 In fact I tried to complie all the source with -v28 -m20 (Build Properties\C2000 compiler\Runtime Model Options, applying C2XLP for the whole project ). Before that attempt, when compliling the code I had 6 warnings in total with 5 of them related directly to TI code and 1 to the legagy code we are discussing right now. Now I get not less than 1113 warnings... :-)

The problem comes from the fact that  (following the -m20 option applied to the whole project) apparently the assembler expects that the C28x assembler sintax should be adapted to the C2XLP addressing mode. I get regularily the warning: "Expecting C2XLP adressing mode @@". Even a bigger problem is the warning is fired for the assembly code of the C files for which obviously the translation in the assembler language is done automatically by the compiler itself.

It appears that compiling C code with the -m20 option is not at all a good ideea. As I told you in a previous post my project has C code, C28x native assembly and C24x assembly.

The solution that appears to me the best is the solution I already apply:

    1.-reorganizing the C24x code for 64words data page size

   2. -compliling the C24x assembly code with -m20 (appling it locally to the assembly file, not to the whole project)

   3. -leaving the warning as it is or desactivating it.

  Do you see any issues with this solution (all the data is organised in 64 words pages for both C24x and C28x assembly code or C code) ?

Regards,

Cristian

No, that is the solution I would recommend.

ThomasS said:

No, that is the solution I would recommend.

Lori, Thomas,

Thank You for Your time!

As I am concerned, I consider this issue closed. 

Regards,

Cristian