2012-04-04 15 views
3

私はiOSでffmpegを使用しようとしていて、最適化されたアームコードのクラッシュをデバッグしていました。いくつかの符号なし(.u16、.u32)命令が符号付き命令(.i16、.i32)に置き換えられていることを発見しました。 GDBの逆アセンブルされた命令がソースコードと完全に一致しないので、見やすくなります。例えば Apple ASアセンブラは、特定のNEON命令をiOS上の同等の命令に置き換えますか?

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

私の質問:

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

答えて

4

これらの命令は、要素の符号の有無に依存しない - それは.Inn接尾語が何を意味するのか、実際のです。アセンブラはまだ.Snnまたは.Unnのいずれかのバージョンを受け付けますが、逆アセンブルは.Innのみを使用します。 (例えばVMULL)アセンブラは.Inn接尾辞を受け付けない符号付きおよび符号なし整数を区別ない手順について

、だけ.Snn又は.Unn

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 
0

通常、一部のコンパイラとは異なり、アセンブラは何もしないことを保証できます。 アセンブラがいくつかの命令を変更するとき、それはほぼ同等または疑似インストラクションです。