Arm Community
Site
Search
User
Site
Search
User
Groups
Education Hub
Distinguished Ambassadors
Open Source Software and Platforms
Research Collaboration and Enablement
Forums
AI and ML forum
Architectures and Processors forum
Arm Development Platforms forum
Arm Development Studio forum
Arm Virtual Hardware forum
Automotive forum
Compilers and Libraries forum
Graphics, Gaming, and VR forum
High Performance Computing (HPC) forum
Infrastructure Solutions forum
Internet of Things (IoT) forum
Keil forum
Morello forum
Operating Systems forum
SoC Design and Simulation forum
SystemReady Forum
Blogs
AI and ML blog
Announcements
Architectures and Processors blog
Automotive blog
Graphics, Gaming, and VR blog
High Performance Computing (HPC) blog
Infrastructure Solutions blog
Internet of Things (IoT) blog
Operating Systems blog
SoC Design and Simulation blog
Tools, Software and IDEs blog
Support
Arm Support Services
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Support forums
Arm Development Studio forum
ARM Vs GCC assembler
Jump...
Cancel
Locked
Locked
Replies
13 replies
Subscribers
118 subscribers
Views
9709 views
Users
0 members are here
Options
Share
More actions
Cancel
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
over 10 years ago
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
Gilead Kutnick
over 10 years ago
Note: This was originally posted on 6th February 2013 at
http://forums.arm.com
Okay, I'll try to explain in more detail, although if you find the ARM manual cryptic you may find me worse..
There's two variables at play here. The 12 bits are taken from the opcode and the 32 bits that are used as an operand when the instruction's executed. The processor expands those 12 bits into the 32-bit operand. The table shows how those 12 bits map to the 32 bits. The 12 bits are actually split into a few different fields scattered throughout the instruction. There's 8 bits at the bottom of the opcode, which the table labels a through h. Then there's another field of 3 bits in the middle which it calls imm3, and another single bit which it calls i. 5 bits are used as a control, so that when those 5 bits match some pattern bits a through h are expanded into the 32 bits as shown by the right-side column. You get the 5 control bits by concatenating i, imm3, and a together. An "x" means that either a 0 or 1 for the a bit will match this pattern.
Are you familiar with how immediates work for the classic ARM ISA? If you are that helps a lot, because Thumb-2's is basically taking the same idea as a base but then improving it, at the expensive of needing more decoding logic in hardware.
If you don't know, ARM's immediate mode is 12-bits and works like this: there's an 8-bit value and a 4-bit shift. The effective value of the immediate is then rotate_right(value, shift * 2). Because rotations wrap around you can use it to shift an 8-bit constant to the left. You can also use it to have immediates that have both the most significant and least significant bits set. This isn't that commonly useful, although I've used it a few times..
Thumb-2 takes this basic format and does two things. First, it drops the ability to have immediates which cross over the edge and sticks with left shifts, meaning that there are only 24 useful shifts instead of 32. Then, it recognizes something similar to what floating point formats do - if you're left shifting a value you can assume that the most significant bit of what you're shifting is a 1 and you don't have to actually store it. With this you get 5 shift bits and 7 significant bits.
Those 5 shift bits only need to store 24 types of shifts (since there's no more support for shifting over the edge), so the other 8 combinations are special. Since they don't involve shifts they need to use the full 8 bits for the immediate, giving another 2 bits leftover (down from 8 combinations to 4) to specify what to do with those 8 bits. These four options let you copy and paste the 8 bit immediate into the 32 bit operand in four different ways. Either it goes to bits 0:7, bits 0:7 and bits 16:23, bits 8:15 and bits 24:31, or bits 0:7, 8:15, 16:23, and 24:31.
0x87C isn't valid because you can't describe it as shifting an 8-bit value to the left by some amount, nor can you describe it as copying an 8-bit value in one of the four ways given.
Cancel
Up
0
Down
Cancel
Reply
Gilead Kutnick
over 10 years ago
Note: This was originally posted on 6th February 2013 at
http://forums.arm.com
Okay, I'll try to explain in more detail, although if you find the ARM manual cryptic you may find me worse..
There's two variables at play here. The 12 bits are taken from the opcode and the 32 bits that are used as an operand when the instruction's executed. The processor expands those 12 bits into the 32-bit operand. The table shows how those 12 bits map to the 32 bits. The 12 bits are actually split into a few different fields scattered throughout the instruction. There's 8 bits at the bottom of the opcode, which the table labels a through h. Then there's another field of 3 bits in the middle which it calls imm3, and another single bit which it calls i. 5 bits are used as a control, so that when those 5 bits match some pattern bits a through h are expanded into the 32 bits as shown by the right-side column. You get the 5 control bits by concatenating i, imm3, and a together. An "x" means that either a 0 or 1 for the a bit will match this pattern.
Are you familiar with how immediates work for the classic ARM ISA? If you are that helps a lot, because Thumb-2's is basically taking the same idea as a base but then improving it, at the expensive of needing more decoding logic in hardware.
If you don't know, ARM's immediate mode is 12-bits and works like this: there's an 8-bit value and a 4-bit shift. The effective value of the immediate is then rotate_right(value, shift * 2). Because rotations wrap around you can use it to shift an 8-bit constant to the left. You can also use it to have immediates that have both the most significant and least significant bits set. This isn't that commonly useful, although I've used it a few times..
Thumb-2 takes this basic format and does two things. First, it drops the ability to have immediates which cross over the edge and sticks with left shifts, meaning that there are only 24 useful shifts instead of 32. Then, it recognizes something similar to what floating point formats do - if you're left shifting a value you can assume that the most significant bit of what you're shifting is a 1 and you don't have to actually store it. With this you get 5 shift bits and 7 significant bits.
Those 5 shift bits only need to store 24 types of shifts (since there's no more support for shifting over the edge), so the other 8 combinations are special. Since they don't involve shifts they need to use the full 8 bits for the immediate, giving another 2 bits leftover (down from 8 combinations to 4) to specify what to do with those 8 bits. These four options let you copy and paste the 8 bit immediate into the 32 bit operand in four different ways. Either it goes to bits 0:7, bits 0:7 and bits 16:23, bits 8:15 and bits 24:31, or bits 0:7, 8:15, 16:23, and 24:31.
0x87C isn't valid because you can't describe it as shifting an 8-bit value to the left by some amount, nor can you describe it as copying an 8-bit value in one of the four ways given.
Cancel
Up
0
Down
Cancel
Children
No data