[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

[OSASK 2834] Re: Fullset EUC-JP

  こんにちは、川合です。


I.Tak. さんは 2001/12/31 12:27:03 の「[OSASK 2831] Fullset EUC-J
P」で書きました：

>作ったルーチンを上げておきます。
>http://home1.catvmics.ne.jp/~msy/tak/garage/euc2gg.lzh

  ありがたいのですが、うーん・・・。

>　ちなみにこれを作った裏には、
>「APIレベルで変換を提供しているにも関わらず『シンプルEUC』とか言い逃れ
>をしてEUCをないがしろにする川合さんの姿勢は不満だ。MS漢字コードの方が
>ずーーっと複雑なのに。ひょっとして川合さんはマ○クロソフトになにか……？
>いや、純粋に使わないからいいやと思ったんだろう。ううむ、自分で作らにゃ
>ならんのか(^_^;;」
>という葛藤があります、ハイ。

  これは全然違う理由なんです。

  表示文字長とバイト数が比例するエンコード方式は扱いやすかったの
ですぐに採用したんです。・・・ほら〜、シンプルEUCもシフトJISもこ
の条件を満たしています。

  それとEUCルーチンをシンプルに保ったのは、他のEUCコード（たとえ
ば韓国語）にもそのまま使えるようにするためです。実際、共通に使え
ています。もし組み込むとしたら日本語EUC専用のオプションコードを
決めて、そのコードでこのルーチンを使うことにするでしょう。

  日本語だけのために、どこまでAPIサポートするべきかというのも僕
の悩みの一つです。シフトJISとフルセットEUCだけならまあいいかなあ
・・・。それともフルセットの方は各アプリで対応してもらった方がい
いかなあ・・・。

  ということで今のところ、組み込みは先送りです。

---

  例によって、ソースへのコメントです（笑）。

>/*JISX0201のロマカナ間の空きは
>	認められとる……なんでやねん。 */

  これはどういう意味なんですか？・・・分かりませんでした。

>/*本来こういうのは一バイトずつループをまわすべきでは？
>	セグメントの終わりにマルチバイト文字の前半だけ
>	置かれたら確実に死ぬ。どうせパラメタが間違ってると
>	死ぬからいいか。 */

  ループの回し方はどうでもいいのですが、不適切な文字コードが渡さ
れるかもしれないという懸念はいりません。今のpioneer0ライブラリは
「アプリ高速」というモード用に書かれていて、これは「アプリ安全」
ではないのです。・・・これが何を言っているのかわからない方は、[O
SASK:039]を・・・って、これは公開されていませんね。じゃあ、ここ
に引用します。

------- 引用開始 -------

>>り、「アプリ安全」「アプリ高速」「システム高速」です（ゲートの入
>っと、それぞれどういうときに使うんですか？

  まず、Timerルーチンは上記の３つのモードがあると考えて下さい。
実際には、３つの入り口（Ｃ言語風にいえば、３つの関数ってとこかな
）があるだけのことです。

  この３つを理解するには、まず「アプリ安全」を理解する必要があり
ます。「アプリ安全」モードは、システムルーチンとしてふさわしい、
極めて安定したモードです。呼び出す側のプログラムにバグがあったと
しても、堅牢なチェックルーチンが事前に検知し、システム全体の崩壊
の可能性を皆無にします。また、アプリケーションが使いやすいように
設計されています。

  普通のOSなら、これだけでいいんです。しかし、OSASKは安定性の他
に高速性を要求しています。したがって、高速化のために残り２つのモ
ードが用意されました。

  「アプリ高速」モードは、アプリケーションのプログラムミスによる
エラーは一切発生しないという前提で動作するモードです。もちろん、
プログラムでは如何ともしがたいエラー（例えば、リソースが足りない
とか）については、ちゃんとチェックします。しかし、定義されていな
いfunctionコードがつかわれているんじゃないかとか、取得してないハ
ンドルを使おうとしているんじゃないかとかなどのチェックはしません
。これにより、速度的な負担が大きく減少します。・・・このモードを
使うときはそのアプリが充分に信用に足りる（＝アプリ安全モードで使
っていても、一度もエラーが出たことがない）ことを確認してから使っ
て下さい。

  「システム高速」モードは、「アプリ高速」モードの考えを更に推し
進めて高速化を最優先し、設計されたモードです。まず、エラーチェッ
クは「アプリ高速」と同程度の必要最小限にされています。加えて、fu
nctionコードやパラメーターが、Timerルーチンの都合に合わせて設計
されています。「アプリ安全」／「アプリ高速」がアプリケーションか
ら使いやすいように設計されているのとは大きく異なります。また、こ
のルーチンを使用するプログラムはリング０で実行されていることまで
が要求されます。つまり、一般のアプリケーションはこのモードを直接
利用することができません。使用できるのはシステムルーチンだけであ
り、TAPIや音楽ドライバーが積極的にこのモードを使用する予定です。
なお、このモードでの実行が最高のパフォーマンスを発揮します。

  この３つのモードは同時に存在しうるものです。アプリＡは「アプリ
安全」を使用し、別のタスクのアプリＢでは「アプリ高速」を使うこと
ができます。コールゲートとして登録するときに、セットするアドレス
がちょっと違うだけのことです。

------- 引用終了 -------

  この文章はデバイスドライバー（タイマールーチン）がアプリケーシ
ョンからのファンクション呼び出しを直接受け取る部分について書かれ
たもので、pioneer0の説明ではありませんが、内容的には同じです。

  またソースを見ると188倍するためにLEAやSHLを多用していますが、
これは最近のプロセッサでは大いに不利なコードであると思います。こ
れが速いのはせいぜい486くらいまででしょう。PentiumはIMULを10クロ
ックで実行できます。LEAを連続して使うのはAGIがやたらと発生するの
で、このような複雑な倍率の掛け算にはお勧めしません。

  なおPentiumPro以降では、IMULの実行クロックは1クロックです（た
だしレイテンシーが4クロックありますが）。IMULにすればコードも小
さくなりますから、僕はこっちのほうがいいと思うのですが・・・。


  それでは。

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