CW10.6 inline assembler issue

[homeness]

Hi,

I have found that CW10.6 calculates inline assembler expression as if it is C expression.

int* pointer;

__asm__ void func()

{

     lea pointer+1, a0

     ...

Here a0 loaded with address of pointer + sizeof(pointer)... but CW5 things that 1 here is 1 byte.

Is this a bug or a feature?

Thank you,

Peter

[trytohelp]

Hi Peter,

What is the architecture ?

Do you refer to an older version ?

      which one ?

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[homeness]

Hi Pascal,

The architecture is CF5282. We are migrating from CW5.1.2 to CW10.6.

Thank you,

Peter

[trytohelp]

Peter,

I've created an example under CW for Coldfire V5.1.

Extract of source file:

+++++++++++++++++++++++

#include <stdio.h>

int* pointer;

asm void func(void)

{

lea pointer+1, a0

nop

rts

}

int main()

{

    printf("Hello World MW in C\n\r");

    fflush(stdout);

    func();

    while(1);    // Idle

    return 0;

}

+++++++++++++++++++++++

disassembly code with V5.1:

+++++++++++++++++++++++

;	9: int* pointer;

;   10: 

;   11: asm void func(void)

;   12: {

;   13: lea pointer+1, a0

;

0x00000000	_func:
;	func:
0x00000000  0x41F900000000	lea	_pointer+1,a0

;

;   14: nop

;

0x00000006  0x4E71

nop

;

;   15: rts

;   16: }

+++++++++++++++++++++++

disassembly code with MCU V10.6

+++++++++++++++++++++++

;   15: int* pointer;

;   16:

;   17: asm void func(void)

;   18: {

;

;   19: lea pointer+1, a0

;

0x00000000                    _func:

;                             func:

0x00000000  0x41F900000000           lea      _pointer+4,a0

;

;

;   20: nop

;

0x00000006  0x4E71                   nop     

;

;

;   21: rts

+++++++++++++++++++++++

It seems to be the same generated code.

Pascal

[homeness]

Hi Pascal,

The code is the same but we don't see real addresses of pointer+x because this disassembly is non linked code. We see only placeholders (00000000) for feature addresses.

Best regards,

Peter

[trytohelp]

Hi Peter,

I got feedback from compiler team.

+++++++++++++++++

I don’t think there is a standard way to consider this as the inline assembly code is compiler specific and it is not guided by a particular standard.

It all stays in how the compiler evaluates the inline assembly expressions (C standard expression evaluation rules do not necessarily apply for inline assembly expressions):

• in the first case, ‘pointer + 1’ most probably is evaluated to ‘(&pointer) + 1’
• in the second case, ‘pointer + 1’ seems to be evaluated to ‘&(pointer + 1)’ which is equivalent to ‘(&pointer) + sizeof(pointed_type)’

If the user expects to have the same behavior from V5.1 in MCU 10.6 the code should probably be rewritten as:

lea (char *)pointer+1, a0

+++++++++++++++++

I've checked it on my side and it's working:

;  15: int* pointer;

;  16:

;  17: asm void func(void)

;  18: {

;

;  19: lea pointer+1, a0

;

0x20000C98                    _func:

;                            func:

0x20000C98  0x41F92000A508          lea      ___global_destructor_chain,a0

;

;

;  20: lea (char *)pointer+1, a0

;

0x20000C9E  0x41F92000A505          lea      _pointer+1,a0

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[homeness]

Hi Pascal,

We would like to use the same sources for using with both compilers and the type casting is not suitable for the old CodeWarrior.

Now we are using __MWERKS__ macro... what is the first version of the compiler when the behavior is changed?

Thank you,

Peter

[trytohelp]

Peter,

Difficult to say.

In the compiler release note I don't find something about that.

There are some points (bug fixed) for the Inline but nothing really the pointer allocation.

May be the change was introduced by something (new feature, bug fixed, etc ...).

Version in V5.1:

Version 5.0 build 00023

Version in MCU V10.6:

Version 6.0 build 3024 (build 3024)

I've several versions installed on my side.

The changed was introduced in the CW for MCF V7.2.

Before this version the pointer was defined as V5.1.

The compiler version was Version 6.0 build 50 (build 50)

With the previous version V7.1 the code was same as V5.1.

the compiler was Version 5.2 build 26 (build 26).

It seems the changed was introduced when the compiler Version 6.0 was used instead of V5.x.

Below the list of compiler improvements:

===============================================================================

Fixed Issues

===============================================================================

- fixed inline assembly parameters symbolic debugging information generation

- fixed a problem with mac with load, generates the same pattern as macl

- fixed a problem with directive 'entry', wasn't recognized anymore

- fixed a problem with asm error messages displaying mangled names

- fixed a problem with loop invariant hoisting optimzation

- fixed a problem with replacing redundant function calls with indirect calls

- fixed pragma scheduling on | off | reset

- fixed inline assembler problems with CAU, divs and rems

- __declspec(interrupt) wasn't implemented as documented in the preview release

- section .debug_arange header is padded to a double address size

- elf section header string table reuses entries

- dwarf locations for debug_frame and variables are inlined when possible

- tight loops (bysy wait) span over 4 bytes to allow BDM accesses

- overload functions and mutiply defined functions cannot use CodeSmart

- fixed the default data model to farData for the commmand-line tools

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[trytohelp]

Hi Peter,

I've disassembled the .elf file and got:

For V5.1

....

83

0x20005288  0x00000004  GLOBAL  OBJECT  0x00

DATA

_pointer

....

;	9: int* pointer;

;  10:

;  11: asm void func(void)

;  12: {

;

;  13: lea pointer+1, a0

;

0x20000500	_func:
;	func:
0x20000500  0x41F920005289	lea	0x20005289,a0

;

For MCU V10.6

....

11

0x2000A504  0x00000004  GLOBAL  OBJECT  0x00

.bss

_pointer

....

;  15: int* pointer;

;  16:

;  17: asm void func(void)

;  18: {

;

;  19: lea pointer+1, a0

;

0x20000C98                    _func:

;                            func:

0x20000C98  0x41F92000A508          lea      ___global_destructor_chain,a0

++++++++++++++++++++++++++

In V5.1, the pointer 0x20005288.

the size of int pointer is 4.

pointer+1 gives 0x20005289

In MCU v10.6, the pointer 0x2000A504

the size of int pointer is 4.

pointer+1 gives 0x2000A508

I think I see what is the problem.

I need to contact the compiler team about that.

Keep you informed.

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[trytohelp]

Hi Peter,

Do you use CW for Coldfire V5.1.2 or a version using the IDE V5.1.2 ?

Coldfire V5.1 is an old version released more than 10 years ago.

Now you've migrated to the MCU V10.6 which is the last version.

I will re-install the V5.1 and will perform some tests on my side.

Keep you informed.

Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------