3

iOS で ffmpeg を使用しようとしていて、最適化されたアーム コードでクラッシュをデバッグしていました。一部の未署名 (.u16、.u32) 命令が署名付き命令 (.i16、.i32) に置き換えられていることを発見しました。GDB の逆アセンブルされた命令はソース コードと完全には一致しないため、簡単に確認できます。

例えば、

vrshrn.u32 -> vrshrn.i32
vrshrn.u16 -> vrshrn.i16
vadd.u16 -> vadd.i16

私の質問:

  1. この動作は正しく、期待どおりですか? そうでない場合、どのように修正しますか?
  2. それらが同等である場合、なぜ署名されていないものが必要なのですか? そのようにコードがより明示的であるためですか？
  3. この動作は、他のプラットフォームのツールキットで想定されていますか? たとえば、Android のツールキットは？(AppleのASは古いものだと聞いたことがあります)
4

3 に答える 3

4

これらの命令は要素の署名に依存しません - それは実際に.Inn接尾辞が意味するものです。.Snnアセンブラは引き続き または のいずれかのバージョンを受け入れます.Unnが、逆アセンブリでは のみを使用します.Inn。

符号付き整数と符号なし整数を区別する命令 (例: VMULL) の場合、アセンブラはサフィックスを受け入れず、or.Innのみを受け入れます。.Snn.Unn

于 2012-04-04T15:03:04.340 に答える
3

それらは同じ命令です。符号は動作に影響しません。

$ cat neon.s 
    .text
    .code 32
    .globl _foo
_foo:
    vrshrn.u32 d0, q0, #1
    vrshrn.i32 d0, q0, #1

$ otool -tv neon.o 
neon.o:
(__TEXT,__text) section
_foo:
00000000    f29f0850    vrshrn.i32  d0, q0, #1
00000004    f29f0850    vrshrn.i32  d0, q0, #1
于 2012-04-04T18:02:53.090 に答える
0

一般に、一部のコンパイラとは異なり、アセンブラはおかしなことを何もしないと確信できます。アセンブラがいくつかの命令を変更するとき、それはほとんどの場合、正確に同等または疑似命令です。

于 2012-04-05T02:30:14.037 に答える