Relocatable label expressions not usable in standalone assembler of powerpc-eabivle-gcc 4.9.4 when configured for automatic Book E to VLE instruction translation

cancel
Showing results for 
Search instead for 
Did you mean: 

Relocatable label expressions not usable in standalone assembler of powerpc-eabivle-gcc 4.9.4 when configured for automatic Book E to VLE instruction translation

447 Views
qwertyu
Contributor I

I am trying to reuse multiple assembler source files that have been written originally for the CodeWarrior toolchain. By passing the command line options "-vle" and "-ppc_asm_to_vle" it is possible to let the CodeWarrior toolchain automatically convert code written in Book E to VLE mode. Additionally, the same assembler source can be used unmodified to translate the assembly in Book E mode directly by not specifying the above command line options. This behaviour makes it possible to reuse the assembler source files in multiple projects even when they have different requirements regarding Book E or VLE mode usage.

I am looking for a way to achieve the same flexibility of translation either for Book E or VLE mode with the GCC toolchain provided in S32 Design Studio. The command line options "-mvle" and "-Wa,-ppc_asm_to_vle" seem to be the equivalent for the features provided by CodeWarrior. However, the automatic translation from Book E to VLE seems to just not work on some instructions (even for some that have been specified in the latest release notes document of S32 Design Studio).

The non-working translation is especially problematic for all instructions that might be used together with something called "relocatable label expressions" (naming according to the CodeWarrior documentation) because I need them very often. Typically such instructions end on "@ha", "@h" or "@l" which allows to get either the upper or lower 16-bits of an address/label or a value that has been specified before. But this does not work with the standalone assembler of the GCC toolchain even when "-mvle" and "-Wa,-ppc_asm_to_vle" are given.

Here is an example code that is never working:

        lis         r10, object@ha
        addi      r10, r10, object@l
        lis         r10, value@h
        ori        r10, r10, value@l
        lis         r4, object@ha
        lwz       r5, object@l (r4)
        lis         r4, object@ha
        stw       r5, object@l (r4)

Typical errors that I receive for the above code are:

"Error: syntax error; found `@', expected `,'"

"Error: junk at end of line: `@ha'"

"Error: junk at end of line: `@h'"

"Error: junk at end of line: `@l'"

It is possible to fix this by writing everything of the above code sample in VLE mode only.

Here is an example code that is always working (because it has been manually written in VLE mode):

        e_lis         r10, object@ha
        e_add16i  r10, r10, object@l
        e_lis         r10, value@h
        e_or2i      r10, value@l
        e_lis         r4, object@ha
        e_lwz       r5, object@l (r4)
        e_lis         r4, object@ha
        e_stw       r5, object@l (r4)

However, this defeats the whole purpose of the automatic conversion from Book E to VLE instructions because the assembler code is not reusable for Book E and VLE mode projects anymore.

I am using the latest release of the GCC toolchain according to the version output:

powerpc-eabivle-gcc.exe (BLD = 1607) 4.9.4 20160726 (build.sh rev=gceb1328 s=F494 -i /opt/freescale ELe200 -V release_gceb1328_build_Fed_ELe200_ML3)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Is there any possibility in the current GCC toolchain version to make the relocatable label expressions usable together with automatic Book E to VLE mode translation? Or is this something that is not supported right now? Thanks in advance.

Labels (2)
0 Kudos
2 Replies

205 Views
alexanderfedoto
NXP Employee
NXP Employee

I recommend you to not rely on translation from BookE to VLE feature implemented in current GCC toolchain.

You'd better to have explicit assembler code in you sources over which you have control. You can wrap up  VLE assembly code by _VLE_ macro in the same .S file. Thus assembly file will be preprocessed at first and then compiled.

0 Kudos

205 Views
qwertyu
Contributor I

Hello Alexander,

I am aware that the GCC toolchain provides specific preprocessor symbols that would indicate if a file is being translated for Book E or VLE mode.

Unfortunately, the CodeWarrior assembler seems to lack many preprocessor symbols or pragmas that are normally provided by the CodeWarrior compiler. According to my experience and the CodeWarrior documentation this is also the case for the selection of Book E or VLE mode translation (there is no equivalent symbol to "__VLE__" provided by the CodeWarrior assembler). Therefore I resorted to application dependent usage of the CodeWarrior options "-vle" and "-ppc_asm_to_vle" to allow using both translation modes with the same assembly source code as necessary. This works mostly unproblematic for all relevant instructions (only some minor exceptions).

Using the "__VLE__" preprocessor macro would require to basically rewrite every line of assembly code for Book E or VLE mode conditional compilation. The source files would get much larger and the readibility would be drastically reduced when compared to now. So this seems to be not an appropriate method when such a translation issue could and should be handled by the toolchain itself. A toolchain is also able to optimize the resulting VLE code size which is not possible with manual coding where you have to use the "biggest" instruction variant always (e. g. to avoid unpredictable linker errors).

Do you know if it is planned to extend the Book E to VLE mode translation support in the GCC toolchain in the future or not?

0 Kudos