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

[OSASK 2847] Re: Fullset EUC-JP

  こんにちは、川合です。


I.Tak. さんは 2002/01/01 02:00:15 の「[OSASK 2842] Re: Fullset E
UC-JP」で書きました：

>　いや、１バイトのコードを半角で表示するというのは慣例でしかあり
>ません（半角や全角は印刷用語で、文字コードとの関係はありません）。

  そのとおりであります。

>つまり、文字コードはフォントの大きさや幅の情報を持ちません。当たり前
>ですよね。カタカナを渡されたらカタカナを表示する、決まりはそれだけです。
>面倒ならEUCのJIS X 0201カナを全角で表示したってなんの問題もありません。
>これをやるソフトにはnkf（有名）が挙げられます。
>　ぐいぐい00仕様は慣例に縛られすぎていると思います。

  これについては反論しましょう。

  いくつかのテキストは、半角文字は半角で、全角文字は半角の2倍で
表示することを想定して書かれているでしょう。その意図に背くだけの
理由があれば僕はカナを全角で書くなどのことをやるかもしれませんが
、そうでないかぎりやりません。OSASKはエミュレーターOSであること
を忘れないでください。エミュレーションというのは基本的に実機に近
ければ近いほど良いのです。

>>  それとEUCルーチンをシンプルに保ったのは、他のEUCコード（たとえ
>>ば韓国語）にもそのまま使えるようにするためです。実際、共通に使え
>>ています。もし組み込むとしたら日本語EUC専用のオプションコードを
>>決めて、そのコードでこのルーチンを使うことにするでしょう。
>　フルセットのEUCルーチンでも共通に使えます。遅くなるのは確かですが、
>しかしシフトJISと同程度ではありませんか？

  日本語に限定したフルセットEUCは確かに共通に使えるでしょう。し
かし本当のフルセットEUCに対応するなら、たくさんのコードページに
対応しなければいけないでしょう。オプションは増えます。

>　今のところG2やG3を使うのは日本語だけなのも、確かにそうです。

  中国語とかはどうなんでしょうか？よく知らないんですが・・・。

>　EUCの拡張性は日本語だけのものではありませんから、フルセットEUCこそ
>API対応しましょう。日本語だけのためはシフトJISそのものです。MS拡張に
>も個別対応しているようですし（←使いたい者が作る原理を感じました）。

  誤解しています。

  もし僕が僕の個人的な動機だけであの設計をしたら、シフトJISと富
士通系の拡張フォントに都合の良い仕様にしていたでしょう。しかし僕
はそういう風には考えていません。

[OSASK 2587]より
>  Windowsを選んだのは、現在においてはほとんどのテキストがこの文
>字セットで読むことを想定しているだろうと僕が思ったからです。

  このときの発言にも現れていますが、僕は純粋に現状での日本語テキ
スト全体を考えて、それでどれを中心にするべきかを決めました。今は
シフトJISとNECコードに都合の良い仕様になっています。

  フルセットEUCを作るべきだという意見には賛成です。僕の言うフル
セットは日本語専用ではなくEUCの全ての拡張性に配慮したものです。
パラメーターは増えるでしょう。そしてシンプルで十分な場合もあるで
しょう。僕はEUCについてはシンプルとフルセットの両方をつけてやり
たいと思っています。そして文字長指定は、表示文字の半角文字単位で
指定させようと思っています（つまり、半角カタカナは2バイトですが
文字長1です）。

  でもEUCよりはISO-2022に対応した方がいいかもしれません。以下で
書かれたとおり。

>　変換の究極は、ISO-2022 に対応して後はアプリ次第という形になります。
>適当なシーケンスを送って設定すればEUC-JPになるしISO-2022-JPになるし、
>EUC-KRにEUC-CNに、コンパウンドテキスト（シフトJISは置いてけぼりを
>食らいますが）。……誰が書くんだろう？(^^;;;

  シーケンスを送らなくても、オプションで「シーケンスを送った状態
」からデコードを開始してやればいいのです。そうするだけで使いやす
くなるでしょう。

>　つまるところ私はISO-2022やEUCが好きでシフトJISは嫌いなわけで、
>かなりひいきして発言しています。しかし嘘は言っていません。
>よぉ〜く考えてください(^_^;;;

  僕は好き嫌いを押し殺して設計しているつもりです。

  ただシフトJISはEUCに比べて一つだけいい点があるとは思います。そ
れはEUCよりもバイト数が短くて済む傾向があるということです。EUCは
シフトJISよりも拡張性については遥かに優れているので（EUCというか
ISO-2022の拡張性ですが）、仕様としてはEUCの方が優れていると思い
ます。

>　ぐいぐい00仕様のフォントはどういう配置になっているのか興味があります。

  これについては、[OSASK 2492]をごらんください。

>　例外を拾ってやる、というレベルではなさそうですから、親切に誤りを
>探して返してくれる、正してくれる、ということですね？＞アプリ安全

  ええとですね、アプリ安全はちゃんとしたエラーコードを呼び出し元
に返しますし、設定によってはシェルに密告します（しょせん、OSASK
のすべてはシェルの手先なのです・・・笑）。とにかく、アプリ安全を
一言で言うなら「落とせるものなら落としてみろ！」です（笑）。

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

  いや、レイテンシーというのはそういうものではありません。IMULを
立て続けに4つ書いてもいいのです。しかし演算結果が利用できるまで
には4クロックかかるということなんです。IMULの回路もおそらくパイ
プライン化されているのでしょう。

>　JIS X 0201 をエンコードすると英字とカナの間に空き（制御コード領域C1）
>がありますよね。でもオリジナル変換ルーチンではそこの空きは埋めていない
>ようでした。JIS X 0213 は隙間が無いように変換するのが面倒なのに……。

  はい、隙間は埋めていません。埋めない方が使いやすいですよね？一
般的な変換においては。

>　imulの方がレジスタが空く上に必ずしも遅くはないと知った以上、
>喜んでimulを使います。leaがアドレシング回路を占有する時間も気に
>なっていましたし。

  それは好ましいことです。

  ちなみにi486では、IMULの即値32bit演算は13〜42クロックです。確
かに速くはないです。188倍に限定すれば、18クロックのようです。


  それでは。

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