アセンブラ初心者スレッド 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/25(火) 01:58:20.74

8bitISAの経験はあるんだがIA32やAMD64のプログラミングマニュアルを見ると命令の多さにめまいがする
しかもググってみるとメモリアドレッシングもなにやら作法があるようでよくわからん・・・
な状態なのだがIA32/AMD64のアセンブラを勉強するのにおすすめの資料とかあるかな
今のところ自力で書いたことのあるISAは78K0S、8051、AVR。基本的な概念はわかっているつもり
リンカ周りは不安あり。プラットフォームはWindowsかLinuxかFreeBSDを検討中

**デフォルトの名無しさん** · 2018/09/25(火) 08:56:01.40

>>236
ISAって何のこと？

**デフォルトの名無しさん** · 2018/09/25(火) 09:25:52.53

ISA=instruction set architecture=命令セットアーキテクチャ
や、
ISA=PC/ATの拡張スロットのバス仕様

？？

**デフォルトの名無しさん** · 2018/09/25(火) 18:37:53.38

このスレでISAをIndustry Standard Architectureと解釈する必要ってあるのか？

**デフォルトの名無しさん** · 2018/09/26(水) 04:10:17.53

誤解を生まないよう書き込む際は気を付けた方がいいね

**デフォルトの名無しさん** · 2018/09/26(水) 10:35:31.91

>>236
VCのx64はインラインアセンブラも使えなくなってるんだから、特殊なビット操作やりたいのでなければ
組み込み関数覚えてからの方が楽なんじゃないの
https://software.intel.com/sites/landingpage/IntrinsicsGuide/
右端に対応するニーモニックが書いてある

**デフォルトの名無しさん** · 2018/09/27(木) 10:28:07.85

>>240
アスペじゃなければこの文脈でそれはない

**デフォルトの名無しさん** · 2018/09/27(木) 10:47:26.07

そもそも8bitISAなんて言い方は一般的ではないもん。

**デフォルトの名無しさん** · 2018/09/27(木) 10:58:42.91

かなりアセンブラ経験あるけど、8bit ISAと聞いても意味が分からなかった。
多分、8bit CPUとか、8bit マイコンのことが言いたかったのではないかとは
思ったけど、意味がはっきりしなかったので念のため聞いてみた。

個人的には、Instrucstion Set Architectureの意味での「ISA」という
言い方は、Intelのマニュアルなどで最近目にするようになった印象が
ある言い方。

修正に告ぐ修正を重ねてが複雑化したx86系CPUのあの複雑さのニュアンス
を出すためにIntelが使い始めた言葉かもしれない。

昔、Z80が流行っていたころは、日本の雑誌などでは、8bit CPUと言われて
いたし、炊飯器や冷蔵庫では、今でもCPUよりもどちらかというと
I/OポートやA/Dコンバーターを内蔵しているみたいななニュアンスを
含めて「マイコン」と言われていると思う。

ISAという言葉は、Intelマニュアル以外ではあまり見たことない。

**デフォルトの名無しさん** · 2018/09/27(木) 11:23:55.29

ARM でも MIPS でも普通に ISA 使うけど。
8bit の頃は、セカンドソースはあっても、ISA レベルでのライセンシングが無いか稀だったんじゃないかなあ。

どっちにしろ、16bit バスの ISA を思いつくのはちょっと理解できない。

**デフォルトの名無しさん** · 2018/09/27(木) 11:29:57.13

>>245
文化が違うと用語も違う。Z80 ISAなんて言葉は一度も聞いたことがない。
8BIT ISAも初耳だった。

8BIT時代、ARMやMIPSも日本では聞かなかったし。

**デフォルトの名無しさん** · 2018/09/27(木) 11:40:30.81

>>245
「8-bit ISA card」
で検索すると、色々出てくる。

当時、愛器はNEC製だったのでPC/ATのバス規格であったところのISA
については知らなかったけど。

コンピュータは用語が多様なので、省略形は注意が必要だと思う。
ガングロ女子高生が省略後で通じ合えるのは、多分、興味の対象が
狭いか、語彙が少ないからこそかもしれないと思ってる。
語彙が豊富な人ほど、略さずそのまま言う傾向があると思うし。

**デフォルトの名無しさん** · 2018/09/27(木) 11:40:33.72

>>246
うん、だから ISA レベルでのビジネスがない頃はそこにタームが存在してなかっただけで、今の時代であれば、8bitISA と言われれば、いろんな8bitマイコンの事だと判るでしょ。
おまけに、その下に
自力で書いたことのあるISAは78K0S、8051、AVR
って書いてあるんだから。

>>236
FreeBSDかNetBSDの mm とか syscall とか libc 周り読むのがいいと思う。
本なら、はじめて読む486 は良かった記憶があるけど相当昔の話だし x64 はないからおすすめ度は低い。
Kindle あるみたいだから、気が向いたらレベルでおすすめ。

**デフォルトの名無しさん** · 2018/09/27(木) 11:49:44.12

>>248
あまりなじみの無いCPU名が列挙されていたので、8bit ISA BUSで、組み込み系
をやっていた人かと思ったんだよ。

ネットでは、質問者の年齢も分からないし、何にも推測できないから。

**デフォルトの名無しさん** · 2018/09/27(木) 11:55:04.47

アセンブラの基礎が分かっている人なら、Intelの3 Volumeがセットになった
英文マニュアルがお勧め（なお、英語が分かる人は、日本語版は読まない
方がいいと思う。混乱の元になるから。英語が分からない人は、多分、
混乱しながら時間をかけて前後関係から推定して理解することになる。）

ModRMについても書いてある。ただし、32BITのものが詳しく書かれていて、
64BITのものについては、補足のように後から書かれている。
REX prefixとかと関連して。

非常に壮大なマニュアルで、忘れたけど、総ページ数は5,000ページくらい
あったかもしれないけど、必要なところをかいつまんで読めばいい。

アセンブラ経験がある人なら読めるはず。

**デフォルトの名無しさん** · 2018/09/27(木) 12:02:53.61

みんなここを読んでいるのが自分と同じ業界の専門家だと思っているのかな？
初心者スレなんだから上級者は来るなよ

**デフォルトの名無しさん** · 2018/09/27(木) 12:09:02.87

>>250
PDFファイルは、Adobe純正のものではなく、SumatraPDFがお勧め。
場合によっては、それと、PDF-XChange Viewerとの両使いも便利。

2つのビューアーがあると、同じファイルの異なるページを同時に
見ることが出来る。

特に、SumatraPDFは、ネットブラウザやWindows用の
テキスト・エディタなどとよく似た使い勝手で便利。

**デフォルトの名無しさん** · 2018/09/27(木) 12:29:35.23

>>245
ISAってISAバスしか思い浮かばないんだがw
アセンブラやるなら、ASMソースとかニーモニックコードとかのほうが一般的だろうね

**デフォルトの名無しさん** · 2018/09/27(木) 12:30:49.36

自分の知識不足を棚に上げて絡む馬鹿アスペ

**デフォルトの名無しさん** · 2018/09/27(木) 12:34:10.71

お互いに知識に偏りがあるからしょうがないんだよ。

だから、分からない言葉があれば言葉の確認が必要となると思う。

名プログラマやIQ170の人でも、知らない分野では知識不足はあるよ。

**デフォルトの名無しさん** · 2018/09/27(木) 12:51:27.68

>>255
うん、78K0S、8051、AVRがなじみの無いCPUと聞いてショックを受けている。

**デフォルトの名無しさん** · 2018/09/27(木) 12:59:24.22

>>256
78K0Sが、NEC製のマイコンだということだけは、昔知ったことがある。
でも、昔といってもとても最近。

8051は、PC-8801のシリアルコントローラに、似たような型番のものがあったような
気がしたが、たぶん関係ないけど、正確な型番は思い出せない。

**デフォルトの名無しさん** · 2018/09/27(木) 13:05:15.67

>>256
8251が、Serial Controller、8255 がParallel Controller、
8085、8086がCPUだった。

8051というのは、知らないかも。

**デフォルトの名無しさん** · 2018/09/27(木) 16:23:11.07

>>236
命令が多いのは、基本的には、MMX, SSE～SSE4, AVX, AVX2, AVX512 が
追加されたことが大きい。その辺の命令はまずは、無視。
整数命令(汎用命令)から見るといい。
なおその前に、どんなレジスタがあるかについて勉強する。
「basic execution environment」みたいな節に書いてある。
レジスタは拡張につぐ拡張があったので、理解するのにそれなりの時間がかかる。

アルファベットごとの命令表の、mov, add, sub, mul, div, imul, idiv,
push, pop, call, jmp, jcc 系を中心に見た後、ModRMについて書かれた節を見る。
最初は、16BIT/32BIT の ModRM、SIB について理解する。
その際、operand prefix, address prefix について理解する。
その後、64BIT の long mode, compatible mode の説明を読んだ後、
64BIT の ModRM, SIB について、REX prefix とまとめて理解する。

ちなみに、以下は後回しにする:
fadd, fsub, fmul, fdiv, fldp, fld, fstp, fld は、x87 FPU。
padd, psub は、MMX, addps, addss, subps, subss, mulps, mulss は、SSE系。

mm0～mm7, xmm, ymm, zmm, に関する movxxxx も最初は無視。
これらの movxxxx は、アルファベット順の命令ごとについての書かれた章
のに解説が書かれているが、アラインだとかの説明が難しい。
実は、同じマニュアルセットの全然別の場所にこれらの movxxxx 命令の
説明が割りと平易な言葉で書かれているので参考になる。ただし、英語。
翻訳版の日本語だと余計に意味が分からないかもしれないの注意。

AVX系命令は、まず、VEX, EVEX prefix を読む。REX prefix が完全に理解
してないと理解は難しいと思う。

**デフォルトの名無しさん** · 2018/09/27(木) 16:33:04.36

>>259
ちなみに、命令表は、

1. マニュアルの中心付近にアルファベット順に書かれているもの
2. ずっと後の付録の当たりに確か2進数の BIT 的に書かれているもの
3. マシン語から命令へ逆にたどれるもの

の3種類ある。

以上の命令表のうち、最初に読むべきなのは、上記の「1」のもの。
その命令表を見るための準備も必要。
マニュアルをよく探すと、/0～/7 の意味、+b, +w, +d, +q の意味などが書かれた
部分がある。基本的には、そこを読まないとちゃんとした理解は出来ない。
それだけでなく、命令表も2部に分かれているような独特の読み方がある。それも、
上記の説明と同じような場所にまとめて出ている（分かりにくいが）。
（オペランドの種類を1つの表では表しにくいので、ポインタ参照のような感じで
記号で、後の表の行を指定するような感じになっている。）

REX prefixについては、AMD社のAMD64のManualも当然参考になる。

REX prefix は、色々と注意が必要で、細かい点を正確に理解するのは
しばらく時間がかかる。

**デフォルトの名無しさん** · 2018/09/27(木) 16:36:18.33

墓場に一番近いスレ

**デフォルトの名無しさん** · 2018/09/27(木) 16:49:13.96

>>260
分かっているかもしれないが、x86系では、if()文に相当するものは、
基本的には、cmp aaa,bbb 命令で、（仮想的に）引き算をした後、
結果に基づいて、
zf, cf, sf, of(zero flag, carry flag, sign flag, overflow flag) など
のフラグ類に値が設定されて、そのあと、フラグ類に基づいて、
jz, jnz, jg, jge, jl, jle, ja, jae, jb, jbe などで jump (branch) する仕組み。

cmp命令は、ほとんど sub と同じだが、sub は、結果を destination
に実際に代入するのに対し、cmpは、結果はフラグ類以外にはどこにも
返さない。

subでも、フラグ類は設定されるので、上記の条件ジャンプは cmpと
全く同様に使える。実は、add や test, and, xor などでも、
条件ジャンプは行える場合がある。

整数で多倍長の加算を行うには、caryy flag を使って、add, adc を続けて行う。
減算の場合は、sub, sbb。

add ・・・
adc ・・・
adc ・・・
adc ・・・
・・・

みたいにすると、どれだけでも桁数は増やせる。

掛け算や、割り算の多倍長計算については、もっと数学的に行うが足し算と
引き算だけは、簡単に行える。

**デフォルトの名無しさん** · 2018/09/27(木) 17:57:17.06

そもそも>>1に
>PICやH8を
などと書いてあるのに「組み込み用プロセッサなんて知らなくて当然だ」的な態度は回答者としてどうなんだ？

**デフォルトの名無しさん** · 2018/09/27(木) 19:29:19.93

まずはCコンパイラにアセンブラ出力させて、
それを元に命令の動作をリファレンスマニュアルで確認していった方が楽なのでは？
いきなりマニュアルだけ読むだけだと大変だろうね
ちなみにC++よりもC言語の方がアセンブラ出力を読むのは簡単なはず
あと、Visual C++なら32bitのx86でやった方がいいよ
64bitのアセンブラ出力はそのままアセンブラでアセンブルできないはず
32bitならVisual C++のアセンブラ出力をアセンブラでそのままアセンブルできる

**デフォルトの名無しさん** · 2018/09/27(木) 19:51:12.89

gccなら64bitでもアセンブラ出力できる
AVRを使ったことがあってgcc使ってたのならLinux上でgcc使ってみるのもあり
この場合、コマンドライン主体になるけどね
Linuxなら
objdump -M intel -d hogehoge
という感じで実行ファイルやオブジェクトファイルの逆アセンブルができる

gccでx86のアセンブラ出力をするときは-masm=intelのオプションを忘れずに
やり方はこんな感じ
gcc -S -masm=intel -o hogehoge.s hogehoge.c
このアセンブラリストを
as -a=hogehoge.lst -o hogehoge.o hogehoge.s
とアセンブルできる
これでできたオブジェクトファイルを
gcc -o hogehoge hogehoge.o
これで実行ファイルが完成

gdbではdisasで逆アセンブルできる
逆アセンブルする前にset disassembly-flavor intelを1回入力してやれば
それ以降の逆アセンブルがintel記法で出力される

最後に、WindowsとLinuxでは関数の呼び出し規約が違ったりするのをお忘れなく

**デフォルトの名無しさん** · 2018/09/27(木) 19:58:33.40

gccなら上のように64bitのx86_64のアセンブラ出力もasでアセンブルできるよ

**デフォルトの名無しさん** · 2018/09/27(木) 20:02:31.89

x86のアセンブラで注意が必要なのは
例えば、
mov eax, data01
とあった場合、data01のメモリの内容がeaxに入る
決してdata01のアドレスではない
data01のアドレスを読み込みたかったら
mov eax, offset data01
こうすること

**デフォルトの名無しさん** · 2018/09/27(木) 23:08:23.40

まただよ…

**デフォルトの名無しさん** · 2018/09/28(金) 15:40:04.81

lea だろう常考

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

32bitでは
lea eax, hogehoge
よりも
mov eax, offset hogehoge
の方が命令が1バイト少なくなる

64bitでは
lea rax, hogehoge
だとアドレスはRIP相対の32itDISPになって7バイト
mov rax, offset hogehoge
だと64bitのimmを読み込むので10バイトになって3バイト長くなるけど

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

gccやgasだとx86_64で64bit immを読み込む命令のニーモニックが違うんだよな
movabs rax, offset flat hogehoge
gasだとこうなるかな

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

>>271は
movabs rax, offset flat: hogehoge
でした

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

Linuxでx86_64のgccでコンパイルしたものをとアセンブラのリンクする時に
lea rax, hogehoge
これや
mov rax, hogehoge
これをやるとリンク時にエラーが出るね

lea rax, hogehoge[rip]
mov rax, hogehoge[rip]
こうしないといけないみたい

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

>>273
x64 独特の事情からかんがみて、言いたいことは分かってるつもりだが、
一応、MASM の元々の書き方の仕様では、C言語で言うと、

mov rax, hogehoe[rip]　　; rax = *(rip + &hogehoge)
mov rax, hogehoe　　　　 ; rax = *(&hogehoge)

の「意味」なので、本来は、働きが異なるのでその辺は注意を払う必要がある。

x64 だと、メモリオペランドでは、「絶対アドレス指定」より、
「rip 相対」が短いコードになり、なおかつその場合は、
disp 部分に 64BIT値が入れられないので色々と話が複雑になるけれど。

( gcc(gas)でどう意味に解釈されているかは知らないけど。 )

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

>>274
元々の、masm の syntax 的には、
　　　mov rax,[addr]　　　　;絶対アドレス指定
と、
　　　mov rax,[rip + (addr - offset label1)]　　　;相対アドレス指定
label1:

が rax に入る値が同じになるハズ。

**デフォルトの名無しさん** · 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で簡単に絶対アドレスが登場するのがおかしいと思わないのかね