| Author |
Message |
|
|
 Posted: Feb 07, 2011 - 07:53 AM |
|
Joined: Jan 19, 2011
Posts: 63
|
|
I just wanted to warn everybody to use the MOVHI instruction which is documented in the AVR32 architecture manual.
I have found that the assembler generates illegal / wrong opcodes when assembling this instruction. This is very hard to find, and that's the reason why I am posting this.
My configuration: AVR32 studio 2.6 as downloaded from atmel.com; support for UC3C added from within the welcome page; toolchain upgraded to the version from 2010-12-01 by using integrated update mechanism (look into the "Help" menu).
The problem seems to be solved when using MOVH instead. So we have a documented instruction which leads to wrong opcodes and unexplainable code behaviour and a non-documented instruction which seems to work.
Only Atmel knows why there are two instructions for the same purpose, the documented one of them getting assembled without any warning or error messages and nevertheless leading to illegal / wrong opcodes.
Binarus |
Last edited by Binarus on Feb 16, 2011 - 07:19 AM; edited 2 times in total
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2011 - 11:53 AM |
|
Joined: Jan 07, 2003
Posts: 4580
Location: Oslo, Norway
|
|
Which device are you using? The movhi insn was added in architecture revision 2, e.g. -march=ucr2 when you compile with GCC. My guess is movh is a gas insn that will translate into the appropriate instruction for the arch.
Could you post some correct and wrong code? |
|
|
| |
|
|
|
|
|
|
Posted: Feb 07, 2011 - 04:53 PM |
|
Joined: Jan 19, 2011
Posts: 63
|
|
I am using the UC3C0512C and have given that as target to the toolchain. The MCU info is:
Code:
Device information:
Device Name UC3C0512C
Device Revision D
JTAG ID 0x3200003f
SRAM size 64 kB
Flash size 512 kB
Processor configuration:
CPU Revision 0
Architecture Type 0 (AVR32A)
Architecture Revision 3
Memory Management Unit Type 3 (Memory Protection Unit)
Number of Entries in the IMMU 1
Number of Entries in the DMMU 9
Floating Point Unit Yes
Java Extension No
Performance Counters No
OnChip Debug Yes
SIMD Instructions No
DSP Instructions Yes
Memory R-M-W Instructions Yes
Number of Sets in the Instruction Cache 1
Instruction Cache Line Size 1 bytes
Instruction Cache Associativity Direct Mapping
Number of Sets in the Data Cache 1
Data Cache Line Size 1 bytes
Data Cache Associativity Direct Mapping
If you would like to reproduce please note paragraph 3 of my original post. From now on, I am relating to AVR32 Architecture manual rev B. (32000B–AVR32–11/07) which is quite old but seems to be the newest one.
Could you please explain what insn means? Is it short for instruction?
The MOVHI instruction is described at page 222 of the manual although even the description is wrong in itself (look at the syntax part: MOV (!!!) definitely should do other things than MOVHI, so syntax has to be movhi Rd, imm16 and not mov Rd, imm - sigh).
I have attached a project which makes it easy to reproduce the behaviour. Note the following part of the listing / elf:
Code:
MOVHI R12, HI (FINDME)
8000011a: f9 bc *unknown*
8000011c: 80 00 ld.sh r0,r0[0x0]
8000011e: d7 03 nop
which is generated by this harmless assembler code:
Code:
.pushsection .text
.global FINDME
.type FINDME, @function
FINDME:
MOVHI R12, HI (FINDME)
.popsection
Obviously, f9 bc is NOT the opcode of the MOVHI instruction. According to the manual, the opcode should begin with fc. If it wasn't such serious it would be funny that the toolchain knows about the "unknown" opcode but generates it nevertheless...
As I already wrote, for getting correct code just replace MOVHI by MOVH.
Binarus |
|
|
| |
|
|
|
|
|
|
Posted: Feb 16, 2011 - 07:16 AM |
|
Joined: Jan 19, 2011
Posts: 63
|
|
I have reported this to Atmel and got the answer that they will change the architecture manual accordingly.
On one hand, I appreciate that they confirmed the problem not being due to my stupidness; on the other hand, I am very disappointed that they obviously don't plan to change the assembler (as AND gcc-asm).
I really think the assemblers have to be changed so that they just throw an error when encountering a MOVHI instead of silently generating illegal / wrong opcodes.
Since my questions have been answered, the problem has been confirmed and the cause is clear, I am flagging this as solved.
Cheers,
Binarus |
|
|
| |
|
|
|
|
|
|
Posted: Feb 23, 2011 - 06:30 PM |
|
Joined: Nov 25, 2009
Posts: 49
Location: Chennai, India
|
|
|
Binarus wrote:
On one hand, I appreciate that they confirmed the problem not being due to my stupidness; on the other hand, I am very disappointed that they obviously don't plan to change the assembler (as AND gcc-asm).
I really think the assemblers have to be changed so that they just throw an error when encountering a MOVHI instead of silently generating illegal / wrong opcodes.
I never knew this! Tried a simple testcase:
int main(void)
{
asm("movhi r8, hi(16)");
return 1;
}
The compilation shows the opcode as f9... which in my opinion is illegal. movh works fine.
Thanks for the update Binarus. |
_________________
Anitha
|
| |
|
|
|
|
|
|
Posted: Feb 24, 2011 - 01:23 PM |
|
Joined: Jan 19, 2011
Posts: 63
|
|
So now we know that avr32-gcc is also generating wrong / illegal opcodes. I hadn't tested this because I rarely have to use the inline assembler, but often have to write whole assembler modules contained in assembler source files.
Thanks for testing, Anitha!
Binarus |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
