[OSASK 1944] Re: nasmcnv2?

[Hidemi KAWAI <kawai !Atmark! imasy.org>]

  おはようございます、川合です。


nabe さんは 2001/08/25 01:03:58 の「[OSASK 1941] Re: nasmcnv2?(R
e: from OSASK BOARD).」で書きました：

>>  実は、かつてはNASMがASKAの標準アセンブラでした。そのためnasmcn
>>v1までは既にリリースされています。必要でしたら、
>
>たしかコードが短くなるとかでしたっけ。
>一応 NASM 派として弁明すると、
>NASM は書いた通りにのコードをそのまま素直に出力します。
>
>short jmp や短い方の命令コードなども、
>指定すればその通り短く出力されます。
>NASM で出せない命令はないはずです。

  はい、その点について今まで僕は言及してきませんでしたが、認識は
しています。そしてなべちゃんさんと同じく、NASMのこの特徴は長所に
数えています。

  さて、僕はMASM派として弁明することにします（笑）。

  MASMもNASMほどではありませんが、shortやnearを指定して出したい
方のコードを強制的に出すことはできます。そして、特に指定しなけれ
ば短い方を自動的に選択します。僕は、この自動選択を高く評価してい
ます。

  アセンブラプログラマーとしては、デフォルトで短くて速いほうを選
択してくれるならそれにこした事はありません。jmp命令などは、short
で届くかどうかがコードの前後関係で変化するので、書き足しているう
ちに届かなくなったり、削っているうちにshortで充分になったりしま
す。これをいちいち意識しなければよいコードが得られないというのは
僕の好みとは一致しません。

  もしMASMがshortやnearの指定ができないアセンブラだったとしても
僕はNASMではなくMASMを選んだことでしょう。それほど、この自動選択
機能を高く評価しています。・・・そして、どうしてもあえてnearにし
たいなどというときでも、NASMは使わずにDBやDDで書くでしょう。

  この自動選択機能への好みはASKAの仕様にも強く反映されています。

    EAX = 0;

という記述はMOV(EAX,0);ではなく、例外的にXOR(EAX,EAX);として扱わ
れます。この方がコードが短いからです。同じ理由で、

    ECX += 1;

はINC(ECX);にされてしまいます。これらの自動選択は、フラグの変化
の仕方が異なるような自動選択です。このような「勝手」をされては困
るという時には、

    (MOV) EAX = 0;
    (ADD) ECX += 1;

などと書かなければいけません。ちなみに、

    (ADD) ECX++;    // ADD(ECX,1);
    (SUB) EDX += 1; // SUB(EDX,-1);

などという変則的なこともできます。この機能はデコードキャストと呼
んでいますが、このバリエーションはこのくらいあります。

             EAX--;  ->  dec eax            (40)
(DEC)        EAX--;  ->  dec eax            (40)
(DEC short)  EAX--;  ->  dec eax            (40)
(DEC long)   EAX--;  ->  dec eax            (ff c0)
(ADD)        EAX--;  ->  add eax,-1         (83 c0 ff)
(ADD imm8)   EAX--;  ->  add eax,-1         (83 c0 ff)
(ADD accum)  EAX--;  ->  add eax,-1         (05 ff ff ff ff)
(ADD imm32)  EAX--;  ->  add eax,-1         (81 c0 ff ff ff ff)
(SUB)        EAX--;  ->  sub eax,1          (83 e8 01)
(SUB imm8)   EAX--;  ->  sub eax,1          (83 e8 01)
(SUB accum)  EAX--;  ->  sub eax,1          (2d 01 00 00 00)
(SUB imm32)  EAX--;  ->  sub eax,1          (81 e8 01 00 00 00)
(LEA)        EAX--;  ->  lea eax,[eax - 1]  (8d 40 01)
(LEA disp8)  EAX--;  ->  lea eax,[eax - 1]  (8d 40 01)
(LEA disp32) EAX--;  ->  lea eax,[eax - 1]  (8d 80 01 00 00 00)

  ですから、ASKAの仕様はNASMに充分匹敵すると僕は思っています。

># MASM 6.x はでかくて嫌い、Win-console で開発したくないだけ
>  とも言えるのだけど……

  これについては、共感します（笑）。

># 贅沢ついでにあとひとつ言うと、
>  2重に変換するのが面倒ってのもあるんだけど。

  それは、僕も賛成です。しかし、だからといってNASMのソースを出し
てほしいということにはならないと僕は思います。

  僕は、MASMのソースを直接出せるようにしてほしいとは言っていませ
ん。そんなことは本質的はないと思っています。本質を突くなら、ASKA
は.OBJファイルやバイナリーファイルをダイレクトに出力できるように
なるべきです。そうすれば、MASMやNASMを別途用意する必要はなくなり
ますし、デコードキャストを反映できるようになります。

  僕としてはASKAにmasmcnvやnasmcnvを内包させるなんていうことで、
ODPさんを悩ませたくはありません。その時間をバイナリー直接出力の
ために注いでほしいです。

>>多少修正すればDOS環境下で実行可能な
>>バイナリーを用意することもできるでしょう。
>これもついでに聞き流してほしいのですが、
>DOS で十分間に合うツールまで Win-console 専用というのが
>敷居の高い原因のひとつだったりします。

  これはごもっともなご意見です。言い訳させてください。

  DOSの環境下では、DOSエクステンダーを使わない限り16bitでのプロ
グラミングになります。そうなると、64KBを超える配列が使えません。
僕の最近のプログラミングスタイルとして、でかいバッファを使って、
最初に全てをそこに読み込んでバッファ管理を単純にするというのをよ
くやるんですが、それができなくなってしまいます。

  むろん、僕のこのプログラミングスタイルはあまり誉められたもので
はないかもしれません。しかし、この方法はメモリマップドファイルに
近いので好きなのです。それで、このスタイルを改めて16bit環境下向
きのアルゴリズムを導入するために時間を掛けることもできますが、そ
れよりも先にやるべきことはいくらでもあるだろうと思っているわけで
す。

  結局、僕はwin32を「もっとも普及しているDOSエクステンダー」くら
いにしか考えていないんです。

  そして、なべちゃんさんのような方に対しては、「ソースを公開して
いる」ことが免罪符になると考えています。・・・お好きなようにいじ
っていいです。ライセンスもこの上なく緩いですし。

  そういえばASKAだってソースが公開されているじゃないですか。nasm
cnvの内包だってなべちゃんさんの手で可能だと思いますよ。・・・ま
あ、誰かが作ってくれるのを待つよりは面倒ですが・・・。

  結局のところ、ツールを自作するほどの興味はないということでした
ら、残念ですがASKAはしばらく見送ってNASMをお使いいただくというの
がなべちゃんさんにとっての現実的な回答になると思います。


  それでは。

--
    川合 秀実(KAWAI Hidemi)
川合堂社長 / OSASK計画総指揮 / カーネル開発班
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/