アセンブラ初心者スレッド 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/

**デフォルトの名無しさん** · 2019/02/24(日) 11:13:53.47

>>385
そうなんだ

システムのプログラムフラシュ領域への自己書き込み

のインラインアセンブラシーケンスで使ったんだけど

プログラム追ってみたら割り込み許可情報のデータ退避して復帰してる感じだった

無事マイコンの自己プログラミングできた

ありがとう

**デフォルトの名無しさん** · 2019/02/24(日) 14:37:48.95

>>387
+1
変態め

**デフォルトの名無しさん** · 2019/02/24(日) 14:42:53.37

日本でMIPSだとプレステが有名だが・・・

**デフォルトの名無しさん** · 2019/02/26(火) 17:30:06.50

z80,68000,ia32 ならちょっとわかる

**デフォルトの名無しさん** · 2019/02/27(水) 15:03:03.39

x86でNASMでELFを組んで学習しているのですが、_startの処理でstack frame設定の処理に質問があります
_startからジャンクデータを残さずEIP,ESPを整えて_exitを呼び出す方法を教えてください
（#立つ鳥後をEAX/EIP以外濁さず、を行いたい理由があります）
_exitはnoreturnで、int 0x80によるsystem_call()、又はSYSENTER(0f 34)によるia32_sysenter_target()
を用いて、SYSCALL_VECTOR又はMSR_IA32_SYSENTER_EIP(0x176)が呼ばれます
通常の_startにおけるlibcの処理では、auxvの中、AT_SYSINFO_HEDR(33)から、vDSO内の
__kernel_syscall_via_epcを経てカーネルへ向かうとの説明です
EXTERN _exit
GLOBAL _start
SECTION .text
_start:
push dword 42
call _exit
をnasm -f elf x.asm; gcc -Wall -s -nostartfiles x.o -o x.outで動きますが、
gccの方でlibgcc.a(-lgcc)やlibc(-lc)が自動で追加されるからなので、
-nostdlibや-nodefaultlibsではSegfaultします。ここの処理の理解のためにcrt0.oを眺めていると,
xor %ebp,%ebp ; stack frameの土台を用意
pop %esi ; [argc][argv][envp][auxv]... で一番上のargcをesiに
...（以下_libc_start_main処理）となり最終的に
sys_exit（int 0x80,eax = 1 (sys_exit),ebx = return code）が呼ばれていました
ソースを眺めると、$grep -r "NR_exit[^_]" /usr/include/
/usr/include/asm/unistd_32.h:#define __NR_exit 1
/usr/src/linux/include/uapi/asm-generic/unistd.h:__SYSCALL(__NR_exit, sys_exit)から
/usr/include/sys/syscall.hから
/usr/src/linux/arch/x86/kernel/entry_32.S:ENTRY(system_call)まで辿り着きましたが、
gdbでスタックを眺めてもいまいち要領が得ません
流れとして、stack->auxv[]->AT_SYSINFO_EHDR->VDSO32_vsyscall->__kernel_vsyscall->CUP依存のコピペ先へ
という理解なのですが…もしかして_start時のスタックの状況に勘違いがあるのでしょうか？
参考にしているのはA Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linuxです

L · 2019/02/27(水) 16:16:22.81

>>392
直感からすると、原因は、esp に一度も値を設定していないことが最も疑わしい。
stdlib などがリンクされている場合、start up コードの中で、esp の値が
設定された後に、main などの自分のコードへと実行が移されるが、
-nostdlib などを付けた場合、リンク時に指定した entry point から
実行が開始される。今の場合、リンク時に entry point を指定していよう
なので、恐らく、最初の object file であるところの x.o の先頭アドレス
であるところの _start かｒ実行が開始される。

push dword 42 を行ったとき、esp の値が 0 か、または、0x7fffffff などの
値になっているため、segment fault や general protection fault などが
生じると思われる。

ここまでは全て記憶と直感に頼って書いた。

**デフォルトの名無しさん** · 2019/02/27(水) 16:18:53.04

誤：リンク時に entry point を指定していよう
正：リンク時に entry point を指定しないよう

すまないが、あなたの書き込みの全部は読んでおらず、最初の方の
数行を見ての直感で答えた。

**デフォルトの名無しさん** · 2019/02/27(水) 16:23:18.32

>>393
すまん。

esp だけでなく、ss の値も重要。
mov ax,ds
mov ss,ax
などとした方がいいかもしれない。

一番重要なのは、_start: の直後あたりに、

mov esp, (何らかのメモリバッファの底のアドレス)

とする事。メモリバッファは、自分で用意する。
アセンブラ初心者なら、masm なら、db 命令などで領域を静的に
確保し、その最後のアドレスあたりを指定すると良い。

なお、esp を設定するまでは、push, pop, call は行ってはならない。

L · 2019/02/27(水) 16:37:51.36

>>392
「x86」と言っても、OS によって変わってきて、Windows などなら、確か、
ライブラリを全くリンクしない場合でも、最初から esp は、一応、
「使える状態」に設定されていたと(心の中に)記憶している。
つまり、esp は、最初からOSが用意した何らかのメモリ・ブロックの底に
設定された状態で exe の実行が開始されると思う。

組み込みなどでは、esp の値は 0 みたいな値になっているかもしれない。

L · 2019/03/04(月) 12:10:03.33

>>392
gdb が使える状態なら、
・レジスタ ss, esp がちゃんと「正しい」値になっているかチェックする。
・ss == ds なのか、ss = 0 なのか、ss は 0 ではないか、ds とは別の値なのか。
・call _exit の部分の飛び先アドレスがちゃんと正しい相対アドレスになっているか
　確認する。---> 正しくリンクされていない場合もあるため。

_exit 関数が shared library の中にあるような場合、処理系によって call 文がどのような
マシン語になるかは変わってくる場合がある。リンカが、call [addr] 形式の indirect call
を想定する場合と、
call import_func
・・・
import_func:
jmp [_exit_entry]
・・・
_exit_entry dd _exit

などのようになる場合など、さまざま。それが正しくなっているかの確認も必要。

**デフォルトの名無しさん** · 2019/07/04(木) 19:46:17.60

今時のIA32コードを吐く処理系がよく使う命令についてのまとめた資料ってないですかね
486DXあたりでもかなりの命令数になりますが現行で使われている命令は限定されますよね？

**デフォルトの名無しさん** · 2019/07/05(金) 11:29:01.09

>現行で使われている命令は限定

何言ってんだ

**デフォルトの名無しさん** · 2019/07/05(金) 19:14:34.33

x86系は現行のアーキテクチャとしては間違いなくカオス組。解析器とか作りたくねー

**デフォルトの名無しさん** · 2019/07/21(日) 02:41:27.70

intelで公開している奴じゃなくて？

**デフォルトの名無しさん** · 2019/10/06(日) 15:58:10.24

x86 の条件付きジャンプ命令

JG Greater
JL Less
JE Equal
JNE Not Equal
は分かったのですが、
JA
JB
は何の英単語の略なんでしょうか？

**デフォルトの名無しさん** · 2019/10/06(日) 16:06:45.50

aboveとbelowだったかな

**デフォルトの名無しさん** · 2019/10/06(日) 17:14:52.78

おお、なるほど！
素早いご回答ありがとうございます

**デフォルトの名無しさん** · 2019/10/06(日) 17:29:21.50

https://codeday.me/jp/qa/20190731/1353200.html
おかげさまでこちらのページを見つける事ができました
間違いないようです

**デフォルトの名無しさん** · 2019/10/06(日) 17:30:39.06

昔は常識だった

**デフォルトの名無しさん** · 2019/10/21(月) 09:51:46.99

アセンブラ買ったらリファレンス一冊ついてたしな...
今ならintelのpdf先に見る所?

**デフォルトの名無しさん** · 2019/10/24(木) 10:43:50.55

古いのなら日本語マニュアルあるぞ

インテルエクステンデッド・メモリ64テクノロジ・ソフトウェア・デベロッパーズ・ガイド第1巻
インテルRエクステンデッド・メモリ64テクノロジ・ソフトウェア・デベロッパーズ・ガイド第2巻

直リンクはちょくりんＮＧで貼れないのでググッて

**デフォルトの名無しさん** · 2019/10/24(木) 10:52:31.09

なんで５ｃｈでＮＧワード扱いされてるんだろうな
全部全角にしてみた

ｈｔｔｐｓ：／／ｗｗｗ．ｉｎｔｅｌ．ｃｏ．ｊｐ／ｃｏｎｔｅｎｔ／ｄａｍ／ｗｗｗ／ｐｕｂｌｉｃ／ｉｊｋｋ／ｊｐ／ｊａ／ｄｏｃｕｍｅｎｔｓ／ｄｅｖｅｌｏｐｅｒ／ＥＭ６４Ｔ＿ＶＯＬ１＿３００８３４０２＿ｉ．ｐｄｆ
ｈｔｔｐｓ：／／ｗｗｗ．ｉｎｔｅｌ．ｃｏ．ｊｐ／ｃｏｎｔｅｎｔ／ｄａｍ／ｗｗｗ／ｐｕｂｌｉｃ／ｉｊｋｋ／ｊｐ／ｊａ／ｄｏｃｕｍｅｎｔｓ／ｄｅｖｅｌｏｐｅｒ／ＥＭ６４Ｔ＿ＶＯＬ２＿３００８３５０２＿ｉ．ｐｄｆ

**デフォルトの名無しさん** · 2019/10/24(木) 11:01:40.57

EM64T_VOL1_30083402_i.pdf
EM64T_VOL2_30083502_i.pdf

どうみてもこれで充分です
ほんとうにありがとうございました

**デフォルトの名無しさん** · 2019/10/24(木) 11:12:11.26

英語のマニュアル
https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf

**デフォルトの名無しさん** · 2019/10/25(金) 15:41:34.61

>>406
8086のアセンブラと言えば、PC-9801とBASICやMS-DOSの組み合わせだが、
当時パソコンを持っていた人はBASICは知っている人が多く、C言語は
好き物が理解していたが、アセンブラまで理解している人は稀で、
ja の a が above であることを知っている人はごく一部だった。

**デフォルトの名無しさん** · 2019/10/25(金) 16:36:39.41

>アセンブラまで理解している人は稀

あほすぎ
お前のまわりがそうだっただけだろ

**デフォルトの名無しさん** · 2019/10/25(金) 17:38:11.71

>>412
当時、The BASICやASCIIでBASICとアセンブラで組んだゲームが山ほど掲載されてた。
同じことをしたいと思ったら8086のアセンブラ知らないとどうしようもなかったんだよ。
BASICはエラー出しても止まってくれたけど、アセンブラでエラー出すとそのままマシンが固まったり
勝手にリブートしたりして何度も泣いたもんだ。けど同時に非常に面白かった。
アセンブラで「どこか1カ所でもミスったらマシンが飛ぶ」と思ったら緊張感がハンパない。
「これで絶対動く」という確信が持てるまで何度も見直してから、震える指でエンターキーを押して
動いたときの感動。立ち上がって全身でガッツポーズしたね。
プログラミングの醍醐味はこれだよ。これ覚えたらもう止められない。

**デフォルトの名無しさん** · 2019/10/25(金) 18:16:12.88

俺自身はアセンブラは使ってたよ。
しかし、一般的にはそんなに使われている訳ではなかった。
プロのゲームプログラマやそういう雑誌に掲載されたゲーム作者は使っていたが。
そういう人たちは特殊だったので、天才プログラマなんて言葉が生まれた。

**デフォルトの名無しさん** · 2019/10/25(金) 18:21:42.17

>>414
そういうことを言うと、当時を知らない人はアセンブラなんて誰でもやっていた
などという嘘を信じてしまう。

**デフォルトの名無しさん** · 2019/10/25(金) 21:14:38.60

>>416
誰でもやってたなんて言ってないんだが。やってた人もけっこういたって程度だろう。
もっと正確に言うなら、当時プログラムをやってた人の総数と、そのうちアセンブラをやってた人が何割いたか
という統計データでも探してこないと正確な割合は出ない。
ただ、そういう本が何冊も出てたってことはそれだけ売れてたってことだから、程度の差はあれ、
アセンブラに興味があった人がそれなりにいたことは間違いない。

**デフォルトの名無しさん** · 2019/10/25(金) 23:59:54.86

>>417
ja の a が above の意味であることは知っていても、ja が直前の cmp 命令と
組み合わせて使うことや、グラフィックを描くにはG-VRAMと呼ばれる場所に
数値を書くということまでちゃんと理解できた人が少なかった。

**デフォルトの名無しさん** · 2019/10/26(土) 02:40:13.17

>>418
PC雑誌、アセンブラのドキュメントと初級解説本、9801の解析本くらい読めば普通に書いてあった。

**デフォルトの名無しさん** · 2019/10/26(土) 02:52:45.09

>>419
今現在、プログラミングしている人の大部分は、スクリプト言語しか使えない
と言われている。その理由は、ポインタが理解できないから。
ポインタが理解出来ない人は、アセンブラの間接参照 [reg + addr]
も理解できないだろうから、アセンブラではグラフィックもまともに描けない。

当時の常識といっても、今のパソコン使いが当時にタイムスリップしても
大半はアセンブラを理解はおろか使いこなすなど出来ない。

**デフォルトの名無しさん** · 2019/10/26(土) 09:59:09.07

>>417
>当時プログラムをやってた人の総数と、そのうちアセンブラをやってた人が何割いたか

今より遥かに高い割合で居ただろう

**デフォルトの名無しさん** · 2019/10/26(土) 18:30:52.81

>>420
一般の人はアセンブラなんて見たこともないだろうから別にそれはそれでいい。
プログラマーだってアセンブラが使いにくいからC使ってるわけだし。
ただ、アセンブラやっとくとCPUの動作が直にわかるし、簡単なプログラムでも超高速に動く。
Cからアセンブラコードを生成して、内部でどんな処理してるか調べることもできる。
そういうところが面白いと思う人がやればいいんだよ。

**デフォルトの名無しさん** · 2019/10/26(土) 22:35:07.76

CASL2の話題はこのスレでしていいですか？

**デフォルトの名無しさん** · 2019/10/27(日) 02:06:55.94

上の流れ見るに90年代が華の野郎共の巣だから2はわかんないかも(笑

**423** · 2019/10/27(日) 10:41:06.65

>>424
気になりませんよ
ありがとうございます

**デフォルトの名無しさん** · 2019/10/27(日) 11:40:07.17

試験科目LLVMにすれば良いのに

**デフォルトの名無しさん** · 2019/10/27(日) 12:56:27.43

普通にゲームしかやらんやつの方が多かっただけで
できるやつが少ないかったのは事実

**デフォルトの名無しさん** · 2019/10/27(日) 17:04:26.06

>>427
比率で言えば大体黄金比(2:6:2)になる。昔も今もプログラマーで本当にできるのは上位2割、
全く向いてないのが下の2割、まあまあ普通なのが真ん中の6割。
スクリプトしか書けないのはこの6割の中に入る。上位2割はスクリプトなんてちょっとやればわかるから
何とも思ってない。文字通りレベルが違うから話も合わない。でもそれでいいんだよ。

**デフォルトの名無しさん** · 2019/10/27(日) 17:50:07.64

最も利用率が高いのはRubyだが
マイコン相手にすればアセンブラとにらめっこだし
気に入らないが必要とあればC/C++やPythonやJavaScriptも触る

**デフォルトの名無しさん** · 2019/10/28(月) 09:34:47.25

80年代はアセンブラ関連の書籍がたくさんあった
Z80、6809、8086、68000
まだ1989年頃まではCコンパイラが高価だったりして敷居が高かったし
BASICやってた人は高速化するにはマシン語を使ってたしな
アセンブラやマシン語初心者向けのBASICから使えるマシン語の本もたくさん出てた
アセンブラやマシン語を使ってゲームを作る本とかな
電子工作関連でもZ80のアセンブラや周辺LSIのプログラミングで初心者向けの本がたくさんあった
アセンブラ覚えるなら1980年代や1990年代初め頃の方がずっと恵まれてたな
図書館の蔵書とか検索してみるとそういう古い本が出てくるかもよ

**デフォルトの名無しさん** · 2019/10/28(月) 09:46:48.07

今と違って1980年代中ごろまではBASICがメインだったし
ゲームしかやらない人を除けば1980年中ごろまでのパソコンユーザは
プログラミングができるのが当たり前だった
だからパソコンユーザの中でアセンブラもやってた人は多かったよ
そもそもパソコンを扱える人自体が今と違って少なかった
プログラミングに興味がない人はそもそもパソコンにも興味がなかったからな

**デフォルトの名無しさん** · 2019/10/28(月) 09:58:42.55

>>416
当時はパソコンを趣味としてやってる人自体が少なかった
パソコンに興味のない普通の人はキーボードなんて叩いて何が面白いのとかそういう認識
パソコンなんてわけのわからないそんなつまらないものなんでやってるのって感じ
そういう感じなんでパソコンユーザは根暗とかオタクとか言われて馬鹿にされてたからな

**デフォルトの名無しさん** · 2019/10/28(月) 10:04:22.32

>>427
そのゲームが一番アセンブラやマシン語を必要としてたんだよな

当時、雑誌にゲームを投稿してた人のインタビュー
https://akiba-pc.watch.impress.co.jp/docs/sp/1213044.html

**デフォルトの名無しさん** · 2019/10/28(月) 10:06:00.01

マシン語　ゲーム
この2つのキーワードで検索してみると80年代のアセンブラやマシン語の本がたくさん出てくる

**デフォルトの名無しさん** · 2019/10/28(月) 15:42:16.95

>ゲームしかやらんやつの

ゲームで遊んでた人と
ゲームを造ってた人を
意図的に混同してるだろ

しかもそもそもマ板の話題だし
ム板でするな

**デフォルトの名無しさん** · 2019/10/28(月) 15:55:47.51

>>431
アセンブラは、本を買ってみたりした人は多かったかもしれないが、
実際に使いこなすまでにいたった人は稀だったはず。
だから、アセンブラやマシン語は難しいという認識だった。

なお、ちょっと話がずれるが、LLVM は、型の部分が煩雑で普通のアセンブラよりも
難しい部分がある。
構造体型を使わなければ普通のアセンブラと同じように出来ないことは
ないが、それでも、bitcast などを頻繁に繰り返す必要がある。
なお、構造体型をヒントに最適化している可能性があるので、面倒でも
構造体型を使う必要があるかもしれない。
上手く整理して理解しないと、コンパイラを作る人泣かせになる。

**デフォルトの名無しさん** · 2019/10/28(月) 19:16:09.04

80年代後半だが電子系の学生なら講義でZ80のアセンブラやらされてな

**デフォルトの名無しさん** · 2019/10/28(月) 21:16:27.78

RAM640KBでCとかほぼ無理だろ
X68000でも4MB以上推奨だった記憶

◆QZaw55cn4c · 2019/10/28(月) 23:13:33.30

>>430
書籍もそうだが、i486 の時代になっても ms-dos が動き、プロテクトモードは自由に触り放題、というのが当時はすばらしかった
今はプロテクトモードは触らしてもらえない、マシン語化する価値があるものは、キャリーフラグを触れば速くなるもの、くらいしか思いつかない

**デフォルトの名無しさん** · 2019/10/29(火) 01:38:16.40

>>438
当時、Turbo C などが結構使えていた。ところが、リアルモードや
仮想86モードのx86には、640KBの壁ではなく、64KBの壁があった。
それがかなり問題だった。

**デフォルトの名無しさん** · 2019/10/29(火) 01:52:33.06

>>439
>今はプロテクトモードは触らしてもらえない、
最初からOSがプロテクトモードにしてくれている。

MS-DOSで自力でプロテクトモードにするのはかなり大変だったのでずっと
楽になってる。というのは、プロテクトモードにした場合、DOS
は、仮想8086モードで動かさないといけなかった。しかし、そうするためには
非常に膨大なプログラミングが必要になった。仮想8086モードは、設定すれば
すぐ動くわけではなく、割り込みテーブルなどを全部自分で用意しなければ
ならなかったから。割り込みテーブルもテーブルを用意すれば終わりではなく、
ほとんどエミュレータの作成をしてる感じで、32BITプログラムを用意して、
16BITコードでsti,cliやint命令なんかが実行されるたびに、エミュレーション
ハンドらが起動されて、そこでしかるべき処理を行う必要があった。
だから、自力でDOSをプロテクトモードにするのはほとんど不可能で、
DPMIやVCPIという既存のプログラムが利用された。
しかし、それらをまともにつかうのは、TURBO C++などの16ビットコンパイラ
では無理だった。

**デフォルトの名無しさん** · 2019/10/29(火) 02:03:23.94

>>441
DOSで32BITアドレッシングを使うのは、非常に複雑で、80386系CPUの
欠陥か、または、Windowsを売るためにわざとDOSでは32BITアドレッシング
を使いにくくしていたかのどちらかと考えられる。
DOSにおいても、32BITレジスタは簡単に使うことが出来たので、32BITデータ
を読み込んだり32BITで加減乗除を行うのは簡単に出来た。ところが、
アドレスを32BITにすることは原則的にはできなかった。
既に、EMSメモリを使うために、プロテクトモードは使われてしまっており、
DOSは仮想8086モードで動いていた。そのせいで、自作プログラムで勝手に
プロテクトモードをコントロールすることは不可能だった。
というのは、プロテクトモードは、最初にそれを行ったプログラムが
支配者の様になり、他のプログラムは、支配される側としてしか動作できない
仕組みになっていたから。だから、EMSメモリ用の「支配する側のプログラム」
が対応していない限り、支配される側の一般プログラムは、32BITアドレッシング
を使うことは出来なかった。

そのために容易されたのが、VCPIとDPMI。ところが、まともに32BIT
アドレッシングを使うのはVCPIでは難しかったが、DPMIに対応したEMS
ドライバは限られていた。しかも、DPMIを使うにはC/C++コンパイラもそれに
対応していなくてはならなかった。それで、結局、DOSで32BITアドレッシング
を使ったアプリは非常に限られたものとなってしまった。

それが、Windowsが使われた一つの理由、Windowsは、最初から32BITアドレッシング
が使えるようになっていたから。実は、Wintel同盟なるものがあり、恐らく
DOSでは32BITアドレッシングを自由には使えなくするために、80386系CPU
をわざと変な風に設計したのではないかと疑っている。
一般の人は、そんな裏事情を知らない。

**デフォルトの名無しさん** · 2019/10/29(火) 07:05:18.63

DOSでは京都マイクロコンピュータが
DOSエクステンダーのEXE386を非商用で実費で配布しててパソコン通信で無料で配布
商用でも1000コピーで100万円くらいで売ってたがそれに対応したコンパイラが高価だったな
海外ではDJCPPがあったが日本ではあまり普及しなかったし、商用ソフトでは使われなかった
唯一の例外はFM-TOWNS
初めからDOSエクステンダーが組み込まれて32bitのDOS環境が使えた
公式のアセンブラが非常に高価でCコンパイラもその高価なアセンブラが必要で
一般ユーザには普及しなかったがFM-TOWNS用にDJCPPが移植された
そのTOWNS用に移植されたDJCPPがEXE386を使うことでPC-98でも使えたが
PC-98ではあまり普及はしなかった

DOSで32bit環境が整ったのがWindows 95が発売される直前
Borland CやWATCOM CなどでCコンパイラにDOSエクステンダーを付けて販売するようになったが
Windows 95が出てみんなもうDOSには興味がなくなっていた

>>442
Windows 3.1まではまだセグメントの64KBの壁があったけどね
Windows 3.1用に32bitのフラットなアドレスが扱えるWin32sが出たね
Win32sはあまり普及はしなかったが

**デフォルトの名無しさん** · 2019/10/29(火) 07:09:00.71

DJCPPじゃなくてDJGPPだった

**デフォルトの名無しさん** · 2019/10/29(火) 07:24:26.40

アセンブラに話を戻すと
DOSエクステンダーのEXE386はMASMの5.0以上やTurboAssemblerなどのアセンブラで
EXE386上で動作するアプリを作れた
プロテクトモード上の特定のアドレスにVRAMがマッピングされていたので
VRAMへのアクセスも容易だったな

そのEXE386は今でもベクターからダウンロードできる

**デフォルトの名無しさん** · 2019/10/29(火) 17:54:53.05

>>445
当時、ほとんどのアプリは基本ロジック部分はC/C++言語で書いていて、
グラフィックなどの速度が必要な部分をアセンブラで書くということをやっていた。
だから確かにアセンブラからは32BITアドレッシングは可能であっても、
C/C++が使えなければ現実的に使うことは無理であった。
だから、何らかのC/C++コンパイラが必要となった。それが結構高価であった
ことと、既にWin95に一般民が移行していたので選択の余地は狭かった。
ただし、移行というより、1995はパソコン元年などといわれたくらい、
初めてパソコンを使い始める大挙して押し寄せた。
だから、DOSエクステンダは魅力的ではあっても、その流れに逆らうことは
難しかった。

**デフォルトの名無しさん** · 2019/10/29(火) 18:03:50.25

俺の質問めっちゃ低レベル…

LDやSTなどの命令やオペランドは主記憶に記憶されることは分かったんですが、
コメントも同様に、オペランドとかの後に記憶されているんですか？

**デフォルトの名無しさん** · 2019/10/29(火) 18:11:29.42

>>447
一般的な処理系ならコメントはアセンブル時に削除される

**デフォルトの名無しさん** · 2019/10/29(火) 18:48:08.61

今でもはじめて読む8086読んどけかと思えば絶版なのかな...amazon在庫無いね

◆QZaw55cn4c · 2019/10/29(火) 19:01:39.60

>>441
＞プロテクトモードにした場合、DOSは、仮想8086モードで動かさないといけなかった。
いいえ、リアルモードで DOS を起動して、ユーザープログラムが勝手にプロテクトモードに変更してなんら問題ないですよ
プロテクトモードから一時的にリアルモードに戻ることはできませんが、プロテクトモードで割り込みテーブルを再設定すれば問題ないですね

＞自力でDOSをプロテクトモードにするのはほとんど不可能で、DPMIやVCPIという既存のプログラムが利用された。
まあそれは事実ですが、あと DOS エクステンダーがよく使われましたね

◆QZaw55cn4c · 2019/10/29(火) 19:02:55.89

>>442
＞既に、EMSメモリを使うために、プロテクトモードは使われてしまっており、
＞DOSは仮想8086モードで動いていた。そのせいで、自作プログラムで勝手に
＞プロテクトモードをコントロールすることは不可能だった。

EMS なんて非常に使いにくいものはさっさと追放しちゃえばよかったのですよ

◆QZaw55cn4c · 2019/10/29(火) 19:03:56.60

>>442
＞DOSでは32BITアドレッシングを自由には使えなくするために、
66 プレフィックスか 67 プレフィックスで無問題だったかと

**デフォルトの名無しさん** · 2019/10/29(火) 19:36:42.19

まず
80286ではプロテクトモードからリアルモードに戻ることが出来なかったため
戻るために特殊な仕組みが必要になり、プロテクトモードが非常に使いにくかった

386以降は、単純にリアルモードに戻ることが可能になったため使いやすくなり
セグメントのリミットを設定し直してそのまま戻ることで
リアルモード(DOS)から4G全てにアクセスすることも出来るようになった

そして、仮想86モードでの割り込み処理も、別に複雑な処理などは基本的には必要ない
なぜならBIOSにある、元の割り込み処理ルーチンに処理させれば良いだけだから
もちろんIDTをセットアップして処理するプログラムは用意する必要はあるが
大半はスタックにあるリアルモードでの戻り番地等を設定して、
あたかもリアルモードで割り込みが起こったかのようにBIOSやDOSの割り込みベクタテーブルのアドレスに飛ぶだけ

自前で処理する必要があるのは、GPフォルトやページフォルト、
それにA20の操作の処理が入ったらページテーブルを書き換える等するだけ
その程度でも、HMA64KやUMBを用意して空きメモリに余裕があるDOSを動かすくらいなら出来た
(ただし、DMAにも対処するにはまた別途処理が必要)

もちろんEMS等に対応するには、そのための処理ルーチンを用意する必要があるし
EMSやVCPI程度ならともかく、DPMIにも対応するとなると、かなり面倒くさかっただろうとは思う

**447** · 2019/10/29(火) 19:46:30.39

>>448
ありがとうございました
ちょっとショックです…

**デフォルトの名無しさん** · 2019/10/29(火) 21:10:57.31

>>449
Amazonに「64ビットアセンブラ入門」というのがある。

**デフォルトの名無しさん** · 2019/10/29(火) 21:13:34.56

>>454
コメントは実行に関係ないから削除されて当たり前なんだが、
それがショックという意見は始めて聞いた。なぜ？

**デフォルトの名無しさん** · 2019/10/29(火) 21:41:39.59

アセンブラでガリガリ書きたい人は、フルアセンブラで書いたOSがある。
プログラムもアセンブラで書く。サンプルプログラムもたくさんある。
DOSのように終わったOSではないので、今のPCにもインストールできる。
Kolibriは初期のMenuetからフォークした32bit OS。Menuetは64bit。
面倒なアドレッシング制限もなく、画面表示も簡単にできる。
日本語にはまだ対応していないので、誰かが日本語化すればユーザが増えるかも。

menuet os
http://www.menuetos.net/

kolibri os
http://kolibrios.org/en/index

**デフォルトの名無しさん** · 2019/10/29(火) 21:48:10.11

>>452
そのプリフィックスは、データ用とアドレス用のものだけど、
データ用の方はどのモードからも普通に使えた。ところが、
アドレス用の方はプロテクトモードでしか使えず、
仮想8086モードでも使用不可能になっていた。
それが、Wintel同盟がDOSを使えなくしてWindowsだけを使えるように
するための策略だったのではないかと疑っている
（そんな風に設計する理由は特に無かったのに。）。

**デフォルトの名無しさん** · 2019/10/29(火) 22:01:50.22

>453
>そして、仮想86モードでの割り込み処理も、別に複雑な処理などは基本的には必要ない
>なぜならBIOSにある、元の割り込み処理ルーチンに処理させれば良いだけだから
>もちろんIDTをセットアップして処理するプログラムは用意する必要はあるが
>大半はスタックにあるリアルモードでの戻り番地等を設定して、
>あたかもリアルモードで割り込みが起こったかのようにBIOSやDOSの割り込みベクタテーブルのアドレスに飛ぶだけ

ここは言うほど簡単ではなかった。まず、32BITモードから仮想8086モードの
サブルーチン(割り込みハンドラも）を呼ぶ方法がcall命令としては用意されて
いなかった。だから、32BIT--->V8086モードへは、call命令から帰るリターン命令
の一種であるところのiret命令を使わなくてはいけなかった。その設定が細かい話
になるので細心の注意が必要であった。さらに、V8086--->32BITモードの
呼び出し元へ戻る際には、ret命令ではなく、コールゲートに対する特殊な
call命令か、int命令を用いなくてはならなかった。しかし、もともとのDOSの
割り込みハンドラの最後の部分にはそんな命令が書かれているわけは無いので、
工夫が必要であった。割り込みハンドラから戻ってくるアドレスに、
コールゲートに対するcall命令か、32BITモードに対するint命令かを
「仕掛けて」おく必要があった。どっちにしろ、それはもともと戻るための
命令ではないものを戻る命令として用いているので、スタックなどをきちんと
戻すためには細心の注意が必要だった。
さらに、二重に割り込みが入ったような場合に対応させるためにも、
非常に注意深くスタックの構造を設計しておく必要があった。それは、
32BITモードと16BITモードスタックのの二重構造だった。というのは、
80386のスタックは、32BITモードと16BITモードで全く別の領域を
使う仕組みになっていたので、連続的にすることはできなかったためである。

**デフォルトの名無しさん** · 2019/10/29(火) 22:02:17.16

>>453
>386以降は、単純にリアルモードに戻ることが可能になったため使いやすくなり
>セグメントのリミットを設定し直してそのまま戻ることで
>リアルモード(DOS)から4G全てにアクセスすることも出来るようになった

ここも、隠れ機能としてそういうものがあると聞いたことがあるが、
多分、ちゃんと公表されていなかったのではないかと思う。

**デフォルトの名無しさん** · 2019/10/29(火) 22:38:00.70

>>452
66、67プレフィックスは使えても64KBを超えるオフセットになると一般保護例外が発生する
もう、誰かが書いてるが一度、プロテクトモードに入ってセグメントリミットを設定しなおして
リアルモードに戻れば一般保護例外は発生しなくなるけど、
他のプロテクトモードを使うソフトを一緒に使ってる場合、不具合が発生する可能性はあった

**デフォルトの名無しさん** · 2019/10/29(火) 22:40:47.58

>>449
ネットをごにょごにょすれば・・・

あ、誰か来たようだ

**デフォルトの名無しさん** · 2019/10/29(火) 22:46:10.13

>>461
Intel公式には、プロテクトモードからリアルモードに戻る方法は無いはず。
確かCPUリセット直後の特殊な状態でごにょごにょすると聞いたような。

**デフォルトの名無しさん** · 2019/10/29(火) 22:55:18.61

>>463
記憶をたどれば、確か、セグメントリミットを4GBに設定したセグメントエントリ
を持ったGDTテーブルを用意してその先頭アドレスをGDTRに入れた後、
確か、CR0 の BIT をいじった後、far jmpを行うとプロテクトモードに入るが、
far jmpを行わなければ、中途半端な状態になって、4GBアクセスできる
リアルモードになるんだった気がする。だから、その後、far jmpを行うと
モードが切り替わってしまうので、その命令は、アプリが暴走しても
絶対に使っちゃいけない。ただし、リアルモードなのでアプリが暴走すると
OSもつられてこけるので、関係ないっちゃ関係ない。

**デフォルトの名無しさん** · 2019/10/29(火) 23:31:54.59

>>463
386はプロテクトモードからリアルモードに戻ることができる
286は戻れないのでハードウェアでCPUだけリセットして復帰するように作る必要がある
PC/ATやその互換機、PC9801の286マシンにはそういう仕組みがハードウェアで備わってる

**447** · 2019/10/30(水) 00:23:36.64

>>456
機械語からコードを復元する必要があったとして、その時にコメントが
全て消えているとなると、技術者がチクチク解析しないといけないのかな
と思いまして

**デフォルトの名無しさん** · 2019/10/30(水) 02:14:08.40

割れ厨か

**デフォルトの名無しさん** · 2019/10/30(水) 06:36:17.87

まず、リアルモードでも仮想86モードでも、
アドレスサイズプリフィックスを使うこと自体ではGPフォルトは発生しない
例えば、lea eax, eax+eax*4 という、5倍する時に使うコードは
仮想86モードでも普通に使える

何度も書いているが、
リアルモードと仮想86モードではセグメントのリミットが64Kに設定されているために
その範囲外にアクセスするとGPフォルトになるというだけなので
一旦セグメントリミットを4Gにしてからリアルモードに戻れば、例外を起こさずに全アドレスにアクセスできる

farジャンプは、パイプラインに残っている命令キューをフラッシュするためのものなので、セグメントリミットとはあまり関係ない

例えば自前で仮想86モードを利用した仮想EMSドライバを書く場合
最初にプロテクトモードに移行してリミットを変え、すぐにリアルモードに戻る
そしてリアルモードのコードで全領域をいろいろセットアップし、それから仮想86モードになってDOSに制御を移すという手法が使えた

仮想86モードでの割り込みハンドラも、仮想86モードでのスタック上にある戻り番地の部分に
割り込みベクタテーブルからの番地を置いて(テーブルにそして保存されているSPも変えて)iretするだけだから
別に難しくない
仮想86中でのiretも何か対処する必要があった気もするけど
いずれにせよGPフォルトのハンドラ内でどんな命令が例外を起こしたか調べる必要があるので、
その内部でiretだったらどうするというテーブルジャンプ対応程度で足りたはず

**デフォルトの名無しさん** · 2019/10/30(水) 06:40:30.90

>>464
リアルモードに戻る正式な手順は、「各セグメントのリミットを64Kに設定してからレジスタ(確かcr0だと思ったが)を設定」で
それを4Gに設定したままで戻れば、64Kの制限が解除される
もちろん16bitレジスタは16bitでしかアドレスできないので、32bitレジスタを使う必要がある

**デフォルトの名無しさん** · 2019/10/30(水) 09:06:54.09

>>468
>farジャンプは、パイプラインに残っている命令キューをフラッシュするためのものなので、セグメントリミットとはあまり関係ない

関係大有りです。リアルモードからプロテクトモードへのモード切替時に、
必ず far jmp命令を行うことが仕様で決まっているのです。
CR0 の PE BITを1にしただけでは切り替わりません。その後に必ずfar jmp
命令を実行するまでがモード切替の手順の一部として決まっています。

**デフォルトの名無しさん** · 2019/10/30(水) 09:09:35.16

>>469
CR0のPEビットを1にした状態でfar jmpするとプロテクトモードに切り替わります。

**デフォルトの名無しさん** · 2019/10/30(水) 15:33:25.51

>>457
MonaOS 知ってる人減ったな

**デフォルトの名無しさん** · 2019/10/30(水) 23:02:51.33

>>466
残念ながらチクチク解析しないといけないです。なぜならもしコメントが残っていたら、「○○製品で使ったコード」とか
社内秘の内容が書いてあるかも知れず、そんなものが外に出たら大変だからです。
ソフトウェアのバージョンとか表に出ても構わない内容ならDBで定数文字列として書いておけばバイナリーにも
残るので逆アセンブルすれば見えます。

**デフォルトの名無しさん** · 2019/10/30(水) 23:39:08.38

ダンプリストからでも処理を追えるから問題ない

**デフォルトの名無しさん** · 2019/10/31(木) 11:59:20.35

我々のコリブリ

**デフォルトの名無しさん** · 2019/11/01(金) 06:35:57.29

Super ASCIIでDOSエクステンダーの連載があったな
その連載の最初の頃にプロテクトモードで64KBのリミッターを解除して
リアルモードに戻るサンプルプログラムが載ってた
DOSエクステンダーの話になってからは雑誌に載るソースコードは一部分のみで
全体のソースコード自体はASCIIがやってたアスキーネットで公開してたけど

**デフォルトの名無しさん** · 2019/11/01(金) 08:50:52.10

昔書いたコードを眺めてみたが
プロテクトモードに移るだけなら far jmp は必要なく、
shortジャンプでキューをクリアするだけで動いてたな

もちろん、16bitプロテクトモードに移るだけでcsのリミットも触っておらず
リアルモードと命令の意味が変わらない(命令長が変化しない等)からこそ出来る技
32bitモードに移行したらプリフィックスの意味も即値やアドレスの長さも全て変わるから
farジャンプは絶対必要だろう

386の時代の話だから、以後のでも通用するかはわからないが

**デフォルトの名無しさん** · 2019/11/01(金) 08:51:34.31

こんな感じ

Enable4G　proc
　call　Relocation
　add　ds:[D_GDTR].@BASE32, eax
　pushr　<ds, es>
　pushf
　cli
　lgdt　D_GDTR
　mov　eax, cr0
　;and　eax, not _PG
　or　al, _PE
　mov　cr0, eax
　jmp　short $+2　　　;flush queue
　movseg　<ds, es>, GD_D4G, ax
　mov　eax, cr0
　and　al, not _PE
　mov　cr0, eax
　jmp　short $+2　　　;flush queue
　mov　al, 2
　out　0F6h, al　　　; A20マスク解除
　sti
　popf
　popr
　ret
　endp

**デフォルトの名無しさん** · 2019/11/01(金) 08:53:59.78

で、仮想86モードに移行する時は、far jmpが必須
なぜなら、仮想86モードに移行するためには
仮想86モード用にセットアップされたTSSを使った特殊なタスクに移行する必要があり
そのためにはプロテクトモード内でのcsの書き換え、つまり、farjmpが必要となるから

これは呼び出し部分

GotoV86　　proc
　pushad
　pushr　<fs, gs>
　pushf
　
　call　ModeSwitch
　
　popf
　mov　al, 3
　out　0F6h, al　　　; force A20 OFF
　popr
　popad
　ret
　endp

**デフォルトの名無しさん** · 2019/11/01(金) 08:54:59.94

ModeSwitch　proc
;　call　Enable4G
　call　SetAddress
　call　SetupIDT
　call　SetupTSS
　
　xor　eax, eax
　mov　es, ax
　call　CleanEMB　　　; これ以降、es=0
　call　SetupPageTable
　call　MoveCode
　call　Setup8259A
　
　prefixd32　　;32bit gdtr (not 24bit gdtr)
　lgdt　GDTR
　prefixd32　　;32bit idtr (not 24bit idtr)
　lidt　IDTR
　
　mov　eax, cr0
　or　eax, _PG + _PE　　; 直接ページングをON
　mov　cr0, eax
　jmp　short $+2　　; flush queue
　mov　ax, GD_D_TSS　　; タスクレジスタにダミーの設定
　ltr　ax
　
　call　VGtest
　FLUSH　GD_V_TSS　; jmp far seg, $next
　ret
　endp

最後に far jmpしてる

**デフォルトの名無しさん** · 2019/11/01(金) 08:56:48.06

Super ASCIIに載ってたサンプルコード
https://pastebin.com/0Tk0U9Y1
(TASMで動作確認済み)

PC9801用のテストプログラム(VRAMを80808080で埋めてるだけです)
.386p
assume cs:prog,ds:prog
prog segment use16
org 100h
mov ah,40h
int 18h
mov ah,42h
mov ch,0c0h
int 18h

mov eax,0
mov es,ax
mov edi,0a8000h
mov ecx, 32768*3/4
mov eax, 80808080h
cld
db 67h
; use ecx for loop counter
rep stosd

mov ax,4c00h
int 21h
prog ends
end

**デフォルトの名無しさん** · 2019/11/01(金) 08:58:53.01

サンプルコード、テストプログラムともにCOM形式なので
LINKした後にexe2bin protect.exe protect.comとcom形式に変換する必要があります

**デフォルトの名無しさん** · 2019/11/01(金) 11:55:34.87

知らない人が多いようなので書いておくと、
実測してみると pusha より、ばらばらの push 命令を書いたほうが速度が速い。
一つの理由は、push espという無駄なpushが1つ減らせるから。
これはQEMUなどを使っているだけでは分からない事実。

なお、こっちは良く知られたことだけど、enter, leave 命令より、
push ebp, mov ebp,esp, sub esp, nn などと書くほうが速い。

もっと言えば、486だとなぜかinc, dec が2クロック掛かってしまうのに、
add esp,1 や sub esp,1 は1クロックで済むという事実を知る人は少ないらしい。

**デフォルトの名無しさん** · 2019/11/01(金) 11:58:53.09

>>483
補足。QEMU だと、pusha が1命令分の時間で済むのに対し、バラバラの
push命令に直してしまうと、その個数倍の時間が掛かるので、8倍程度後者
の方が遅い。実機だと、後者の方が16%程度速い。実機とQEMUでは全然
速度バランスが違うので、QEMUでの速度測定は全く参考にならないので注意。

**デフォルトの名無しさん** · 2019/11/01(金) 12:10:32.63

>>477
正確には short jmp だったか、far jump だったかは資料を見てみないと
思い出せないけど、少なくとも Wikibooksには、
6. Set the PE bit (and the PG bit if paging is going to be enabled) of the
　MSW or CR0 register
7. Execute a far jump (in case of switching to long mode, even if the destination
　code segment is a 64-bit code segment, the offset must not exceed 32-bit
　since the far jump instruction is executed in compatibility mode)

また、https://stackoverflow.com/questions/26679682/how-does-setting-the-pe-flag-in-cr0-enable-protected-mode
にも、
1. Set up a global descriptor table (gdt) and load it using the lgdt instruction
2. Set the PE flag/bit in the control register CR0 to enabled (ie. to the value 1)
3. Execute a long jump with ljmp

Technically the CPU internally stores the selector information of all selectors used.
Whenever a selector register changes then the limit, base and so on are loaded.
This means that loading the CS register is required for updating the base, limit
and so of the CS register. This means: A far jump must be done (because this
will load the CS register). Maybe a RETF would also work...

I'm not sure if loading the other segment registers (for example DS) would
already work before the far jump so if you load the DS register before the
far jump the base address and limit will be taken from the GDT. Would be
nice to try this out...

と書かれている。

**デフォルトの名無しさん** · 2019/11/01(金) 12:19:54.06

>>485
だんだん思い出してきたので書いておくと、GDTRにGDTのアドレスをセットした
だけでは、CPU内部のセグメントレジスタの情報が更新されない。
例えば、dsには、リミット、ベースアドレスなどの情報がCPU内部に入っているが、
GDTRを更新した段階では、CPU内部のそれらの情報は更新されない。
更新されるのは、mov ds,ax や、pop ds, lds などを実行した場合のみ。
つまり、mov ds,ax などを実行して始めて、CPU内部のdsレジスタに関する隠れ
情報格納場所の情報までが更新され、dsにプロテクトモードらしいセグメントが
対応するようになる。

一方、csレジスタについては、mov cs,ax などの命令が無いので、その代わりになる
のが、far jmp ということになる。far ret や iret などでもいけるかもしれないが、
仕様上は far jmp ということになっているのだと思う。だから、プロテクトモードに
初めて突入したい場合に、far jmp 以外の命令でcs を更新した場合にどうなるかは
保証されていないかもしれない。

**デフォルトの名無しさん** · 2019/11/02(土) 18:02:51.42

低レベルな相談です

ADDL・ADDA・SUBL・SUBA・AND・OR・XOR・CPL・CPA命令において
オペランドの第2引数に、=を付けるのをつい忘れてしまうんですが、
何か対処法はありますか？

**デフォルトの名無しさん** · 2019/11/02(土) 22:19:49.20

>>487
CASL II は始めて見たんだけど、
http://masudahp.web.fc2.com/casl2/casl2110.html
http://masudahp.web.fc2.com/casl2/casl2120.html

ADDA GR0, =#0045
のように書くと、自動的にラベルを生成して、
ADDA GR0, DATA1
・・・
DATA1 DC #0045
と書いたの等価になるらしいから、忘れるとか言う問題ではなく、
CASL II言語の基礎なので自然に覚えるしかないですね。
アセンブリプログラミングには、このくらいの記憶力は必要です。
ただ、丸覚えするのではなく、ちゃんと理解すれば自然に覚えられると思います。