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

★お気に入り追加

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

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,'$'

ここまで見た

103 2010/07/05(月) 12:30:21: >>100
いや普段はViだからな。
あれとVzは用途がまるで違う。どっちか一つだけにはできない。

ここまで見た

104 2010/07/05(月) 22:20:12: >103
どんなとき、viよりvzが便利なの？
俺もviユーザなので、ちょっと気になった

ここまで見た

105 2010/07/08(木) 00:00:50: 俺はDOS付属のedit派。
Windowsメモ帳とほぼ同じメニューだからとっつきやすい。

ここまで見た

106 2010/07/08(木) 18:48:56: 男ならedlin

ここまで見た

107 2010/07/08(木) 19:36:14: 真の男ならsymdeb

ここまで見た

108 2010/07/08(木) 19:41:31: と思ったら最近のＯＳには含まれてなかった（汗）
かわりにdebugを実行してみたら16ビットモードで起動した

ここまで見た

109 2010/07/08(木) 20:27:55: viユーザにとってはedlinの方がeditより使いやすい

ここまで見た

110 2010/07/08(木) 21:36:39: >>109は馬鹿な奴

ここまで見た

111 2010/07/08(木) 22:53:47: >>105
editって中身はQuickBASICから言語機能を外したやつだったっけ確か。
edit.comから起動される本体がqbasic.exeとかなってたような気がす。

ここまで見た

112 2010/07/08(木) 23:31:11: にしてもedlinってのはなあ。。。

ここまで見た

113 2010/07/09(金) 00:13:27: お前のeditだと、起動してから使えるようになるまで約10秒。

ところがedlinだと起動から「ファイル名を指定してください．」まで
約0.1秒。こいつは速い！

ここまで見た

114 2010/07/09(金) 09:45:10: 男なら type con > main.c

ここまで見た

115 2010/07/09(金) 09:49:46: 緊急時の
copy con autoexec.bat
や
copy con config.sys
は
ときどきやった

ここまで見た

116 2010/07/09(金) 13:13:12: ま、一度はやるわな

ここまで見た

117 2010/07/09(金) 20:19:03: 暇だからDOS用の超軽量エディタでも作るか…

ここまで見た

118 2010/07/09(金) 21:15:59: edlinが14KBか…

>117
10KBで頼む

ここまで見た

119 2010/07/14(水) 22:29:34: メルコのMelwareとかに付いてた簡易エディタがあったよな
と思って調べたら36kBもあった。
中身を覗いたらMetaWare Cという余り聞きなれない処理系が使われてた。

ここまで見た

120 2010/07/23(金) 22:32:20: Z80から8086に入ってきたとき、86には条件リターンがないのに驚いた。

ここまで見た

121 2010/07/23(金) 22:39:19: movでフラグが変わらないとか

ここまで見た

122 2010/07/24(土) 04:44:50: >>120
いやむしろ俺は、8080/Z80系をはじめて触ったとき
条件Jump/条件Call/条件Returnと揃ってることの方に驚いたが…

ここまで見た

123 2010/08/01(日) 22:40:21

ここまで見た

124 2010/08/25(水) 18:59:52: 保守

Z80ではIX、IYを使うと笑われたから、
86でもSI、DIはストリング命令以外では使わなかったな。

ここまで見た

125 2010/08/25(水) 19:21:15: IXやIYを使うだけで嗤う香具師はおらん
IXやIYをアキュムレータのごとく使う香具師が嗤われる

ここまで見た

126 2010/08/25(水) 20:10:28: IX や IY はクロックをおもいくそ食うと思っていたが、HD64180 なんかでは状況はかわったのかなあ？

ここまで見た

127 訂正 2010/08/25(水) 22:50:37: 8086系のCでも、SIとDIはレジスタ変数として使われる程度だね。

ここまで見た

128 2010/08/26(木) 04:34:12: ぷげら

ここまで見た

129 2010/08/26(木) 10:50:31: >>127
誰が作ったんだ？その糞コンパイラはｗ

ここまで見た

130 2010/08/27(金) 13:27:04: ストリングス転送命令は途中からあまり使われなくなったような気がする。

ここまで見た

131 2010/08/27(金) 16:14:18: UNICODEが流行ってASCIIZじゃなくなったからだろ

ここまで見た

132 2010/08/27(金) 16:19:38: ブロック転送命令は8/16/32bit長のどれも使えるぞ

ここまで見た

133 2010/08/28(土) 08:31:25: Pentium以降、単純機能の命令が非常に高速化されたので
ストリング転送命令のような複合命令を使う理由がなくなった。
VC++のmemcpyの実装を見ると使用可能ならxmmレジスタを使ってる。

ここまで見た

134 2010/09/15(水) 22:51:28: CTSって何する命令?
symdebで逆アセンブルすると時々出てくるんだけど。

ここまで見た

135 2010/09/15(水) 23:14:54: >>134
ClearToSend……ってギャグはさておき。
コードは幾つよ。CTSなんて記憶にないわさ。

ここまで見た

136 2010/09/15(水) 23:41:19: >>134
STC(SeT Carry flag) じゃなくて？

ここまで見た

137 2010/09/16(木) 00:04:59: >>135
0fh。

symdebのアセンブラで
db 0fh
db 00h
とやって逆アセンブルすると
0F00 CTS 00
と出てくる。

ここまで見た

138 2010/09/16(木) 00:41:43: >>137
そこには 386以降の命令が詰まっているような気が。
たしかにCTS ってなんのつもりだったんだろう？

ここまで見た

139 2010/09/16(木) 07:22:51: >>137
symdebの時代なら8086を想定しているだろうから、0fは未定義だね。
8086って、未定義命令割り込みってあったっけ? あればAPIでも用意されているとか。

ここまで見た

140 2010/09/16(木) 13:37:37: ない。
286以降でなかったかのう。

ここまで見た

141 2010/09/16(木) 14:46:27: 0fhって8086ではpop csだったような気がす。
86だと実際にpopが行われるから、予めpush csしておくようにと
CPU判定方法に書いてあった。

ここまで見た

142 2010/09/16(木) 20:47:36: pop cs は、F0じゃないか？
286以降ではプリフィックスとして使われて
いわゆるF0バグを招いたやつ。

ここまで見た

143 2010/09/16(木) 21:44:25: 0F0Hは8086もlock prefix

ここまで見た

144 2010/09/16(木) 22:56:48: push cs 0eh
push ds 1eh
push es 06h
push ss 16h

pop ds 1fh
pop es 07h
pop ss 17h

なので、pop csは0fhだったと思う。

ここまで見た

145 2010/09/18(土) 17:58:34: 8086：
AX:汎用加減乗除計算用
BX:準汎用加減乗除計算／アドレッシング補助
CX:準汎用加減乗除計算／カウンタ（条件分岐命令、ループ命令で使用)
DX:汎用加減乗除計算用
SI:メモリ転送元インデクサ
DI:メモリ転送先インデクサ
BP:スタックフレーム用
SP:スタックポインタ
それぞれけっこうギチギチに役割がふられており実は自由度は少ない。
但し多少の加算減算程度は１６ビットレジスタには許可されてた
程度。よって完全にコンパイラ向け。経験知でオプティマイズできる
余地は余り無い。
しかし当時はアセンブリ職人と自称する人は会社に一人や二人は居て
腫れ物に触るように扱われてたっけW

ここまで見た

146 2010/09/19(日) 13:30:22: >>145
>但し多少の加算減算程度は１６ビットレジスタには許可されてた
>程度。
AL/AHとかの８ビットレジスタにも加減乗除演算が定義されてた（る）件

>よって完全にコンパイラ向け。
コンパイラ作成者泣かせなプロセッサと聞きました。（オプティマイズ
が難しい）