• Locked Locked
  • Replies 13 replies
  • Subscribers 118 subscribers
  • Views 9697 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARM Vs GCC assembler

Gerald Murphy
Note: This was originally posted on 25th January 2013 at http://forums.arm.com

Hi,

I have a question regarding the ARM and GCC assemblers i.e. ARMASM and GAS.

MOV.W R4,#0x87C0 is translated to F248_74C0 by ARMASM.

However, GAS throws up the error "invalid constant (87c0) after fixup" for the same instruction. Why does GAS give an error for this?

I realise the operand is 16-bit but I'm using the '.syntax unified'. I thought GAS supports .W and .N suffixes. Even without the .W suffix, GAS gives the same error whereas ARMASM quietly expands the 16-bit instruction to 32-bit.

I'm using 'GCC version 4.7.2 (Sourcety CodeBench Lite 2012.09-63).

Any insight as to why GAS is giving an error is appreciated. The workaround is to use two instructions. The following 2 instructions compile OK.

MOVW  R4  ,#0xC0
MOVT R4  ,#0x87

Thanks and regards,
Ger
Parents
  • Note: This was originally posted on 13th February 2013 at http://forums.arm.com

    All of your assertions look correct to me. Just a minor correction on a possible misunderstanding - the 32-bit Thumb-2 instructions are not like the 32-bit ARM instructions. It's a different sort of encoding with slightly different assembly level capabilities too, hence why the unified language is a subset of both.

    About the PC offset.. I don't know for sure, but something I do know is that even the big A-series processors with much longer superscalar pipelines still have the same PC semantics as the original 3-stage ARMs. Meaning that it's no longer a reflection of how the pipeline works but something that has logic to fake it in order to maintain compatibility.

    Cortex-M series processors don't have the traditional ARM instruction set so they don't have to worry about compatibility there, but they do have compatibility with the original 16-bit Thumb first introduced on ARM7s, and binary compatibility is a declared goal there. So regardless of what PC values make sense throughout the pipeline it has to appear to work the way it does to software. This may be moot since it wouldn't apply to Thumb-2 instructions, but if the PC really reflected the value two instructions ahead then it'd also vary depending on if a 32-bit or 16-bit instruction is next.
Reply
  • Note: This was originally posted on 13th February 2013 at http://forums.arm.com

    All of your assertions look correct to me. Just a minor correction on a possible misunderstanding - the 32-bit Thumb-2 instructions are not like the 32-bit ARM instructions. It's a different sort of encoding with slightly different assembly level capabilities too, hence why the unified language is a subset of both.

    About the PC offset.. I don't know for sure, but something I do know is that even the big A-series processors with much longer superscalar pipelines still have the same PC semantics as the original 3-stage ARMs. Meaning that it's no longer a reflection of how the pipeline works but something that has logic to fake it in order to maintain compatibility.

    Cortex-M series processors don't have the traditional ARM instruction set so they don't have to worry about compatibility there, but they do have compatibility with the original 16-bit Thumb first introduced on ARM7s, and binary compatibility is a declared goal there. So regardless of what PC values make sense throughout the pipeline it has to appear to work the way it does to software. This may be moot since it wouldn't apply to Thumb-2 instructions, but if the PC really reflected the value two instructions ahead then it'd also vary depending on if a 32-bit or 16-bit instruction is next.
Children
No data