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

レス数が900を超えています。1000を超えると表示できなくなるよ。
2017/04/13(木) 17:35:55.70ID:1WMn3pSz
初心者OK！質問大歓迎！のアセンブラのスレッドです。
基本情報の勉強中の人、PICやH8を勉強中の学生などなど…

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

関連スレ
アセンブラ 13
http://echo.2ch.net/test/read.cgi/tech/1314512680/
2020/07/18(土) 13:46:42.99ID:uRU3MGLx
IXとかIYの裏命令の話があるな
2020/07/18(土) 13:49:01.14ID:HDs6SbLj
>>814
昔の事だったし、資料が手元に無いが、原則論として
DDDとかのレジスタ番号の1つとして、(HL)が書いてあり、
それがDDD=6だったと思う。
ただし、原則論なので、全ての命令でDDD=6にすれば必ず合法で、
(HL)になるという意味ではない。
2020/07/18(土) 13:51:52.21ID:HDs6SbLj
>>816
リンク先のページでも、
INC r; DEC r; LD r1,r2; LD r2, r1 においても、DDD=6は、(HL)の命令に該当
していることが分かる。
2020/07/18(土) 13:56:24.86ID:B9g40Bu1
76: ぼくのことわすれないで
2020/07/18(土) 14:24:37.73ID:HDs6SbLj
AND, OR, XOR, ADD, ADC, SUB, SBC, CP,
やローテート、シフト命令でも、レジスタ様の命令で、
レジスタ番号を6にすると、(HL)に対する命令と同じ
マシン語になっていることが分かる。
2020/07/19(日) 04:45:05.98ID:1aVreze3
x86_64のアセンブラを始めようと思ってるのですが、レジスタの使い方を教えてください

以前、80286の頃だと、たとえばECXレジスタはカウンタ用に使うものだったと記憶してますが
x86_64だとほぼもう汎用レジスタとして使えるように見えます
gccなどもx86_64用でもそういうコードを出力するようです

昔の用途での使い方について、どれくらい意識した方がよいのでしょう
2020/07/19(日) 10:17:20.71ID:TvRHHtME
>>820
CPUの世代によっては、loop 命令は、
dec ecx
jnz ラベル名
とするよりも遅いことがあるので、後者の書き方の方が良い。
その意味で、ループカウンタを入れるレジスタとして、ecxにこだわる必要はない。

ただし、rep movsd などでは今でもカウンタが ecx に固定されている。

それ以外の場面では、ecxは、他の汎用レジスタと同じと考えてよい。

なお、ebpは汎用レジスタとしては使わず、スタックフレームの先頭アドレスを保持して、
ローカル変数をアクセスするために使うことが原則。
ただし、ローカル変数をebpの代わりにespを介してアクセスすることによって
ebpを汎用レジスタとして使う流儀も有り得る。
その場合は、push,pop命令によってespが変化してしまうので注意が必要となる。
なお、masmのlocalやarg擬似命令は、ebp方式を前提としている。

edi,esi は、movsd で使うことは意識しておく。
edx,eaxは、div命令で使うことを意識しておく。
edi,esi,ebpは、関数呼び出しで保存されるが、eax,ebx,ecx,edxは保存されないことを意識しておく。
eaxは関数呼び出しの戻り値になることを意識しておく。
2020/07/19(日) 10:18:46.24ID:TvRHHtME
>>821
さらに、dec reg 命令より、sub reg,1 の方が速いことがある。
前者は2クロック、後者は1クロック。なので、loop文は、
sub ecx,1
jnz ラベル名
と書くのが最良。
2020/07/19(日) 12:34:39.03ID:h5vFOzT4
>>820
呼び出し規約を守れば
あとはご自由に
2020/07/19(日) 12:36:44.38ID:h5vFOzT4
レジスタが増えてるし
SIMDレジスタもあるんで
自由度は高い

MULとDIVは相変わらずRAX, RDX縛りがあるけど
2020/07/19(日) 12:47:27.95ID:du465xO7
IA-32の命令ならインテルのhpにある
2020/07/19(日) 14:46:51.74ID:1aVreze3
820です

回答ありがとうございました

ABIやライブラリ等での使い方・縛りを考慮して使うようにすると、
やはりそれぞれのレジスタをアキュムレータ、カウンタ等として使う、
というのを指針にした方がよさそうですね
2020/07/19(日) 15:35:41.18ID:AazHQwx2
>>826
いや、普通の命令文に対する繰り返しのカウンタとしては、ecxを意識する必要はない。
計算のアキュムレータとしても、eaxを意識する必要も余りない。
余りを求める割り算だけは特殊。
2020/07/21(火) 11:55:19.37ID:08cjL+93
こんな感じで部品並べたら子ーどがてせきるやつないの？
amd64の

https://i.imgur.com/REDBsNI.png
https://i.imgur.com/NUN7ejI.png
https://i.imgur.com/Qchpsl1.png
2020/07/27(月) 04:16:34.73ID:FDPJJmZc
ない
2020/08/03(月) 23:51:00.41ID:f8ly6bXL
ttps://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%89%E3%83%AC%E3%83%83%E3%82%B7%E3%83%B3%E3%82%B0%E3%83%A2%E3%83%BC%E3%83%89
>アドレッシングモード
>既に使われなくなったアドレッシングモード
>メモリマップド・レジスタ
？？？国内なら78K0R(現RL78)、海外でもMSC-51(現EFM8BB1)とかはCPUのレジスタがメモリ空間にマッピングされている
いずれも現行製品では
831デフォルトの名無しさん
垢版 |
2020/08/04(火) 10:47:29.79ID:DzQriKoF
6809の0-255あたりのやつのことかな
832デフォルトの名無しさん
垢版 |
2020/08/04(火) 10:48:39.15ID:DzQriKoF
まあ同じことなんだろうけど
「CPUのレジスタがメモリ空間にマッピングされている」
というより
「メモリ空間がCPUのレジスタにマッピングされている」
というイメージ
2020/08/04(火) 11:41:48.61ID:WjyA4gdt
イメージって何か表現してるようで何も言ってないに等しい
2020/08/04(火) 12:45:04.95ID:g9THIEhB
ttps://ednjapan.com/edn/articles/1908/28/news026_3.html
STMはレジスタとSRAMの構造が違うらしい
理由からすると多くのCPUが同じ事やってそう
2020/08/04(火) 13:23:59.89ID:9WSBhL2x
この板でイメージを厳密に技術用語で使わないやつは…
2020/08/04(火) 15:05:26.21ID:z2HwYjyf
>>830
> CPUのレジスタがメモリ空間にマッピング
て具体的にどうやるんだろ？と思って調べてみた。
CPUのアドレスバスを監視して、レジスタにアクセスがあったのを検知したら、
それにマップされてるメモリにも同じようにアクセスするってことをしてると。なるほど。
2020/08/04(火) 15:22:33.51ID:CK7AS0VE
>>836
そういうことではなく、レジスタをアドレス空間にマッピングしているCPUは、
例えば、アドレス空間の 0〜255 番地の部分をレジスタ専用に
して、CPUの外部のアドレスバスには信号が出ないようにしていることが多い。
そして、
mov [0],値
と書くと、r0 に「値」を書き込むようにCPUが設計されていて、
外部のDRAMなどには全く信号が送られないようになっている。
2020/08/04(火) 15:30:51.43ID:z2HwYjyf
>>837
そういうのもあるだろうけど、それは最初からそういう設計にしているからそう動くということだよね。
アドレス空間にある入出力領域は固定的である必要はないので、バスに出た信号をどう処理するかは
設計者が自由に決められるはず。なので、バスに出た信号をメモリだけに送ることもできるし、
CPUとメモリ両方に送ることもできる。用途に合わせればいいということかと。
2020/08/04(火) 15:34:19.50ID:CK7AS0VE
>>838
「レジスタをアドレス空間にマッピングしているCPU」
というのは、最初から設計されているCPUのことだと思うぞ。
実際、ポケコンのCPUもそんな感じだった。
2020/08/04(火) 16:20:06.60ID:z2HwYjyf
>>839
設計者が最初からそう設計したのならそうだろうね。
固定的である必要がないというのは、設計するとき設計者がどちらでも選べるという意味だよ。
2020/08/04(火) 19:31:24.43ID:aUyBUHRY
>>837
ああ、ずっと何の話をしてるのか分からなかったけど0ページの話ね。
2020/08/16(日) 16:21:04.44ID:Cqk7CoxF
>>839　アルディーノのCPUがそれだ。レジスタがメモリにマッピングされている。
2020/08/17(月) 08:09:56.01ID:tzd42ouk
LLVMが吐き出したx86-64アセンブラコードを入力とするツールを作りたいのですが
このアセンブラコードの文法に関する資料って何処にあるんでしょうか
ttps://llvm.org/docs/Extensions.html
ttps://sourceware.org/binutils/docs/as/
あたりにも各命令をどのように記述するかまでは載っていないように見えるのですが・・・
2020/08/17(月) 10:11:33.24ID:RiKJFl8Z
命令セットレベルの話ならインテルのマニュアルでも見ろとしか。
2020/08/17(月) 11:34:25.89ID:NVTg5S9X
>>843
Intelに大量の PDF マニュアルがあり、詳細に書いてある。
2020/08/17(月) 11:37:24.90ID:NVTg5S9X
>>843
LLVMツールの出力する、native の x86 や x64 のアセンブリコードは、
試してみる限り、masm 形式ではない。
見た目はgccの形式に似ている。
LLVMのarm版が出力したnativeアセンブリコードは、gccのgasが解釈して正しくobjファイル
までアセンブルできたことがある。
x86 や x64 の場合は、そこまでは試していない。
847843
垢版 |
2020/08/17(月) 12:59:34.65ID:WGW93JMF
ぶっちゃけパーサーをどう作るかって所なのですが

>>844-845
そうなのですが
１．CPUのマニュアルの命令表記とアセンブラの命令表記は例外なく一致するのか
　基本的にはマニュアル通りで良さそうですが表記に揺れがあった場合困る
２．リファレンスはAMDかIntelか
　この命令セットを設計したのはAMDだし処理系の対応もAMD64が先行していたはず
あたりはイマイチはっきりしないです

>>846
吐かれるアセンブラコードはGASベースで独自のディレクティブが追加されているように見えますね
2020/08/18(火) 01:12:29.19ID:xqTakpBf
>>847
命令表記は、8バイトのオペランド(や型)を表すのにdqwordとowordで表す
2つの流儀がある。
さらに、mmwordを使う流儀もあるが、浮動小数点演算のx87の文化では
浮動小数点でも専用の型名は無くて、dwordでfloat、qwordでdoubleを扱う
流儀があった。
そこにxmmやmmxのためだけにmmwordを持ってきた意図やセンスは
賛否が分かれるところだと思う。
2020/08/18(火) 01:28:37.97ID:xqTakpBf
>>847
x64のリファレンスは、原則的にAMDで、AMDにも詳しいマニュアルがある。
命令表記は、絶対アドレス addr に対する間接参照で、昔は、[addr]と
表記していたものが、x64だと、マシン語レベルでは絶対アドレスを埋め込まずに、
ripからの相対アドレスrel_addrを用いて、[rip+rel_addr]のような意味になっている
があるが、アセンブラレベルでそれを表記する時、どうするかと言う問題がある。

masmだと昔から、
mov eax,MyWork1
・・・
ret
MyWork dd 1234
と書いてきた。普通のアセンブラなら、
mov eax,[MyWork1]
・・・
ret
MyWork: dd 1234
と書くところを。
しかし、rip相対になった場合、
mov eax,[rip+MyWork]
と書くと意味に合わないし、かと言って、
mov eax,[rip+rel MyWork]
と書くのも長くなる。意味的には、Masmだと
mov eax,MyWork
なのだが、マシン語レベルでは、絶対アドレス/相対アドレスのどちらで表現されるか、
明確に表すことはできなくなるジレンマがある。
2020/08/21(金) 15:25:03.93ID:EskYTmRE
destにメモリを指定できる命令ってパイプラインをストールさせやすいように思うけどそんな事はないの？
x64だと
ADD r/m64,r64
みたいなの
2020/08/21(金) 20:30:50.01ID:+dwilF/E
確かにストールしやすいとは言えるが影響度合いはプロセッサ次第で、そういう命令を持ったプロセッサはちゃんと考慮した設計がされている。

例えばOut of Order実行を行うプロセッサはパイプラインに結果書込み待ちをするキューを持ったステージがあって、メモリ書き込み前に後続の命令を実行可能だから単純にストールはしない。

前後の命令に依存があればストールするのはレジスタ相手でも同じことだし、命令でロードとモディファイとストアを分けても実行する内容は同じなのだから、結局はプロセッサアーキテクチャ毎に最適化が必要なことには変わりがない。
2020/08/22(土) 00:25:14.47ID:Rco6UMRM
インテル(R) 64 アーキテクチャーおよび IA-32 アーキテクチャー最適化リファレンス・マニュアル
を良く呼んだら書いてあったわ
> 一般的に、各命令を構成するマイクロオペレーション（μOP）の数を考慮し、単一マイク
> ロオペレーション（μOP）の命令、4 マイクロオペレーション（μOP）未満の単純な命令、
> マイクロシーケンサー ROM が必要な命令の順で優先して、命令を選択すると良い。
> 〜
> ・複数のマイクロオペレーション（μOP）からなる一連の命令を分割できない場合は、
> 　同等の異なる命令シーケンスに分割する。例えば、読み出し−変更−書き込み命令は、
> 　読み出し−変更命令 + ストア命令に分割すると、高速化が可能である。この手法を利
> 　用すれば、新しいコードシーケンスが元のコードシーケンスより大きくなった場合で
> 　も、パフォーマンスが向上する。
らしいのでADD m64,r64みたいな命令はパフォーマンス上のデメリットがあるから使用を控えた方が良さそう
2020/08/29(土) 02:13:33.36ID:kcJTulzj
x64命令の動作を確認するのに対話式にアセンブル＆実行＆レジスタの確認が出来るツールとかないかな？
各値を変えながら試行錯誤したいけどソース書いてアセンブルしてデバッガに読み込んでステップ実行してだと手間すぎる

今MULのフラグの更新動作がAMDの資料を見てもIntelの資料を見てもググってももよく判らない
2020/08/29(土) 17:42:02.36ID:CDQjtNyx
>>853
フラグ類は、言葉で説明が難しいので、擬似コードで説明されている Intel の資料が
どこかにあるはず。
2020/08/29(土) 18:05:14.09ID:CDQjtNyx
>>853
Intel® 64 and IA-32 Architectures
Software Developer’s Manual
Volume 2A:
Instruction Set Reference, A-M

-------------------------------------------------
[MUL—Unsigned Multiply]
・・・
Flags Affected
The OF and CF flags are set to 0 if the upper half of the result is 0; otherwise, they
are set to 1. The SF, ZF, AF, and PF flags are undefined.
2020/08/29(土) 18:39:05.44ID:kcJTulzj
>>855
その文章は確認していてAMD64のドキュメントにも
>If the upper half of the product is non-zero, the instruction sets the carry flag (CF) and overflow flag
>(OF) both to 1. Otherwise, it clears CF and OF to 0.
と似たような記述があるんだけど双方の資料に書いてある"upper half"がどの部分を示しているのか判らない
演算結果の上半分が入るDレジスタの事？
2020/08/29(土) 19:05:00.05ID:CGaweZC2
>>856
Intelの日本語マニュアルには処理の疑似コードが載ってる。
これによると、上半分というのは、各命令で使うレジスタサイズの上半分とわかる。
8,16,32bitそれぞれ場合によって上半分の長さが変わるのでそう書くしかない。
だから64bitの場合の上半分は上位32bitになる。

操作
IF (NumberOfOperands = 1)
　THEN IF (OperandSize = 8)
　　THEN
　　　AX ← AL ? SRC (* signed multiplication *)
　　　IF AL = AX
　　　　THEN CF ← 0; OF ← 0;
　　　　ELSE CF ← 1; OF ← 1;
　　　FI;
　　ELSE IF OperandSize = 16
　　　THEN
　　　　DX:AX ← AX ? SRC (* signed multiplication *)
　　　　IF sign_extend_to_32 (AX) = DX:AX
　　　　　THEN CF ← 0; OF ← 0;
　　　　　ELSE CF ← 1; OF ← 1;
　　　　FI;
　　　ELSE (* OperandSize = 32 *)
　　　　EDX:EAX ← EAX ? SRC (* signed multiplication *)
　　　　IF EAX = EDX:EAX
　　　　　THEN CF ← 0; OF ← 0;
　　　　　ELSE CF ← 1; OF ← 1;
　　FI;
FI;
2020/08/29(土) 19:47:52.94ID:cC8g9MrB
upper half of the product だから乗算結果の上半分だ。
疑問の余地は無いと思うがな…
2020/08/29(土) 20:22:30.40ID:GYyhmMZY
CPU emulator Unicorn
https://www.unicorn-engine.org/
860デフォルトの名無しさん
垢版 |
2020/08/30(日) 01:05:43.21ID:BjChy3oe
IF sign_extend_to_32 (AX) = DX:AX
　THEN CF ← 0; OF ← 0;
　ELSE CF ← 1; OF ← 1;
FI;

これだと符号拡張したものと比較しているから、言葉による説明と違っている。
基本的に、mulは、符号無しの整数に対する掛け算なのだが。
2020/08/30(日) 01:11:49.03ID:BjChy3oe
>>857
それは、mul(符号無し掛け算)ではなく、imul(符号付掛け算)の擬似コードで、
英語版でも、同じような擬似コードが書いてあり、言葉による説明は、
次のようになっている:
Flags Affected
For the one operand form of the instruction, the CF and OF flags are set when signif-
icant bits are carried into the upper half of the result and cleared when the result fits
exactly in the lower half of the result. For the two- and three-operand forms of the
instruction, the CF and OF flags are set when the result must be truncated to fit in the
destination operand size and cleared when the result fits exactly in the destination
operand size. The SF, ZF, AF, and PF flags are undefined.
2020/08/30(日) 01:22:29.16ID:BjChy3oe
ちなみに、同じビット数の2つの整数の掛け算は、結果の内、掛ける前の整数の
ビット数の部分に限定した部分だけを見れば、符号付き掛け算と符号無し掛け算
で結果が変わらない。
一方、imulは、2オペランド以上のものは、結果のビット数が、掛ける前と同じ。
そして、mulは、2オペランド以上のものが用意されて無い。
これは、最初に述べた性質から、imulとmulで、2オペランド以上の場合では、
結果が変わらなくなってしまうため、imulだけで、符号無し掛け算にも対応できる
ためである。
863デフォルトの名無しさん
垢版 |
2020/08/30(日) 14:10:51.87ID:GgAZZaQa
https://www.youtube.com/watch?v=1EqyId5U8zA
https://www.youtube.com/watch?v=HOx7R3rgaTs
https://www.youtube.com/watch?v=M3x5J4jUYrc
https://www.youtube.com/watch?v=4ly0dPogeXY
https://www.youtube.com/watch?v=7EbNp1pDRPk
2020/08/30(日) 14:26:36.90ID:EVylyaDc
>>863
昔は大学教授しかこういう講義してなかったが、今は若い女の子が講義してくれるのかw
いい時代になったな
2020/08/30(日) 18:38:46.61ID:Oy/VxFsh
おっぱいしか目に入らん
2020/08/31(月) 15:24:59.40ID:r6h0vUdb
セクションとかも理解してくれるx64逆アセンブラとかないのかな
セクション情報やデバッグ情報をディレクティブ等でコードと一緒に出力してくれるとうれしい
2020/09/01(火) 10:42:01.73ID:vwihzMdy
>>864
昔は子供向けのベーマガに載ってるレベル。
2020/09/01(火) 17:43:15.76ID:8L3AfpS1
>>866
Linux？
869デフォルトの名無しさん
垢版 |
2020/09/03(木) 12:52:56.48ID:ZDuIxl5I
良い時代になった
https://www.youtube.com/watch?v=nUG_ymIss_s
https://www.youtube.com/watch?v=wEVe6XOojCM
https://www.youtube.com/watch?v=Ox2z9MYpRCg
2020/09/03(木) 14:20:08.59ID:cueCbpYZ
>>869
秋月に女の子が部品買いに来てるのなんて見たことないんだが、時代はそこまで来てるのか？
女の子がハンダごて握ってなんか作ってる姿は萌えるかも知れない
2020/09/04(金) 10:09:14.61ID:KmpQA39o
>>870
今時ネット通販だろうけど本屋と同じで
たまたま近くに置いてあるのに目が止まるのが良かったりするんだけどな
パートおばさんのハンダ付け作業なんて若年化する前にほぼ中国海外にいったろう
最近は新入社員研修に後ろから二人羽織状態で手を握りながら・・
2020/09/06(日) 06:21:38.35ID:EKeL4GkH
ドキュメント72時間で秋葉原の部品屋やってたけど
女子高生がオリジナルのペンライトを作るために来てた
2020/09/06(日) 09:40:26.46ID:TNZ7/NP8
良スレ
2020/09/07(月) 16:54:29.21ID:0bCSYOR0
欧米では女性も半田くらいできるけどな

https://makezine.jp/wp-content/uploads/2016/03/stock-photo-beautiful-woman-repair-soldering-a-printed-circuit-board-204001492.jpg
2020/09/07(月) 17:52:16.84ID:0w2E3x4d
>>874
撮影用のモデルだろ、半田が付いているのは裏面だ
2020/09/07(月) 18:30:23.60ID:3pB/Wjpj
それ以前に火傷する
2020/09/07(月) 18:41:49.64ID:hcXGR9uA
>>874
そんなとこ持ったら火傷で大変なことになってるw
撮影のとき誰も注意しなかったのかよ
2020/09/07(月) 22:17:45.58ID:KQEAaFWf
半田ごてを持つ部分が間違ってるし、基盤もハンダ付けする面は上下逆だし、
さあに、こういう基盤は、最近ではかなりの部分がロボットでハンダ付けしてると
聞いている。
2020/09/07(月) 22:44:57.51ID:0w2E3x4d
https://makezine.jp/blog/2016/03/beautiful-woman-soldering-stock-photo-wrong.html
880デフォルトの名無しさん
垢版 |
2020/09/08(火) 03:25:35.85ID:jacy6RM2
何周遅れか判らんくらい激しく概出過ぎてつまらん
2020/09/09(水) 19:36:30.15ID:HmJqfQ+A
>>875
そっちにもつっこみ所あったんか…今頃知った
2020/09/13(日) 00:55:43.99ID:NuGQj3YA
論理演算より、鼻筋の整形が気になって・・・
2020/09/25(金) 21:12:03.86ID:1nrszLVg
鼻の穴にもつっこむ所あったんか…
2020/11/02(月) 22:13:42.36ID:KqjMEGzA
775にしてはアルミ電解バリバリだな
2020/11/19(木) 16:32:15.09ID:7GrsSxFi
アセンブラからドライバを読みたいですが、どうやってしますか？
2020/11/19(木) 20:17:00.91ID:4w1/CW5J
日本語が変
887デフォルトの名無しさん
垢版 |
2020/11/25(水) 09:47:14.54ID:gT5in2ls
好奇心でMS-DOS 6.2にJWasmを入れてアセンブラ入門サイトを見ながら学習しています。
大きな値を10進変換したい場合はどうすれば良いのでしょう？
DX:AX ÷ 10dがしたい。

INT21hファンクションコールでAH=36hを実行してAX * BX * CXした結果を
DIV 10するのに、商が16ビットを超えるので例外が発生する。

入門中なので、2バイトまでの環境しか使い方がわかりません。

4バイトのレジスタが使えれば解決する話なのかも知れませんけど、、
DX:AXから計算する方法ないか調べています。
結局、EDX:EAXを10dで割る事になっても同じことが起きるので
2020/11/25(水) 12:44:21.97ID:jzvQX9aE
>>887
(1)まず、DXを10で割る。
その時の商をQ1(ax),余りをR1(dx)とする。
(2)
mov ax,元のAX
xor dx,dx　　;← dx=0
add ax,R1
adc dx,0
とする。これは、元のAXにR1を足したものを(dx:ax)に入れていることに相当する。
(3)
(dx:ax)を10で割り、商をQ2(ax)、余りをR2(dx)とする。
(4) 最終的な商Qは、(Q1:Q2), 余りRは、R2である。
2020/11/25(水) 12:46:48.67ID:jzvQX9aE
>>888
すまん。ちょっと間違った。(2)は正しくは、
(2)
mov ax,元のAX
とする。
これは、これは、(dx:ax)=(R1:元のAX)に相当する。

だった。
2020/11/25(水) 12:50:41.35ID:jzvQX9aE
コードに直すとこうなると思う。

;入力: (dx:ax)
;出力: (Q1:ax)=商, 余り=dx

mov original_ax,ax
mov ax,dx
xor dx,dx
mov cx,10
div cx
mov Q1,ax
mov ax,original_ax
div cx
;商=(Q1:ax), 余り=dx
ret
2020/11/25(水) 13:07:31.94ID:jzvQX9aE
>>887
32BIT(4バイト)命令を使っていいなら、(dx:ax)/10 は、
shl edx,16
mov dx,ax
mov eax,edx
xor edx,edx
mov ecx,10
idiv ecx
で、eax に32BITの商、edx に余り(0〜9)が出る。
2020/11/25(水) 13:12:20.82ID:jzvQX9aE
>>891
idivじゃなくて、divが正しい。
2020/11/25(水) 14:53:28.45ID:h9isg/D4
定数の除算に糞遅いDIV命令を使うとか
2020/11/25(水) 14:55:43.27ID:gT5in2ls
MUL BX
MUL CX
MOV Q2, DX
MOV Q1, AX
MOV BX, 10
DIV_LOOP:
XOR DX, DX
MOV AX, Q2
DIV BX
MOV Q2, AX
MOV AX, Q1
DIV BX
MOV Q1, AX
ADD DX, '0'
PUSH DX
OR AX, AX
JNZ DIV_LOOP

こんな感じですか？
気になったのですが、MOV DX, 0ではなくて、XOR DX, DXなのは処理が速いから？
CMP AX, 0よりも、OR AX, AXの方が良いのでしょうか？
2020/11/25(水) 15:47:06.05ID:T5VOSp5s
速いから
ではないでしょ
2020/11/25(水) 16:46:45.83ID:jzvQX9aE
>>894
>気になったのですが、MOV DX, 0ではなくて、XOR DX, DXなのは処理が速いから？
>CMP AX, 0よりも、OR AX, AXの方が良いのでしょうか？
昔は速かったので今でも伝統的に0を代入する変わりにxor reg,regを
使い、cmp ax,0の変わりに or ax,axを使う人が多い。
しかし、その「昔」とは、80486とかよりもずっと昔の初代8086の時代のことかもしれない。
ただし、xor reg,regだとフラグ類まで初期化されてしまうので、mov reg,0を使った方が
良い場合がある。

>>895
今は速くは無いが、昔は速かった。
その伝統が何故か今でも継承されている。
2020/11/25(水) 16:58:10.99ID:jzvQX9aE
>>894
冒頭の
MUL BX
MUL CX
の部分が怪しい。一行目で結果がDX:AXに入っているのに、二行目ではそれを
無視しているが、無視してはいけない。

また、最後の
OR AX, AX
JNZ DIV_LOOP
の判定は間違い。
これだと、Q2がまだ非0の場合にもループが終わってしまう。
ちゃんと、Q2が非0の場合もループを続行しなくてはならない。

また、Qは、商(quotient)の頭文字を使っただけで、伝統的には、
意味が余り分からない変数は、work1 などを使う慣例があったりする。
意味が分かる場合には、意味が分かるような変数名にする。
2020/11/25(水) 17:02:18.40ID:jzvQX9aE
なお、Q1は、説明の都合上、数学と似た感覚で短い変数を付けたが、
アセンブラなどに書く場合には、もっと長い名前にした方がいい。
短いとアセンブラが何かと混同して問題になるかも知れないから。
例えば、レジスタ名にr1などというものがある場合があるので注意。
2020/11/25(水) 17:44:43.84ID:h9isg/D4
>>896
伝統だけじゃない
メリットがある
2020/11/26(木) 00:21:00.79ID:5BVCYzUa
皆知ってるてのになw
2020/11/26(木) 01:11:06.89ID:lH6B10sG
>>899
では、現在のIntelCPUにおいて、
・mov reg,0の代わりにxor reg,reg
・cmp eax,0の変わりにor eax,eax
を使うメリットをそれぞれ書いてみてください。
2020/11/26(木) 12:23:04.16ID:kAbnbrOP
# mk_src.rb
def mk_src( md, loop1 = 1000000, loop2 = 1000 )
tit, fpath, asm_str = case md
when 1; [ 'imd', 'imd.c', %Q{\t\tasm( "movl $0, %eax\\ncmpl $0, %eax" );\n} ]
when 2; [ 'reg', 'reg.c', %Q{\t\tasm( "xorl %eax, %eax\\norl %eax, %eax" );\n} ]
end
File.open( fpath, 'w:UTF-8' ){|fh|
fh.print <<_EOT_
#include <stdlib.h>
#include <stdio.h>
#include <windows.h>

int main(void)
{
LARGE_INTEGER qpff, qpf0, qpf1;
QueryPerformanceFrequency( &qpff );

unsigned int n = #{loop2};
QueryPerformanceCounter( &qpf0 );
while( n-- ){
#{asm_str * loop1}
}
QueryPerformanceCounter( &qpf1 );
printf( " #{tit}. time %lf[ms]\\n", (double)(qpf1.QuadPart - qpf0.QuadPart) * 1000.0 / qpff.QuadPart );
return 0;
}
_EOT_
} # File.open
end

mk_src( 1 )
mk_src( 2 )
2020/11/26(木) 12:23:28.07ID:kAbnbrOP
$ uname -srvmo
MINGW64_NT-10.0-18363 3.1.7-340.x86_64 2020-09-22 20:54 UTC x86_64 Msys

$ gcc imd.c -O0 -o imd; gcc reg.c -O0 -o reg
8291652 imd.exe
6291780 reg.exe

$ ./imd.exe; ./imd.exe; ./imd.exe; ./imd.exe
imd. time 221.844800[ms]
imd. time 236.904100[ms]
imd. time 205.867200[ms]
imd. time 242.199800[ms]

$ ./reg.exe; ./reg.exe; ./reg.exe; ./reg.exe
reg. time 134.806000[ms]
reg. time 145.542900[ms]
reg. time 147.039100[ms]
reg. time 143.031100[ms]
2020/11/26(木) 12:58:51.67ID:lH6B10sG
Intelの最適化マニュアルを見たが、or,xor,cmp,movのlatencyやthroughputは
CPUによりマチマチで、絶対にどれが速いと言うようなことはいえないと思う。
ややこしいのは、movは、latencyが1や0.5, throughoutが0.5なのに対し、
xorは、latencyが1, throughtputが0.33や0.5となっていたりする。
これもCPUIDによってさまざま。
表の中のCPUIDの表記法も独特なので、どれが最新のCPUに対応しているのかも
個人的には今のところ分からない。
2020/11/26(木) 13:10:05.83ID:Ndl69lfH
>>904
常に最新の情報を見て一番いいものを使うのが正しいよね。
伝統とか言ってるようじゃダメ。頭が腐る。
2020/11/26(木) 14:55:11.18ID:l8W6EZba
馬鹿ほど脳みそ足りないからAppleのようにすぐ互換性を捨てたがる。
そんな馬鹿は伝統を重んじてきたx86系を使わないでほしい。
2020/11/26(木) 16:30:36.87ID:s+oX3EtE
>>896
不具合なければどっちでもよくね？
どっちかにしなければいけないほど古いPCを今でも使っている人？
2020/11/26(木) 18:31:44.20ID:b0/J9kY8
命令自体のクロック数は多少違うかもしれんがキャッシュ効率も考えれば1バイト命令のxor ax,axの方が正解の確率が高いと思うよ。
2020/11/26(木) 18:39:31.62ID:rqBz/pid
てかxor reg, regはIntelやAMDの最適化マニュアルにも書いてあるくらいなんだが
2020/11/26(木) 18:48:11.36ID:HK02mgb4
x86は386,486,586,686と拡張されてきて、その度に命令が拡張されてきてる。これらはどれもx86だが、
これらの互換性を取ろうとすると386に合わせるしかなくなる。しかしそれでは今のWindowsは動かない。
一般の人にとって互換性というのは普段使っているアプリケーションが動けばいいので、それでほぼ支障ない。

最近のIntel CPUはHaswell、Broadwell、Skylake、Kebylakeと来ているが、これらの間だけ見ても
命令が拡張されているので完全な互換性はない。ならば互換性を重視して、最新CPUの便利な機能を使うな
ということになると技術者のレベルは昔のまま上がらないことになる。それは時代に取り残されることにならないか。

386はシングルコアだったが今はマルチコアが当たり前の時代だ。しかしソフトウェアは今でもシングルコアを
前提に書くことが多い。その方が簡単だしそれでも動くからだ。しかし、搭載されているコア数を最初に見て、
マルチコアだったら並列処理できるところは並列で動かせば早くなるのがわかっていても。互換性のために
わざとそうしないとしたらそれはただの怠慢に過ぎないだろう。そういう人はx86系を使わないでほしい。
2020/11/26(木) 18:55:48.10ID:l8W6EZba
このように互換性捨てろという奴は頭悪いとよく分かる。
PowerPC、IA64、MIPSから何も学んでないのだ。
2020/11/26(木) 19:02:03.76ID:rqBz/pid
x86を捨てたがっているのはIntel自身なんだよなぁ
2020/11/26(木) 19:40:42.10ID:lH6B10sG
>>908
x86のXOR reg,reg, MOV reg,0 はどちらも2バイト命令でコード長は同じ。
Z80とは違う。
2020/11/26(木) 19:52:22.98ID:lH6B10sG
>>909
今見てみたら、xor reg,reg や sub reg,reg には「実行依存性」を断ち切る効果が
あると書いてあった。Pentium 4 から特別な扱いをする様になったとか。
つまり、xor reg,regだとフラグまで初期化してしまうので、フラグが決まるまで
Latencyを待つ必要が無い。
ところが、mov reg,0だとフラグは引き継ぐから前の命令によってフラグが
決まるまで次の命令の実行が待たされることがあるのかな。
もしかしたら、CPU内部では、ZF,CF,SFなどと独立して変更できずに、
EFLAGS全体を1つのレジスタの様に扱うことが基本になっていて、
一部だけを変更しようとすると待機が発生しやすくなるのかもしれない。
レス数が900を超えています。1000を超えると表示できなくなるよ。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況