Hatena::ブログ(Diary)

七誌の開発日記(旧) このページをアンテナに追加 RSSフィード

新ブログ Twitter OneDrive Wiki

2010-08-02

[][]割り算

Alphaには除算命令がありません。インタプリタ側で計算することで実装は回避しましたが、どうやって実装するのか気になりました。最初は10進数に引っ張られて小難しく考えていたのですが、2進数で考えると、除数をシフトしながら被除数を引いていけば良いと気付きました。ちゃんとした解説は機会を改めることにして、自分用のメモ(これはひどい)を残しておきます。

     _____________
10110) 1011010110
       10110→

コードは以下です。自分が書いたコードなのに、見ても上のイメージは思い浮かびません。そういった溝を埋めることは可能かどうか、いずれ取り組みたいテーマです。

2010-04-10

[][]コンパイラを作ってみて

コンパイラ開発(id:n7shi:20090310)を通して物の見方がどう変わったかについて書いてみます。一般的な見解(と私が認識しているもの)、私の見解(過去・現在)などの視点が入り乱れるため、箇条書きを中心に記述します。何かを主張しようとしているわけではないので、特に結論のようなものはないことを、あらかじめ断っておきます。

【追記】私が作成したコンパイラSilverlight上で動作確認できます。 ⇒ id:n7shi:20090727

アセンブラ

アセンブラをいじることに対する一般的な見解(と私が認識しているもの)

  1. コンピュータの動作についてよりよく理解するため。
  2. カリカリにチューニングするため。

これらに対して以下のような意見があります。

これはその通りなのですが、だからどうするかとなると、二極化するように思われます。

  1. レイヤブラックボックスとして扱って、高級言語ノウハウに注力するべき。
  2. CPUごとの特性を調べて、最適なパフォーマンスが得られるようにするべき。
過去の自分の見解
現在の自分の見解
  • レイヤを厳密に切り分けないで、必要に応じて降りていける程度のノウハウはあった方が良い。
  • アセンブラが露出してしまうケースは依然として存在する。完全に隠蔽するのは無理ではないか。

アセンブラノウハウ 1

ノウハウだけでは抽象的過ぎるので、もう少し詳しく説明します。

たとえば高級言語で開発していてどうしても期待通りの動きをしないときに、それがアルゴリズムというような大域的な問題ではなく、局所的な言語仕様の理解不足が原因だということがあります。言語仕様から探そうとしても具体例として演繹する必要があるため、かなり苦労します。

こういうときに該当箇所のアセンブリを出力するのも、解決の糸口を探る方法の一つとして使えます。もちろんそれで全部が解決するわけではありません。あくまで一つの方法です。これはある種のカンニングだと言えます。

ただし『ある程度のノウハウ』がないと、そもそも出力されたアセンブリを解読することができません。具体的には後述します。

インタプリタ言語ではそもそもアセンブリに出力できないため、この方法は使えません。インタプリタについては後述します。

過去の自分の見解
  • 高級言語では不可能なチューニングをするためのもの。
  • そこまでの高速動作を要求するような開発はしないので、自分には関係ない。
現在の自分の見解

インタプリタ

インタプリタ言語を調査しようとしてもアセンブリに落とせないため、インタプリタの実装を読むことになります。その際に以下の壁があります。

この関係に着目すれば、以下のように解釈できます。

関係として相似でも、アセンブリ排除という視点を入れると、見方が複雑になります。

【注】話を単純化するため、アセンブリで実装された昔のBASICのような言語や、JITネイティブコードとして実行される言語は除外しています。JITは単純なインタプリタよりも更に読むのが難しいです。

過去の自分の見解
現在の自分の見解

アセンブラノウハウ 2

コンパイラの出力するアセンブリを読むために必要な『ある程度のノウハウ』について書きます。これは現在の私の考え方です。コンパイラを書く前には考えたことがありませんでしたし、一般論(こうすればコンパイラの出力したアセンブリが読めます、等)としても見たことがありません。

まず、アセンブラの用途については以下のような見解が一般的だと思います。

それに対して、私がここで取り上げようとしているものは異なります。

まとめると以下のようになります。

これが自分でコンパイラを作ったり、コンパイラの出力するアセンブリを読んだりするのに最低限必要なノウハウです。コンパイラを作って初めてこういうアセンブリとの接し方があるということに気付きましたが、実際に役に立っているかどうかは自分でもよく分かりません。

2007-01-26

[]入出力の自動生成

アセンブラと逆アセンブラは別々に作りますが、そのような一つの仕様に対して反対の動作をするものを、仕様から両方同時に生成できれば便利だと思いました。

背景にある考え方として、抽象度を高めて行けば設計と実装が統合できるのではないか、というものがあります。この辺のアイデアを自由に実験するには、既存の言語のコードを自動生成するのではなく、自前でコンパイルまでするべきだという考えに傾いています。そのため当面はコンパイラ作りに重点を置こうかと思います。冒頭のアイデアも、コンパイラ作りでアセンブラと逆アセンブラが必要になったことと関係しています。

2006-11-01

[]コードのリッチテキスト化

テキストエディタでコードを打ち込むのは嫌いなので、あまりプログラミングを楽しむということがありません。いつまでこんな旧態依然とした状態が続くのでしょうか。画期的な言語と言われても「所詮はプレーンテキスト」と思ってしまいます。かと言って完全にフローやUMLだけでコーディングするわけにもいきません。後者に可能性を賭けたいと思ったこともありますが、現状との溝が埋まらないまま打開できずに来ました。

完全に図形化するのは棚に上げて、もっと現実的な方法はないでしょうか。

オブジェクトの埋め込み

プログラミングに使うエディタは文字修飾やオブジェクトを埋め込めないという面では、ワードパッドの域にすら達していません。しかしワードパッドの域に達して何か嬉しいことがあるのでしょうか。コーディングの場合は慣習的に、予約語などが自動的にカラーやボールドになるため、自由に字体を変えたりすることにあまり意味はありません。

コードを説明するときに、図などを入れてきれいに説明しようとすると、コードとは別に解説を書くことになります。doxygenのようなマークアップはありますが、主にリファレンスを作ることが目的で、コードそのものに対する説明を目的としたものではありません。しかしオブジェクト(絵など)が埋め込めればコメントで概念を図示できるため、コードとの直接比較することができます。

D言語ではHTMLの中にコードを埋め込んでそのままコンパイラに通せるようですが、うまく使えばHTMLのWYSIWYGエディタで説明や図と一緒にコードを書けるのかもしれません。

表の埋め込み

定型処理を並べて書く場合、マトリックス状に並べると見栄えがします。現状では等幅フォントを前提にスペースやタブでレイアウトするという原始的な方法を使うしかありません。こういうときに表を埋め込めるようになれば、すっきりしそうです。

2-way

オブジェクトの埋め込みはタグ付きコメントでどうにかなるとして、問題は表の埋め込みのようなコードの自動生成が絡むものです。自動生成したコードは2-wayで反映されることが理想だとされていますが、それを実現するのは困難です。パーサーの出来が悪いと、正しい部分まで壊してしまうような問題が起きかねません。一方通行が無難かもしれません。

VC#ではGUIエディタのデザインがコードに落とされますが、ちゃんと2-wayになっていて、コードを直に編集すればパースされてGUIエディタに反映されます。NetBeansでは一方通行で、コードを編集しても破棄して上書きされるようになっています。技術的には前者が高度ですが、後者のように割り切っても実用上はそれほど問題はありません。そのため2-wayはあまり重視しない方針で行きます。

一方通行だと割り切った場合、自動生成した部分はタグ付きコメントで明示しておけば良いでしょう。たとえば表からの自動生成だと以下のようになります。

/// <table>
/// <output><arg/> <arg/> = <arg/>;</output>
/// <tr><td>int</td><td>a</td><td>1</td></tr>
/// <tr><td>double</td><td>aa</td><td>1.0</td></tr>
int    a  = 1  ;
double aa = 1.0;
/// </table>

これを対応するエディタで開けば、表として表示されるというイメージです。

こういったものが実際に使いやすいのかは不明ですが、いつか試してみたいです。

2006-10-30

[]方向性

やりたいことが一杯あります。一気に出来ないので小出しにしていましたが、散発的になってまとまりがなくなりました。お手上げです。

ここで整理するとか絞るとか考えるのが普通ですが、それをやったら負けのような気がします。どうしたものでしょうか。

新技術に乗っかってバンバン先進的なものを作ってみたいという衝動があります。逆に、作るならなるべく汎用的に作りたいという衝動もあります。これらは一見相反します。

全部自前で書くとプロトタイピングすら敷居が高く、いつまで経っても低レベルな作業だけしているような事態に陥ります。とにかく汎用性も何もなくても、素早く動かなくては意味がありません。

自分のことを振り返ると、すぐ必要な小物ツールはC#で作ります。それなら新技術だとか身構えないで、まずC#で適当に作ります。その際に.NET特有の機能に依存しないように注意して、後で気が向いたら下のレイヤを差し替えていくことにします。