ARM NEON instruction vcvt is encoded wrong
Hi everybody, I found a bug in gas when assembling the arm neon instruction vcvt. The data type specifiers of the vcvt instruction are encoded in the wrong order. I was writing some code using the instruction "vcvt.s32.f32 q1,q0" which should convert a float value in q0 to an integer in q1. I'm testing my code using the scratchbox environment. Here I get the correct result. However, running the same binary on the device (Nokia N900 in my case) I'm getting wrong results. When I exchange the specifiers to vcvt.f32.s32 I'm getting the same wrong results as on the device now within scratchbox and the correct result on the device. Thus the opcodes are assembled in wrong order. Interestingly this bug exists on all levels: the assembler, the disassembler (objdumb) and the scratchbox ARM-emulator. I haven't tested other instructions using two type specifiers yet, but I assume this to be a general bug concerning all such instructions. best regrads, André Bergner ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ARM NEON instruction vcvt is encoded wrong
Hi André, I found a bug in gas when assembling the arm neon instruction vcvt. In which case please could you fill out a bug report on the binutils bug reporting web page here: http://sourceware.org/bugzilla The data type specifiers of the vcvt instruction are encoded in the wrong order. Which version of the assembler are you using ? If it is not the one built from the current mainline development sources then please try this. There has been some bug fixing in this area of the assembler recently and the problem may already be fixed. I was writing some code using the instruction "vcvt.s32.f32 q1,q0" What binary value do you see for this instruction ? I see this: 0xf3bb2740 Which looks OK to me. (I am using the ARM Architecture Reference Manual version "ARM DDI 0406B_errata_2009_Q3" as my guide). which should convert a float value in q0 to an integer in q1. Well strictly speaking it converts the four signed floating point values in the q0 quad-word vector into four signed integers in the q1 quad-word vector. But lets not be pedantic. :-) However, running the same binary on the device (Nokia N900 in my case) I'm getting wrong results. Wrong how specifically ? Are all of the conversions bogus ? When I exchange the specifiers to vcvt.f32.s32 I'm getting the same wrong results as on the device now within scratchbox and the correct result on the device. Thus the opcodes are assembled in wrong order. Or there is a hardware bug... According to the ARM ARM mentioned above the encoding for this VCVT instruction is as follows: Assembler syntax: VCVT.. ,Encoded as Q = 1 VCVT.. ,Encoded as Q = 0 where: .. The data types for the elements of the vectors They must be one of: .S32.F32encoded as op = 0b10, size = 0b10 .U32.F32encoded as op = 0b11, size = 0b10 .F32.S32encoded as op = 0b00, size = 0b10 .F32.U32encoded as op = 0b01, size = 0b10. So for a VCVT.S32.F32 instruction I would expect the "op" field to be encoded as 0b10. Which matches the instruction encoding: 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 --- 1 1 1 1 0 0 1 1 1 D 1 1 size 1 1 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- Vd0 1 1 op Q M 0 Vm So bits 7 and 8 make up the op, and these are indeed 0b10 in the 0xf3bb2740 encoding that I get from GAS. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ARM NEON instruction vcvt is encoded wrong
I'm sorry I made a mistake. The assembler is assembling correctly, but the emulator (I think it's called qemu) is doing it wrong. I will make a bug report there. Sorry again. regards, André Bergner 2010/1/19 André Bergner > Hi everybody, > > I found a bug in gas when assembling the arm neon instruction vcvt. > The data type specifiers of the vcvt instruction are encoded in the wrong > order. > I was writing some code using the instruction "vcvt.s32.f32 q1,q0" which > should convert a float value > in q0 to an integer in q1. I'm testing my code using the scratchbox > environment. Here I get the correct result. > However, running the same binary on the device (Nokia N900 in my case) I'm > getting wrong results. > When I exchange the specifiers to vcvt.f32.s32 I'm getting the same wrong > results as on the device now > within scratchbox and the correct result on the device. Thus the opcodes > are assembled in wrong order. > Interestingly this bug exists on all levels: the assembler, the > disassembler (objdumb) and the scratchbox ARM-emulator. > > I haven't tested other instructions using two type specifiers yet, but I > assume this to be a general bug concerning all such instructions. > > best regrads, > André Bergner > > ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
