懐かしのMS-DOSプログラミング [sc] | レス664-715

★お気に入り追加

■ このスレッドは過去ログ倉庫に格納されています

1 2010/04/21(水) 12:42:23

mov dx,offset msg
mov ah,9
int 21h
mov ax,4c00h
int 21h

msg db '懐かしのDOS時代のプログラミングについて語ろうぜ',0dh,0ah,'$'

ここまで見た

664 2013/12/11(水) 08:40:01.19: 今のVisual Basic.NETはBasicたる劣勢要素が殆ど無いいわばC#の双子兄弟みたいになったけど、当時のBasic7は性能的にはどうだったんだろう。Cと変わらない、なら価値はあったのかも知れないけど

もっともC#/VB勢は、MFCより遅いんだけどねw

ここまで見た

665 2013/12/11(水) 09:04:23.91: DOSの頃のBASICにはON EVENT GOSUBやON ERROR GOTOというステートメントがあってだな
(例外処理っぽいのがintしか無い環境で、各ソフトが勝手に割り込みハンドラを書き換えるわけにもいかないから)
全部のステートメントの間にトラップのためのチェックコードが生成されてた
なので何も考えないとCの倍遅い

でも、OFFると、C並の速度は出てた筈
Cコンパイラの方も相応にしょぼかったし

ここまで見た

666 2013/12/11(水) 09:09:30.57: というかだ、16ビット環境はセグメントがあるせいでポインタ演算は効率悪かったんで
C言語というのはそんな速い言語じゃなかったw
スピードが欲しければアセンブラ一択ですよ

ここまで見た

667 2013/12/11(水) 09:22:20.63: >というかだ、16ビット環境はセグメントがあるせいでポインタ演算は効率悪かったんで
>C言語というのはそんな速い言語じゃなかったw

ﾌﾟｗ

ここまで見た

668 2013/12/11(水) 09:37:15.65: 文系は所詮こんな程度ｗ

ここまで見た

669 2013/12/11(水) 11:15:12.87: ラージポインタは使ってもヒュージポインタを
ぶん回すようなまねはあまりしなかったな
BC7の頃は既に386が流通してて、
巨大なデータ配列をいじりたいならDOS/Extenderだった

ここまで見た

670 2013/12/11(水) 11:44:00.83: VCPIとか使うとI/O遅そうなイメージ

ここまで見た

671 2013/12/11(水) 12:02:48.85: 当時のＰＣの場合プロテクトモードの
オーバーヘッドはそれなりにあったのだが、
ソフトEMS使ってるなら普通にDOS使ってるつもりでも仮想86の配下

ここまで見た

672 2013/12/11(水) 12:07:20.41: エクステンダーってint21h DOS APIは一瞬リアルに切り替えるとかして互換性保ってたとおもうけど、他のbios APIていうか汎用的なint86コールもフックとかしててそのまま使えたの？

ここまで見た

673 2013/12/11(水) 12:08:48.24: むしろ問題はEMS用にISAやCバスに遅いメモリをつんでた場合で、
これをメインメモリで使い出すとスピードががた落ちしていた
メモリカードバスのメモリなんてもう最悪

ここまで見た

674 2013/12/11(水) 12:13:30.73: >>672
DPMIしかしらないけど、BIOS系の代表的なのはフックしてたよ
それ以外は一度仮想86に変移してから呼び出すことになる

ここまで見た

675 2013/12/11(水) 12:22:46.39: >>674
フックしてプロテクトモードのまま動いてたの？もっともDPMIだと割込ベクターだけフックすれば、リアル前提のBIOSルーチンそのまま動いちゃったりする気もするけど

ここまで見た

676 2013/12/11(水) 12:32:10.09: むしろ、ほぼ全て(EMS関連とint2F関連以外)は
割り込みでプロテクトモードになったら、すぐにスタックを書き換えて
リアルモードでの割り込みハンドラの指すアドレスに戻るようにして
すぐに仮想86に戻るようにしていた

特別な処理が必要になるのは、これらの他はDMA関連のI/Oポートくらい
こいつらはUMBやHMA(FFFF:部)も含め、物理アドレスとは一致しなくなるので
外に出すアドレスを細工する必要があった
あ、あとA20のON/OFFも対応する必要があった

ここまで見た

677 2013/12/11(水) 12:38:40.10: VCPIやDPMIでも微妙なところはカバーできないので、
結局DOSエクステンダーのランタイムはなくならなかった

ここまで見た

678 2013/12/11(水) 12:48:52.30: いとしの仮想86
なぜにx64のlong modeからなくなっちゃったの

ここまで見た

679 2013/12/11(水) 13:03:37.51: >>677
そもそも、それらは仮想86ドライバ上でDOSエクステンダを動作させるための規格
なくなるわけないだろ
VCPIなんか、「LDTやるからてめーでやれ」だし

ここまで見た

680 2013/12/12(木) 21:15:36.34: DOSって、レトロを楽しむ以外に今は何かに使われてるの

ここまで見た

681 2013/12/12(木) 22:13:02.96: 機械制御とかで使われてるんじゃないの？
ああいうのって画面いらないし、ネットワークもいらないし、
単に機械を制御できればいいだけだからシンプルなOSでいいんだよね。
マイコンでもいいぐらいだけどさすがに少しきついだろうということで
DOSぐらいでちょうどいい。

ここまで見た

682 2013/12/12(木) 22:22:57.46: 未だにPC-9801使ってるとこもあるんだろうな

ここまで見た

683 2013/12/12(木) 22:55:53.79: 俺の通ってた大学では実験室でPC9801使ってたよ
実験用の装置の動かすプログラムがBASICで組まれてた

ここまで見た

684 2013/12/13(金) 04:28:58.24: マルチスレッドに対応したDOSってあるの

ここまで見た

685 2013/12/13(金) 04:44:10.74: アプリが独力でマルチスレッドしてた

DOSじゃないけど同時代だと、
コンカレントCP/MやOS/9-68000とか対応してたな

ここまで見た

686 2013/12/13(金) 05:06:43.70: マルチスレッドはないけど、マルチタスクはできた
ユーザーが明示的に切り替えないといけなくて裏で勝手に動けたりはしない

ここまで見た

687 2013/12/13(金) 05:48:28.43: http://ideone.com/2Tx0rw
こんな感じ

ここまで見た

688 2013/12/13(金) 08:37:09.05: >>687
このソース、どう読めばマルチスレッドになるの

ここまで見た

689 2013/12/13(金) 09:17:29.82: f_1(); // 温度センサ値取得/表示
がいっぺんに
[温度センサの値取得]→[値表示]→[ウェイト]
をせずに小さい処理単位で返ってきて、次の
f_2(); // 圧力センサ　〃
に処理を渡せるから、人間からは
f_1(); // 温度センサ値取得/表示
f_2(); // 圧力センサ　〃
f_3(); // 加速度　　　〃
が同時に動作しているように見える。

マルチスレッドではなくマルチタスクだな。

ここまで見た

690 2013/12/13(金) 09:19:28.48: 俺には単なるサブルーチンの逐次処理に見える

ここまで見た

691 2013/12/13(金) 09:26:07.13: まるちさぶるーちん

ここまで見た

692 2013/12/13(金) 10:15:19.75: これはMS-DOS時代の組み込みでよく使われた手法。
MS-DOSの常駐プログラムとかはもっとマシな方法だと思う。

ここまで見た

693 2013/12/13(金) 10:28:48.03: マルチスレッドのない環境で、処理を小分けにするっていう実装テクニックか。それなら分かる。

ここまで見た

694 2013/12/13(金) 15:26:30.61: タイマー割り込みでバックグランド処理を実装してたな。
InDOSフラグ見てファンクションリクエストを呼び出し中なら
次の割り込みを待ってたけど、
逆にバックグランドがファンクションリクエストを呼び出し中なら
処理を譲れないから、フォアグランドの処理がカクカクになる。
DOSのPRINTコマンドの使えなさを覚えているなら
どんなものかわかるだろう。

ここまで見た

695 2013/12/13(金) 15:36:20.82: print.sys と置き換えて使ってた気がする

ここまで見た

696 2013/12/30(月) 04:42:00.17: Undocumented DOSっていう洋書には随分世話になったな

ここまで見た

697 2013/12/30(月) 05:47:42.89: Interrupt Listもな

ここまで見た

698 2013/12/30(月) 06:59:57.33: Undocumented DOSはもうずいぶん前に売ってしまったが、
Interrupt Listは場所も取らないことだし、今でも記念に取ってある。
あと、「MS-DOS完全活用法」とか「IBM PC & 80286のすべて」なんかも
ついつい捨てられなくて今でも目の前にあるよ。

ここまで見た

699 2013/12/30(月) 12:42:28.59: ピーターノートン&ポールヤオ著のコレ持ってた

http://www.amazon.co.jp/gp/aw/d/4915673278/ref=redir_mdp_mobile

ここまで見た

700 2013/12/30(月) 12:48:31.60: https://i.imgur.com/p2Jun40.jpg

やっぱ絵になるなあ、カッコいい

ここまで見た

701 2013/12/30(月) 13:01:12.13: DOS時代、テキスト画面制御するのにテキストVRAM直接アクセスは常識だった。
負け組Ansiエスケープシーケンスは論外として、画面BIOSでは4.7MHzの初代機でモッサリだったので。
テキストVRAMは、初代機MDAのVRAMアドレスと属性がCGA以降と違ってたので、実行時判断も必要だった。
同じ要領でNEC-9801にも応用出来た。

ここまで見た

702 2013/12/30(月) 15:23:05.11: DOSコールによる文字出力だと、2バイト半角文字が二重に出されたりしたのを覚えてる。
SJISと被る1バイト記号を出そうとしたら、まとめて出力すると漢字になるけど1バイトずつ出すといけたり。

ここまで見た

703 2014/01/01(水) 09:15:04.39: DOSプログラミングの運勢。

ここまで見た

704 2014/01/01(水) 09:27:46.76: ＞＞７０３の運勢

ここまで見た

705 2014/01/01(水) 15:56:37.02: 我が家のPCの消費電力

ここまで見た

706 2014/01/04(土) 00:31:30.85: 以前X86のLDSやLES命令をあまり見かけないという話が出てたが、
制御系の命令を除いたら、ENTERじゃないかと思う。
元々はPASCALの様な関数のネストが出来る言語向けの機能なのだが、
Delphiでも使ってくれてない。

ここまで見た

707 2014/01/04(土) 23:11:37.92: enterは第2オペランドの意味がよく分からん。保護が効くわけじゃないのに。

ここまで見た

708 2014/01/05(日) 07:52:28.27: こんなふうにLevel2FuncはLevel1Funcの変数にアクセスできる。
Level1Funcのスタックフレームのベースポインタを
Level2Funcに渡しているのでそれが可能になる。

procedure Level1Func(x : Integer);
var
　z : Integer;
　procedure Level2Func(y : Integer);
　begin
　　writeln(x, y, z)
　end;
begin
　z := 222;
　Level2Func 999;
end.

ここまで見た

709 2014/01/05(日) 09:05:42.96: <ローカル変数>
<level 2 bp>
<level 1 bp>
<bp 復元用> .. Level2FuncでBPの指す位置
[return address]
[y 引数]
<z　ローカル変数>
<level 1 bp>
<bp 復元用> .. Level1FuncでBPの指す位置
[return address]
[x 引数]

スタックはこんな感じになるので、Level2Funcでは
mov bx, [bp-2]
mov ax, ss:[bx-4]
でaxにzの値を取得でき、
mov ax, ss:[bx+4]
でaxにxの値を取得できる。

ここまで見た

710 2014/01/05(日) 09:09:51.71: enter ローカル変数サイズ, 2
いっぱつで
<ローカル変数>
<level 2 bp>
<level 1 bp>
<bp 復元用> .. Level2FuncでBPの指す位置
の処理をやってくれる。

2番目のパラメータが0の場合は
push bp
mov bp, sp
sub sp, ローカル変数サイズ
の処理だけになるのだが、
この場合、push, movで処理したほうが速い。