アセンブラ初心者スレッド 2©2ch.net

**デフォルトの名無しさん転載ダメ©2ch.net** · 2017/04/13(木) 17:35:55.70

初心者OK！質問大歓迎！のアセンブラのスレッドです。
基本情報の勉強中の人、PICやH8を勉強中の学生などなど…

前スレ
アセンブラ初心者スレッド
http://echo.2ch.net/test/read.cgi/tech/1314502612/

関連スレ
アセンブラ 13
http://echo.2ch.net/test/read.cgi/tech/1314512680/

**デフォルトの名無しさん** · 2018/09/29(土) 12:40:11.70

>>274
ちなみに、x86(IA32)モードでは、

[addr]

の ModRM のオペランドのマシン語 encode と全く同じ encode が、
x64(AMD64)では、

[rip + rel32]

になってしまって、しかも後者には、rel32 のための disp32 の4BYTE値が、
ModRM の直後に埋め込まれる仕様になっている。

これは、色々と誤解を招きやすい仕様で、初心者に混乱なく説明するのが難しくなってしまう。

**デフォルトの名無しさん** · 2018/09/29(土) 13:18:43.07

>>274
MASMだとx64で
mov rax, hogehoge
こう書くと
mov rax, [hogehoge+rip]
の意味になるよ
マシン語は48 8B 05 xxxxxxxxでRIP相対の32bitDISPの解釈になる

Linuxのgccやgasだと
mov rax, hogehoge
これが32bitの絶対アドレスと解釈される模様
マシン語は48 8b 04 25 xxxxxxxxと
スケールインデックスの基数を持たない32bitDISPになってしまってる
これだとRIP相対にならないのでリンク時にエラーになる
mov rax, hogehoeg[rip]
これだとマシン語は48 8b 05 xxxxxxxxとRIP相対の32bitDISPになる

Linuxのgccやgasで64bit絶対アドレス読み込みや64bit絶対アドレス指定のデータロードは別のニーモニックになる
movabs rax, offset flat: hogehoge
マシン語は48 b8 xxxxxxxxxxxxxxxx

movabs raｘ, hogehoge
マシン語は48 a1 xxxxxxxxxxxxxxxx
(64bit絶対アドレス指定のデータロードはraxのみ)

**デフォルトの名無しさん** · 2018/09/29(土) 13:25:59.67

ちなみにMASMで
mov rax, offset hogehoge
こう書くと
マシン語は48 b8 xxxxxxxxxxxxxxxx
となる

**デフォルトの名無しさん** · 2018/09/29(土) 13:37:18.16

MASMは実用性を重視した仕様で
gccやgasはより厳密な仕様になってる言えるな

**デフォルトの名無しさん** · 2018/09/29(土) 13:55:45.43

そもそもMASMのx64版で
mov rax, [hogehoge+rip]
や
mov rax, hogehoge[rip]
こうするとエラーになるよ

**デフォルトの名無しさん** · 2018/09/29(土) 14:34:50.49

>>277
>MASMだとx64で
>mov rax, hogehoge
>こう書くと
>mov rax, [hogehoge+rip]
>の意味になるよ
>マシン語は48 8B 05 xxxxxxxxでRIP相対の32bitDISPの解釈になる

言いたいことが間違っているわけではないけど、厳密には、

MASMだとx64で
　　mov rax, hogehoge
と書くと、
　　mov rax, [rip + (offset hogehoge - offset label1)]
label1:

の「意味になる」。

**デフォルトの名無しさん** · 2018/09/29(土) 14:36:51.71

そもそも、IA32までは、jmp, call 以外ではRIP相対は無かったので、
RIP相対については、masm も gas も、今のところ書式(syntax)的に
無理がある気がする。

**デフォルトの名無しさん** · 2018/09/29(土) 14:39:38.93

つまり、今のところメモリオペランドの syntax に一貫性がなくなってきてしまっていると思う。

**デフォルトの名無しさん** · 2018/09/29(土) 15:05:27.10

>>281
つっこむならMASMで試してからつっこめよ
そもそもripはundefined sysmbolになって使えないっての

あなたのつっこみは話がややこしくなるだけだよ

**デフォルトの名無しさん** · 2018/09/29(土) 15:07:28.65

>>284
「意味」になるだけで、通じないことは知ってるよ。

そもそも、masm は [ ] の中に、offset hogehoge 書くと、その通りの
意味にはならないことがあるよ。

**デフォルトの名無しさん** · 2018/09/29(土) 15:08:54.79

MASMは実用性を重視して
mov rax, hogehoge
こういう書式

gcc、gasはより厳密に
mov rax, hogehoge[rip]

あくまでそういう決まりごとってこと
書式は違ってくるが
そもそもVisual C++やMASMとgcc、gasでは違うところが多すぎるから問題ない
gccやgasではアセンブラはデフォルトではAT&T記法だしな

**デフォルトの名無しさん** · 2018/09/29(土) 15:10:56.60

>>285
何、その意味不明な記述
[ ]の中にoffset入れるわけないだろ
そういう突っ込みはいいから。
あなたのつっこみは話をややこしくするだけだろ

**デフォルトの名無しさん** · 2018/09/29(土) 15:13:20.76

こういう変なのがアスペってやつか

**デフォルトの名無しさん** · 2018/09/29(土) 15:18:29.23

>>287
C 言語での、*(&hogehoge) の MASM 版は、意味的には、

[offset hogehoge]

になって、ちょうどそれは、「hogehoge」の意味に戻るはずなんだけど、
実際に masm でやってみると、変になる。記憶によると、masm では、

[hogehoge]

が hogehoge と書いたのと同じ意味になったはず
（論理的にはそんなはずは無いんだけども）。

**デフォルトの名無しさん** · 2018/09/29(土) 15:19:17.57

>>288
アスペかも知れんけど、数学は主席みたいな感じだったよ。

**デフォルトの名無しさん** · 2018/09/29(土) 15:23:02.46

C言語との対応関係も知らずにアセンブラ語ってたとは驚き
で、また火病って連投してるね

**デフォルトの名無しさん** · 2018/09/29(土) 15:24:36.40

こういうのが2ch/5chの問題点なんだよな・・・。

**デフォルトの名無しさん** · 2018/09/29(土) 15:29:01.40

>>289
あなたの書いてることの意味はもともとわかってるっての
MASMではと書いておきながらMASMで通らない命令を書いて人の発言に横槍入れて
したり顔してるのがおかしいってだけ

**デフォルトの名無しさん** · 2018/09/29(土) 15:32:55.38

>>292
普通だったら
&array[x]
はどうやって書くか考えるよね

**デフォルトの名無しさん** · 2018/09/29(土) 15:37:30.74

>>291
もともとわかってることなのに
実際のアセンブラでアセンブルできない命令を書いて因縁つけてスレを混乱させてるのは
ID:1VwJZM7Jの方だぞ

**デフォルトの名無しさん** · 2018/09/29(土) 15:38:31.02

実際に試してみればわかることだよ

**デフォルトの名無しさん** · 2018/09/29(土) 15:41:02.87

ID:1VwJZM7Jは論理的にとか書いてるが
実際のアセンブラの仕様を無視して、アセンブラで通らない命令書いてドヤ顔してるやつ
コンピュータなんて論理的におかしい命令とか普通にあるだろ
アスペはそういうのが我慢ならないらしい

**デフォルトの名無しさん** · 2018/09/29(土) 15:43:55.02

>>295
そんな状態ならx86_64については語らないでくれ
正直迷惑

**デフォルトの名無しさん** · 2018/09/29(土) 15:46:13.22

>>298
あなたもx86_64のアセンブラの仕様関して全く理解してないのはわかった
あなたもしたり顔で語るなよ
ここに書かれてる命令を実際にアセンブルしてその結果を見れば誰が正しいことを言ってるかわかるはず

**デフォルトの名無しさん** · 2018/09/29(土) 15:50:43.93

>>298

>>280にも書いたが
MASMでは
mov rax, hogehoge[rip]
こんな書き方や
mov rax, [hogehoge+rip]
こんな書き方をすると
error A2006:undefined symbol : rip
とエラーになるんだよ

**デフォルトの名無しさん** · 2018/09/29(土) 15:50:52.23

>>299
>>274が理解できてなくて「わかってる」はずないだろ

**デフォルトの名無しさん** · 2018/09/29(土) 15:52:36.05

論理的におかしい命令なんかない
処理されるまでの過程は別にして計算機は命令されたとおりに動く

処理結果がおかしいのはｷﾐﾗのｵﾂﾑの問題

そもそもｱｾﾝﾌﾞﾗなんか
ｷｬｯｼｭﾐｽをできるだけむりやり回避するためにｲﾝﾗｲﾝｱｾﾝﾌﾞﾗ書くとか
非常に明確な理由がないかぎりまず使われることなんかまずない

つまりｺｺではｱﾎ同士がｱﾎなことでもめてる

**デフォルトの名無しさん** · 2018/09/29(土) 15:54:58.28

>>301
> x64 独特の事情からかんがみて、言いたいことは分かってるつもりだが、
> 一応、MASM の元々の書き方の仕様では、C言語で言うと、
>
> mov rax, hogehoe[rip]　　; rax = *(rip + &hogehoge)
> mov rax, hogehoe　　　　 ; rax = *(&hogehoge)
>
> の「意味」なので、本来は、働きが異なるのでその辺は注意を払う必要がある。

そもそもMASMでは
mov rax, hogehoe[rip]
こんな記述は未サポート

mov rax, hogehoe
これが*(rip + hogehoge)の意味

**デフォルトの名無しさん** · 2018/09/29(土) 15:57:13.97

>>302
アスペ君は
mov rax, hogehoge
これが*(hogehoge + rip)の意味になるところが気に入らなくて突っ込みいれてるだけ
でも、実際に仕様なのだからしょうがないってこと

**デフォルトの名無しさん** · 2018/09/29(土) 16:01:34.18

>>273みたいなこと書く奴が「理解できてる」はずないだろｗ
今回も「リンク時にエラーが出る」とか言ってさ

**デフォルトの名無しさん** · 2018/09/29(土) 16:06:06.66

>>305
MASMでは
mov rax, hogehoge
こう書くのが正解なんだが
Linuxでgccとgas使ってプログラム組むと
mov rax, hogehoge
これを書くとリンク時にエラーが出る
理由は>>277に書いてある

Linuxでgcc、gasでは
mov rax, hogehoge[rip]
これでMASMのときのmov rax, hogehogeと同じマシン語が生成されえる
コンパイラやアセンブラが違えば仕様が違うってこと

**デフォルトの名無しさん** · 2018/09/29(土) 16:18:56.60

32bitではきちんと理解してなくてもなんとかなったってだけなの
x64知らないなら出てこなきゃいいのに

**デフォルトの名無しさん** · 2018/09/29(土) 16:24:58.15

>>307
x86_64をわかってないのはあなただろ
MASMでは
mov rax, hogehoge
こう書く仕様だっての

gcc、gasでは
mov rax, hogehoge[rip]
こう書くのが仕様

ただそれだけ
マシン語ではどちらも48 8b 05 xxxxxxxxとRIP相対の32bitDISPになる

**デフォルトの名無しさん** · 2018/09/29(土) 16:32:57.40

offsetを使ったものも

MASMでは
mov rax, offset hogehoge
これでマシン語は48 b8 xxxxxxxxxxxxxxxxと64bit絶対アドレスになる

gcc、gasでは
movabs rax, offset flat: hogehoge
これでマシン語は48 b8 xxxxxxxxxxxxxxxxと64bit絶対アドレスになる

leaを使うと
MASMでは
lea rax, hogehoge
これでマシン語は48 8d 05 xxxxxxxxとRIP相対32bitDISPになる

gcc、gasだと
lea rax, hogehoge[rip]
これでマシン語は48 8d 05 xxxxxxxxとRIP相対32bitDISPになる

**デフォルトの名無しさん** · 2018/09/29(土) 16:43:03.59

x86_64のRIP相対アドレッシングは歴史的には
32bitの時の32bit絶対アドレッシングの仕様を変更してRIP相対をねじ込んだ形だからね
アセンブラの記述的に、論理的におかしくてもしょうがないんだよ
論理的なものよりも実用性を重視したのがMASM
より論理的に厳密にしたのがgasということだろうな

**デフォルトの名無しさん** · 2018/09/29(土) 17:11:34.41

ちょっと質問なんだけど
dataセクションは32bitアドレス内にないとアクセスできないってこと？

extern int aaa[10];
int bbb (int i) {return aaa[i];}

このコードがこんな感じになってたんだけど

00000000004011a0 <bbb>:
4011a0: 48 63 ff movslq %edi,%rdi
4011a3: 8b 04 bd 40 40 40 00 mov 0x404040(,%rdi,4),%eax
4011aa: c3 retq

aaaがdataセクションの0x404040にあったからこうやってアクセスできたけど
32bit超えてたらこの命令は翻訳できない？

**デフォルトの名無しさん** · 2018/09/29(土) 17:23:41.07

>>311
アセンブラのみではそういうことはないけど、C言語とリンクする場合はそうなるね
64bitでも通常はグローバル変数などのシンボルやジャンプ先のラベルは32bitを前提としてコンパイルされている
x86_64だとRIP相対の32bitDISPで届かないところにはアクセスできない
他のCPUでも似たようなもの

Windowsだと回避方法はない
LinuxだとHPCなどで-mcmodel=mediumを指定することで回避できる方法はあるけどね

**デフォルトの名無しさん** · 2018/09/29(土) 17:34:12.56

>>290
首席のことか

**デフォルトの名無しさん** · 2018/09/29(土) 17:35:24.77

>>311を俺の環境でgccでコンパイルしてみたらこうなった
オブジェクトファイルなのでアドレスは00 00 00 00のまま
gccのバージョンは7.3.0

0000000000000000 <bbb>:
0: 48 8d 05 00 00 00 00 lea 0x0(%rip),%rax # 7 <bbb+0x7>
7: 48 63 ff movslq %edi,%rdi
a: 8b 04 b8 mov (%rax,%rdi,4),%eax
d: c3 retq

**デフォルトの名無しさん** · 2018/09/29(土) 17:36:30.80

ありがとう
>>311のはa.outにしてアドレスが分かるようにした後だったから

**デフォルトの名無しさん** · 2018/09/29(土) 17:37:16.65

AT&Tニーモニックの貼ってしまった

Intelニーモニックはこっち
0000000000000000 <bbb>:
0: 48 8d 05 00 00 00 00 lea rax,[rip+0x0] # 7 <bbb+0x7>
7: 48 63 ff movsxd rdi,edi
a: 8b 04 b8 mov eax,DWORD PTR [rax+rdi*4]
d: c3 ret

**デフォルトの名無しさん** · 2018/09/29(土) 17:42:37.03

一旦axに入れてるんだ
そっちの方が遠くまでアクセスできそう
俺のはlinuxだからかな
gccは8.2.0だけど7.3でも>>311のようになりそう

**デフォルトの名無しさん** · 2018/09/29(土) 18:11:22.67

俺のもLinuxだよ

**デフォルトの名無しさん** · 2018/09/29(土) 18:29:50.29

7.3でも5.3でも>>311のになった
configure 設定: ../gcc-7.3.0/configure --prefix=/usr --libdir=/usr/lib64 --mandir=/usr/man --infodir=/usr/info --enable-shared
--enable-bootstrap --enable-languages=ada,brig,c,c++,fortran,go,lto,objc --enable-threads=posix --enable-checking=release
--enable-objc-gc --with-system-zlib --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --enable-lto --disable-install-libiberty --with-gnu-ld --verbose --with-arch-directory=amd64
--disable-gtktest --disable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux
スレッドモデル: posix
gcc バージョン 7.3.0 (GCC)

configure 設定が違うのかな

**デフォルトの名無しさん** · 2018/09/29(土) 18:31:39.06

>>303
>mov rax, hogehoe
>これが*(rip + hogehoge)の意味

それは明らかに間違っているよ。

正しくは、>>281 のように、

MASM だと 64bit mode で
　　mov rax, hogehoge
と書くと、
　　mov rax, [rip + (offset hogehoge - offset label1)]
label1:

の「意味」になって(ただし、実際の masm ではこの書き方はエラーになるはず)、

C言語で書けば、
rax = *( rip + (&hogehoge - &label1) )
label1:

の「意味」になる。

**デフォルトの名無しさん** · 2018/09/29(土) 18:37:57.88

>>320
理解のポイントは、(64BIT)命令ポインタ rip は、CPUが、ModRM
の間接(メモリ)オペランドを解釈する時には、命令の直後の
アドレスを指しているかのようにみなされて、丁度、

rip = offset label1

または、

rip = &label1

であるかのように解釈されるということ。

**デフォルトの名無しさん** · 2018/09/29(土) 18:52:23.15

>>320
RIP相対32bitDISPって書いてるんだからわかってるんだよ、そんなこと
わかりきったことをしたり顔で書いてんじゃねーよ

**デフォルトの名無しさん** · 2018/09/29(土) 19:02:53.64

>>319
自分でビルドしたやつじゃないけど
gcc -vをやると
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-27ubuntu1~18.04'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
--prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)

**デフォルトの名無しさん** · 2018/09/29(土) 19:23:24.57

分かった-fPICつけると>>314と同じになった

**デフォルトの名無しさん** · 2018/09/29(土) 19:30:06.39

MASMはデフォルトがrip相対だからな
offset演算子使った段階でアドレスではなくただの数値になってるのが理解できんのか
だから絶対アドレスになんだよ

**デフォルトの名無しさん** · 2018/09/29(土) 19:42:48.86

>>325
ただの数値じゃないぞ
だって再配置される時に64bitの絶対アドレスが再配置されたアドレスに置き換わる
だからただの数値じゃない、64bit絶対アドレスとして認識されてるはず

**デフォルトの名無しさん** · 2018/09/29(土) 19:54:13.97

変な突っ込みする人がいるから書くが
CPUの命令的にはx86_64で
mov rax, offset hogehoge
これは64bitのimmを読み込むマシン語に変換される
要するにただの64bitの数値を読み込む命令
マシン語は48 b8 xxxxxxxxxxxxxxxx
ただ、アセンブラはちゃんと64bit immの部分が64bitの絶対アドレスということを認識してる
だから再配置された時に64bit絶対アドレスが再配置後のhogehogeのアドレスに置き換わる

**デフォルトの名無しさん** · 2018/09/29(土) 20:19:25.44

こんなことみんな知ってるとは思うが
実際に64bit絶対アドレスが確定するのはプログラムがメモリ上にロードされる時
このときに、絶対アドレスなどの情報が配置されるアドレスによって正しい値に書き換えられる

**デフォルトの名無しさん** · 2018/09/29(土) 21:07:16.90

そもそも
lea rax, [hogehoge]
って書いときゃNASMでも通るのに
＞data01のアドレスを読み込みたかったら
＞mov eax, offset data01
＞こうすること
なんて教えようとするのかね？

**デフォルトの名無しさん** · 2018/09/29(土) 21:11:28.97

MASMって
mov eax, [rsp][16]
mov eax, [rsi][rcx]
みたいな変態な表現も通るんだよな

**デフォルトの名無しさん** · 2018/09/30(日) 00:47:29.69

Microsoft (R) Macro Assembler (x64) Version 12.00.40629.0
mov al, hogehoge
mov al, [hogehoge]
mov rax, offset flat:hogehoge ; error A2006:undefined symbol : flat
lea rax, [hogehoge]
lea rax, offset flat:hogehoge ; error A2006:undefined symbol : flat
lea rax, hogehoge

14.00.24210.0でも同じだな

**デフォルトの名無しさん** · 2018/09/30(日) 00:54:08.42

clが吐いた.codでは
lea rax, offset flat:hogehoge
みたいな表記になってるけど、ml64は受け付けない

**デフォルトの名無しさん** · 2018/09/30(日) 01:03:38.57

mov eax, offset hogehoge
とやってもエラーも出ないんだよね　当然だけど
0000001A 48/ B8　0000000000000000 E　mov rax, offset hogehoge
00000024 B8 00000000 E mov eax, offset hogehoge

**236** · 2018/09/30(日) 01:18:13.92

なんか説明が不適切だったせいで偉いことになってしまった・・・すまん

とりあえずAMD64のプログラミングマニュアルとIA32/EM64Tの日本語プログラミングマニュアルはダウンロードしてあります

やりたいことは演算ではなくて特殊？な例外処理です。C風に書くと
unsigned int *a;
unsigned int b;
&a = 0x00001000; // アドレスをセット
*a = 0x00888888; // 0x00001000へ値を書き込み
b = *(&a + 1); // 0x00001004の値を読み出し。読み出される値は0x00001000の値に0x0100を加算した物
// bの中身は0x00888988
みたいな感じかな。メモリの読み書き動作に任意の処理を挟みたいです。自分なりにこのような動作をさせる方法を考えた結果
・該当する仮想アドレスにメモリを割り当てない
・アクセスすると発生するページフォールトをハンドリングする
・ハンドラ中で値の処理とアクセス元のコードが行うつもりだった読み書き動作もする
・ページフォールトを発生させた次の命令から実行を再開する
となったのですがこれらを高級言語のみで実装するのは無理そうな気がするのでアセンブラを読み書きできる必要があるかなと・・・
各OSごとの例外処理がらみの情報も必要ですがこの辺もなかなか見つけられないです

**デフォルトの名無しさん** · 2018/09/30(日) 04:51:47.08

>>322
64bitのcl.exeが吐き出すアセンブラ出力はml64.exeでそのままではアセンブル通らないよ
何箇所か、修正が必要になる
ちなみに32bitのcl.exeが吐き出すアセンブラ出力はそのまま32bitのml.exeでアセンブルできる

>>333
mov eax, offset hogehoge
これをx64用のml64.exeでアセンブルしてもエラーは起きないが
リンク時にこのエラーが出るよ
error LNK2017: 'ADDR32' relocation to
'hogehoge' invalid without /LARGEADDRESSAWARE:NO
LINK : fatal error LNK1165: link failed because of fixup errors
64bitのアドレスを32bit絶対アドレスに切り詰めてるのだから当たり前だけど

mov rax, offset hogehoge
これは全く問題ない
アセンブルもリンクも正常に行われるし、正常にプログラムを実行できる

**デフォルトの名無しさん** · 2018/09/30(日) 17:26:28.46

>>335
NASM（bits64, default rel）だとエラーになるよ
mov rax, offset hogehoge ; error: comma, colon, decorator or end of line expected after operand
lea rax, hogehoge ; error: invalid combination of opcode and operands
lea rax, [hogehoge] ⇒ 488D05

mov al, hogehoge ⇒ B0
にアセンブルされたりもするけど

MASMでもlea rax, [hogehoge]やmov al, [hogehoge]はNASMと同じマシン語になるはず

Windows 64bitはrip相対使ってるのに、MASMで簡単に絶対アドレスが登場するのがおかしいと思わないのかね

**デフォルトの名無しさん** · 2018/09/30(日) 21:29:51.77

>>334
いまいちやりたいことが分からないんだけど、Windowsでアクセス違反をハンドリングするのは
https://docs.microsoft.com/ja-jp/windows/desktop/Memory/reserving-and-committing-memory
が参考になるんじゃないかな
__except()のフィルタ関数でアクセス違反をチェックして、対象範囲のアドレスだったらVirtualAllocで
コミットして__except()にEXCEPTION_CONTINUE_EXECUTION返せば再実行される
対象範囲外のアドレスはEXCEPTION_CONTINUE_SEARCHを返す必要がある
メモリは事前に予約してないと例外から回復できないみたい

構造化例外処理は
http://www.ne.jp/asahi/hishidama/home/tech/vcpp/seh.html
https://msdn.microsoft.com/ja-jp/library/swezty51.aspx
を読んでみて

**デフォルトの名無しさん** · 2018/10/01(月) 04:48:19.14

>>336
LinuxのNASMとMASMは構文違うよ

NASMだと
mov rax, hogehoeg
マシン語は48 b8 xxxxxxxxxxxxxxx
これでraxにアドレスが入る

WindowsのMASMだと
mov rax, hogehoge
マシン語は48 8b 05 xxxxxxxx
hogehogeのメモリの内容がraxにロードされる
MASMの場合、
mov rax, offset hogehoge
これだとマシン語は48 b8 xxxxxxxxxxxxxxxx
これにしないとNASMのmov rax, hogehogeと同じマシン語にならない

**デフォルトの名無しさん** · 2018/10/01(月) 05:43:56.26

みんなはじめて読むMASMからやり直しだなｗ

**デフォルトの名無しさん** · 2018/10/01(月) 05:51:48.63

>>336
RIP相対32bitdispだとアクセスできない場合が出てくる
シンボルがRIP相対2GBに制限されるなどはあくまでCコンパイラの制限であって
アセンブラはその制限を受けない
実際にWindowsのEXEファイルは64bit絶対アドレスに対応してて
きちんと再配置してくれるわけだし

**デフォルトの名無しさん** · 2018/10/01(月) 06:38:07.64

これこそアスペって奴だよな
質問とは関係ないCPU持ち出して勝手に「語り」をはじめたり、32bitでは1バイト短くなるだの
実用的には0.001%程度しか影響なさそうな絶対アドレスの方が速いだの、C/C++とリンクして使うのが
普通なのに「シンボルがRIP相対2GBに制限されるなどはあくまでCコンパイラの制限であってアセンブラはその制限を受けない」とか
初心者そっちのけで有害としか思えないような方法垂れ流したりと、他人の迷惑とか全く考えられないんだから

初心者にはMASMとNASMで同じように使えればそれで十分
完全に同じマシン語になるかどうかなんて知るか
特に絶対アドレスなんてWin64には不要と考えるべき
初期化領域以外の動的確保されたメモリはポインタ経由のアクセスが基本なんだから

**デフォルトの名無しさん** · 2018/10/01(月) 06:45:27.19

>>334
こういう状態なんで、334は全く悪くないから気にしなくていいよ

アクセス違反を検出して対応するのは、使ってみたいところがあったのでちょうどいい機会だった
一応自分の書いたテストプログラムを上げとくね
https://pastebin.com/b5gZXxCF

**デフォルトの名無しさん** · 2018/10/01(月) 06:51:19.23

>>341
>>338が理解できないのか？
LinuxのNASMとWindowsのMASMは根本的に文法が違う
同じようにはプログラミングできないっての

MASMではMS-DOSの頃から伝統的に
mov ax, hogehoge
これをやるとhogehogeのメモリの内容をaxに読み込む
はじめて読むMASMにもそう書いてあるよｗ

**デフォルトの名無しさん** · 2018/10/01(月) 07:02:13.01

はじめて読むMASM
79ページ目
　データラベルは、マシンご命令のニーモニックのなかで、データを格納す
るメモリを参照するために使用することができます。次の図３－１０をみてく
ださい。この図では、違いを対比させるために次節で解説するOFFSET擬似
命令の役割を併せて図解してあります。
　この場合、MESSAGEというデータラベルは01C3Hというアドレスに対応
しています。コードラベルの場合は、ラベル名がアドレスそのものと対応し
ていましたが、データラベルの場合にはちょっと違います。このことは重要
ですからよく覚えておいて下さい。
　たとえば、SYMDEBのようにアドレスを直接数値で指定する場合、そのア
ドレスのメモリの内容を参照するには、
　MOV DX, [01C3H]
のようにアドレスを［］で囲みます。これに対し、アセンブラのソースプロ
グラムでは、
　MOV

**デフォルトの名無しさん** · 2018/10/01(月) 07:04:42.69

はじめて読むMASM
79ページ目
　データラベルは、マシンご命令のニーモニックのなかで、データを格納す
るメモリを参照するために使用することができます。次の図３－１０をみてく
ださい。この図では、違いを対比させるために次節で解説するOFFSET擬似
命令の役割を併せて図解してあります。
　この場合、MESSAGEというデータラベルは01C3Hというアドレスに対応
しています。コードラベルの場合は、ラベル名がアドレスそのものと対応し
ていましたが、データラベルの場合にはちょっと違います。このことは重要
ですからよく覚えておいて下さい。
　たとえば、SYMDEBのようにアドレスを直接数値で指定する場合、そのア
ドレスのメモリの内容を参照するには、
　MOV DX, [01C3H]
のようにアドレスを［］で囲みます。これに対し、アセンブラのソースプロ
グラムでは、
　MOV DX, MESSAGE
とします。このことからわかるように、データラベルはラベルに対応するア
ドレスそのものではなく、そのアドレスが示すメモリの内容を表します。
つまり、データラベルそのものを指定すると、アドレスの値を転送したり演算
したりする命令ではなくて、メモリに対して転送や演算を行う命令になりま
す。もう1度図３－１０を見てじっくり確認してください。

こう書かれてる

**デフォルトの名無しさん** · 2018/10/01(月) 07:10:06.78

82ページ目

３．６
OFFSET演算子とPTR演算子
OFFSET演算子
[書式]　OFFSET　ラベル名

データラベルをニーモニック中で使用すると、データ部分のアドレスでは
なく、データを格納したメモリの内容を表しますが、そのメモリのアドレス
はどうやって表すのでしょうか。図３－１０で図解してあるので解説するまでも
ありませんが、データラベルに対応するアドレスは、次のように表します
　OFFSET データラベル
　OFFSET演算子は、ラベルに対して使用する演算子です。ラベルの前にこ
の演算子を付けると、ラベルに対応するアドレスを表す値となります。
　例題のプログラムでは図３－１１の部分で使われています。これは画面に出
力するメッセージが格納されているアドレス値を、データとして定義してい
る例です。

MASMの文法は16bitの頃から一貫してる
みんなはじめて読むMASMからやりなおしだな

**デフォルトの名無しさん** · 2018/10/01(月) 07:41:22.29

>>343
MASMでもmov al,[hogehoge]やlea rax,[hogehoge]が使えて、NASMと「同じ動作」が期待できて、
「根本的に」書き換えなくても疑似命令やマクロとかを書き換えれば移植できるってのがポイントで
NASMはLinux他とWindowsみたいなマルチプラットフォームのプロジェクトでよく使われてるから
あんたみたいなmov al,hogehogeやり方でNASMに移行すると変なバグに悩まされる可能性があんだよ
特にmov al,hogehogeがイミディエイトでアドレスの一部がコードされるのが酷い

SYMDEBで括弧で括るってのはイミディエイトと区別付かないからそうなってるんだろ
これはNASMで括弧で括るのと同じこと
時代遅れになった本の内容なんてどうでもいい
括弧で括らない表記は、8080時代を踏襲してるのか、インラインアセンブラでのCの変数参照と統一感があるってところだろう
これならNASMで異なる動作にならない方が無難

こっちが言いたいのは、初心者に有用なことが書けないなら「出てくんな」ってことだけ

**デフォルトの名無しさん** · 2018/10/01(月) 07:55:48.93

>>347
それは自分だけで書いたコードを読むだけならいいが
他人が書いたコードやコンパイラが吐き出したコードを読むのにはそれは通用しない

**デフォルトの名無しさん** · 2018/10/01(月) 07:57:49.96

それにNASMで慣れるとgccでインラインアセンブラを使うときに困る
gccはx86_64でもインラインアセンブラを扱えるのに
NASMの文法はgccのインラインアセンブラでは通用しないぞ

**デフォルトの名無しさん** · 2018/10/01(月) 08:10:48.59

多くの人がOFFSET演算子に対する理解がないようだから書いただけなのに
猛烈に反発してくる変な人がいるだけ

gccでは-mcmodel=largeのオプションを付けてコンパイルすると
movabs rax, offset flat: hogehoge
のような表現がよく出てくる
64bit絶対アドレスを扱うには必ず必要になってくる

**デフォルトの名無しさん** · 2018/10/01(月) 09:35:33.25

>>341
アセンブラは、かなり細かいことを理解して無いと使いこなせないかもしれないよ。
それが C/C++ などとは違う点。

ちゃんと、リストファイルを見て、Intel の Instruction 表と照らし合わせて
どの命令が出力されているかを確認し、さらに、OBJやEXEファイルを逆アセンブル
してみて、さらにさらに、ローダーが実際にどのようにロードしたかをデバッガ
で確認する、などをちゃんとしないと、うまくいかないかもしれない。

実際、純正の Visual Studio が出したアセンブリソースが、masm で通らない
などという現象が確認されている事からしても、色々と確認作業が必要だと
思う。

自分はアセンブリ経験が豊富だが、上記のような確認作業をかなり積んだから
こそ使えていたと思う。

アセンブラの出力は、バージョンによっても違っていることがあるかも
知れないし、64BITモードでは、同じニモニックでも異なるマシン語を
出力することもありえる。

さらに言うと、アセンブラ自体が非常に困った仕様になってしまっていることもあり得る。

もともと、アセンブリ言語は、初心者が混乱無く使えるようにはなってないという側面もある。

失礼かもしれないけど、他の言語で豊富な経験を積んで、なおかつ、地頭のいい人限定だよね、もともと。

**デフォルトの名無しさん** · 2018/10/01(月) 09:38:14.45

あと、一度実験した内容を正確に覚える記憶力も必要。

本で書かれていることと実際が違っていることは良くある。

**デフォルトの名無しさん** · 2018/10/01(月) 10:13:48.86

>>334
例外処理については、詳細な文献と実験調査を行ったことがある。

文献だけでは不十分で、コードをフックするような仕組みによって実験しないと分からない。

教えることは出来るが、ここでは馬鹿にされるだけなのですまんが答えられない。

**デフォルトの名無しさん** · 2018/10/01(月) 10:26:50.53

IDを換えながらレスをつけてるのか

**デフォルトの名無しさん** · 2018/10/01(月) 23:50:29.17

>>353
Windows用のサンプルは>>342でupしてるので、Linuxは任せたｗ

**デフォルトの名無しさん** · 2018/10/02(火) 07:08:08.55

>>334
Windowsならちょっとググッただけでいろいろ出てくるぞ
このあたり見てやればできるのでは？
アセンブラは全く関係ないね

構造化例外処理
http://www.ne.jp/asahi/hishidama/home/tech/vcpp/seh.html
GetExceptionCode
https://msdn.microsoft.com/ja-jp/library/cc428942.aspx

**デフォルトの名無しさん** · 2018/10/02(火) 07:14:31.94

あとこれも

構造化例外処理と UnhandledExceptionFilter
https://www.keicode.com/windows/windows_exception_handling.php

**デフォルトの名無しさん** · 2018/10/02(火) 07:41:02.78

これも

構造化例外処理～例外情報の取得
https://www.keicode.com/windows/structured_exception_handling.php

**デフォルトの名無しさん** · 2018/10/02(火) 08:43:48.77

ただ、例外のハンドリングはできても、処理を続行するのは難しいね
EXCEPTION_CONTINUE_EXECUTION を返すと処理は続行されるけど
例外が発生するところから続行されるからね
例外が発生したところの次の命令から続行されるわけじゃないからね

**デフォルトの名無しさん** · 2018/10/02(火) 14:17:43.67

>>359
次の命令からでも、続行する方法あるよ。

**デフォルトの名無しさん** · 2018/10/02(火) 18:27:14.93

アセンブラが難しすぎて読めません
https://gyazo.com/ba3099329df9872df87fa3c35ff13384
これはFPSの弾数周辺のアセンブリなんですが、どういう処理をしてるのか全く分かりません
どういう風に読んでいけば理解できるのか？ヒント下さい
ニーモニックは何となく分かるんですけど・・

**236** · 2018/10/02(火) 23:02:45.96

ありがとう。やりたいことはメモリマップドI/Oのエミュレーションです。なので呼び出し元のコードはなるべく細工したくありません

例外ハンドラでメモリを確保してしまうと2回目以降や隣接するアドレスのアクセス時に例外が発生しなくなってしまうので避けたいです
あとWindowsで>>334をやろうとした場合0x00001000から8Byteをあける必要がありますが、そのアドレスへデータをロードしないよう
MSVCのリンカへ指示する方法がわかりません
ldやlldなどであればリンカスクリプトで指示できるらしいのですが・・・(OSの候補にLinuxやFreeBSDがいる理由の一つです)

呼び出し元のコードに細工をすれば例外なんてめんどくさい物を使わずにすみますが、エミュレートしないケースの
オーバーヘッドを完全になくせるか心配です。コンパイラの最適化でインライン展開とデッドコード削除が約束されるなら
そっちの方が遙かに楽ですが・・・

**デフォルトの名無しさん** · 2018/10/03(水) 00:49:48.02

>>362
例外機構を使わずに、以下のような方法も場合によっては使える：

1. C++ の演算子の overload を使う方法。
2. Win32のメモリマップド I/O 機能を使う方法。

>あとWindowsで>>334をやろうとした場合0x00001000から8Byteをあける必要がありますが、
>そのアドレスへデータをロードしないよう
>MSVCのリンカへ指示する方法がわかりません

これは、VitualAlloc() で、0x1000 からの 1page(4096 バイト)をアクセス禁止の page に
すると可能。

ただし、8 バイト以外の部分もアクセス禁止になるので、その部分でも、例外ハンドラ
が起動してしまうので、その部分についての処理も例外ハンドラに書くようにする。

**デフォルトの名無しさん** · 2018/10/22(月) 19:17:19.32

最近CASLⅡ覚えた後、実際のマイコンのアセンブリ言語覚えたくてルネサスのRL78も覚えたんだけど(PICはCASLⅡ以前から覚えてはいた)、
x86とZ80を合わせたようなニーモニックだけかと思ったらAをR0、XをR1って別名に出来たりAXがRP0に出来たり、GR0、GR1って書くCASLⅡにニーモニックが似てるんだが。。。

これってもしかして癒着とかじゃあるまいな。
(逆にルネサスがCASLⅡに寄せた可能性も微レ存)

日本車に使われてるらしいし、自動車は国の基幹産業だし(つまりルネサスのお得意様は日本の自動車メーカー)、あり得なくはない。

**デフォルトの名無しさん** · 2018/10/22(月) 19:56:28.08

仮想アセンブラでは、LLVM が標準

**デフォルトの名無しさん** · 2018/10/23(火) 14:50:58.07

病院逝け

**デフォルトの名無しさん** · 2018/10/23(火) 18:22:26.97

もう少し髪が伸びたらな

**デフォルトの名無しさん** · 2018/11/26(月) 21:11:44.08

LLVMネタってここで良いんですかね？

**デフォルトの名無しさん** · 2018/11/30(金) 09:46:12.16

アセンブラの勉強始めていきなり躓いてるのですが、オペランドの記述で
r/m32やimm32やr32やm32って何の略なんですか？
検索しても命令一覧表ばかり引っかかって・・（;´д｀）

**デフォルトの名無しさん** · 2018/11/30(金) 10:47:42.01

r32： 32bit幅レジスタ
m32： 32bit幅メモリ
imm32： 32bit幅即値

**デフォルトの名無しさん** · 2018/11/30(金) 10:53:47.90

命令の内部フォーマットとアドレッシングモード
https://www.mztn.org/lxasm64/amd05.html

**デフォルトの名無しさん** · 2018/11/30(金) 15:33:43.72

>>367
オシャレ

**デフォルトの名無しさん** · 2018/11/30(金) 17:07:23.34

>>368
知ってても答えたくないかも。

**デフォルトの名無しさん** · 2018/11/30(金) 17:26:55.55

>>365
あれは人間が読むコードじゃない

**デフォルトの名無しさん** · 2018/12/02(日) 03:55:19.52

>>370
>>371
ありがとうございます！

**デフォルトの名無しさん** · 2018/12/02(日) 13:54:11.82

LLVM 豆知識。
getelementptr には、似て非なるものが二種類ある。命令タイプと、定数タイプ。
後者は、他の命令のオペランドで用い、括弧でくくるような書き方をする。

仮想レジスタ %n に、整数定数を代入する命令が無い。
それで困った場合は、
　%10 = add i32 定数値, 0
などとすると良い。同様にポインタ定数も直接は代入できないが、
　%10 = getelementptr TYPE, TYPE * アドレス定数, 0
などとすれｂな代入できる。