2013_0002 のバックアップ(No.1)

バックアップ一覧
差分を表示
現在との差分を表示
ソースを表示
2013_0002 へ行く。
- 1 (2013-08-25 (日) 01:52:07)
- 2 (2013-08-25 (日) 01:59:57)

2013年のメモ #0002

↑

2013.04.03 Wed

世間では「他人と同じことはするな」みたいなことを言う人がいる。いや、僕だって同じようなことはいう。他の人と違うことをするのは、希少価値があってむしろいい、と。
しかしちょっと待ってほしい。僕は先の人と一緒にされたくはない。僕はするなとは言ってないのだ。
そもそも他の人と同じかどうかなんてそれほど重要だろうか。もっと重要なのは、自分がやりたいかどうかだ。やりたいことに新規性がなかったらどうするか？気にしないでやればいいではないか。どうして他人に先を越されたらやめなければいけないのだ。
- どちらも同じくらいやりたいときに、どちらを取るかで決めるために新規性を使うのはいいと思うけど、やりたい気持ちとは無関係にまず新規性ありきで考える人は正直理解に苦しむ。もしかしてこの人はやりたいことがなにもない、かわいそうな人なんじゃないかとすら感じる。
ついでなので書くが、僕は最初にneriさんのCLEを見せてもらった時、あまりに感激して、第三世代OSASKはやらなくていいんじゃないかとすら思った。ちょっとやそっとじゃ超えられない感じがした。でも僕は結局辞めずに設計を続けて、それを転用してOSECPUを作った。そしてOSECPU上で改良を続け、それを第三世代OSASKにフィードバックしている。
今では、OSECPUはCLEとは違った価値を有している。僕はそう思う。他人はそう思わないかもしれないし、neriさんもそう思わないかもしれないけど、とにかく僕はそう思う。僕は新規性がないということを理由にやめなくてよかった。続けてよかった。
そもそも違う人が作れば違うものができて当然である。その差異が新たな新規性を生むことだって十分にありうる。だからやってみなくちゃわからない。
- やる前にあきらめるような人たちは、もしかしたらそれはそれでそれなりにいいこともあるのかもしれない。だから別にそれを批判するつもりはない。でも僕は僕のやり方を変えるつもりはない。

↑

2013.04.05 Fri

neriさんはCLEでのSIMD命令サポートについて思案中みたい。すごいなあ。
- http://nerry.hatenablog.com/entry/2013/04/05/140159

↑

2013.04.06 Sat

x86ってLOOP命令とかがあって、これはつまりECXが0になるまで繰り返すわけだけど、これってカウントダウン方式なので、あまり自然ではない気がする。カウンタが単に回数しか意味しない場合はカウントアップでもダウンでも大差ないけど、添え字とか順番とかを意味する場合は、カウントアップしていくほうがずっと使い道がある。
まあゼロとの比較だとCMP命令を省略できて速いという事情があるにしても、それならマイナスから数えてカウントアップでゼロにする方向で仕様ができていればよかった。引いていく仕様は失敗だったのではないかと僕は思う。

↑

2013.04.07 Sun

C言語で、0から始まる数字は8進数というルールがあるけど、これは失敗仕様じゃないかとよく思う。10進数を0から書きたい場合はある。0o123みたいにすればよかったのに。あと2進数指定を持っていないのも多分失敗だと思う。
CLEのアセンブラは代入形式とか不等号が使えてうらやましい・・・
- https://github.com/neri/cle/wiki/Assembly-Language
- まあうらやましければ作ればいいわけだけど、できればASKA的な高級なアセンブラは、OSECPU上で動かしたいと思っているので、作りにくくて結局苦戦中。
- 自分でもなんか不必要な苦労をしている気がしないでもない。

↑

2013.04.09 Tue

CLEはアセンブラ内蔵という道を選んだらしい。なるほど・・・。
- http://nerry.hatenablog.com/entry/2013/04/07/014134
- でもアセンブラがないとしんどくてやってられないという気持ちはわかるなあ。僕もまったく同じだったから。

↑

2013.04.10 Wed

プログラムを書いていて、大きな構造体とか配列とかを扱っていて、2つのプログラム間で挙動が同じになるはずなんだけど同じにならず、じゃあどこが違うんだ？となった。その時に適当なハッシュ関数を用意して、構造体のハッシュ値を計算させてみたら比較が容易になってすぐに原因を特定できた。これって便利な方法だなと思った。
- ちなみにFNV32を使った。

↑

2013.04.15 Mon

neriさんのブログから：
- http://nerry.hatenablog.com/entry/2013/04/15/014012
- >命令文で指定されていないレジスタを勝手に使うのはアセンブラとして逸脱しているという考えから、１つの命令で表現できない複雑な演算命令はサポートしません。
- いや全くそのとおりだなと思いました。アセンブラ好きとしては、全面的に賛成しないではいられません！
- しかし一方で、OSECPUや第三世代OSASKでしか通用しないようなアセンブラを覚えてくれというのも非常に気が引けます。C言語に毛の生えたようなものだからまあいいか、くらいにしておかないと、すごく申し訳ない気がします。
- ということで、僕は高級アセンブラを作ることにしました。まあ、テンポラリレジスタを必要としない式を書いていれば、書いていないレジスタを勝手に使われる心配はありません。
- ちなみに勝手に使われるレジスタはR00～R0F、P02～P0Fです。これで足りなくなるとギブアップするようになっています。この辺が高級言語になりきれないアセンブラの限界ですね。
- テンポラリレジスタがいっぱいあるアーキテクチャだと高級アセンブラを作るのが難しくないんだと、土曜日に気づきました。数式を逆ポーランド記法に変換出来れば、あとはテンポラリが必要な部分に適当に割り当てていくだけで作れそうです。
  - まあテンポラリレジスタが少なくても、テンポラリなメモリがあれば代用はできると思う。
- ちなみに最適化をしないという考え方もすごく共感しています。基本的には勝手なことをしないで、書いてあるとおりに動くのがアセンブラのあるべき姿だと思っているので、僕もその考えには大賛成なのです。

↑

2013.04.16 Tue

neriさんがアセンブラの代入形式について考察していました。
- http://nerry.hatenablog.com/entry/2013/04/16/135045
実は僕も昨日から少し考えていました。勝手にテンポラリレジスタを使ってほしくない場合はどう書かせればいいかなーと。
- 一つのアイデアとして、以下のような表記を検討しています。
  - %(R01 = 3, R02 += 1);
- カッコの中のコンマは、コンマ演算子です。

↑

2013.04.27 Sat

neriさんがIntel版のAndroid端末を手に入れてARM版のCLEを実行させてみる実験をしてすごいことになっている模様。うらやましいなあ。
僕はついにOSECPUのフロントエンドのバイトコード（といっても第二世代OSASKのときのように4bit単位なんですが）をやって、機能密度でCLEにどこまで追いつけるのかに挑戦しようかと思っています。
- だってosecpu.exeの小ささを取り柄として紹介してしまうと、じゃあアプリのサイズは？ってなるのは自然な流れだから。

↑

2013.05.08 Wed

charsというアプリがある。第二世代OSASKでは13バイトだった。そしてneriさんのCLEではなんと11バイトだった。これはすごい！・・・では第三世代OSASKではどうだろうか。
第三世代OSASKではOSECPUとは異なりシグネチャが2バイトになる。
```
4702? BC0C20 5????? BDC7F
```
おお、11バイト。ということで、ぎりぎり追いつけそう。
じゃあhelloはどうなるのか？
```
4702? 5?? +12
```
うーん、やっぱり16バイトか。これは第二世代OSASKと同じだなあ。

↑

2013.05.20 Mon

osecpu_0001の仕様だと、charsは9バイトにできるかもしれないぞ・・・。
```
05e?60c20c7f51?1b0
```

↑

2013.05.21 Tue

なんか最近のOSECPUはいじっていると変な感触がある。なんというか僕の常識が通用しない。
僕はプログラムを書くときに、これはだいたいこのくらいのサイズになるだろうという感覚を持ちながらやっている。しかしOSECPUはこの感覚が通用しない感じがする。小さくなりすぎる。本当にすごい。・・・僕の時代は終わったのかもしれない。
ちなみにapp0024はまだ小さくする余地がある。bballとかグラデーションとかは限界だと思う。

そういえば第一世代OSASKでは、5/12に512バイトコンテストとか、10/24に1024バイトコンテストというのがあった。これらは512バイトや1024バイト以内でどれだけおもしろいプログラムを作れるか競うもの。・・・これ、OSECPUでやったら楽勝なんじゃないかと思う。うーん、やっぱりOSECPUはとんでもないな・・・。
OSECPUは役に立つとかそういうものではなくて、アートとして楽しむのがいいのだと思う。無駄を排した作品は美しい。
- もちろんフロントエンドコード抜きで見れば、教材としても使えると思うけど（それくらいの役に立つようにソースを整理しなければ）。

↑

2013.05.22 Wed

突然ですが、僕はOSASKコミュニティと和解しようかと検討中。
- ええといろいろあって、今はOSASK計画のメンバーは僕一人で、コミュニティは僕抜きの残りのすべての人が入っている状態なのですが、これらを再統合しようかということです。OSASKコミュニティの復活ですね。
- 僕が外部からのコンタクトを直接受け付ける状態にすることはもちろんリスクがあって、また僕個人の不利益になるかもしれないわけですが、しかし今回は（前にはなかった）メリットもあるので、それならまあいいかなーと。

↑

2013.05.24 Fri

これはいい記事だなーと思いました！
- 「学んでから作るのではなく、作ってから学ぶ」
- http://d.hatena.ne.jp/Hamachiya2/20121114/programming
```
「自分は早くプログラマになりたい、作りたいアプリもある。 　だけど来年にならないとプログラミングの授業が始まらないから、作れない」
```
- 本当にこういうことを言う人が最近はたくさんいる。僕は学校でプログラミングを覚えたわけではないから、正直なところこんなことをいう人の気持ちが分からない。世代間ギャップかもしれない。
- この記事は、そんな人への良いアドバイスになっていると思う。

↑

2013.05.27 Mon

０から作るOS開発
- http://softwaretechnique.web.fc2.com/OS_Development/
- このサイトの情報がかなり「使える」。特に画面右の「Tips」はここ最近何度使ったかわからないほど使った。僕はこれらの情報を知らないというわけではないんだけど、手元で資料を探して確認するよりも、ここで確認するほうがずっと速い。

↑

2013.05.31 Fri

このURLで検索したら面白かったのでメモ：
- https://twitter.com/search/osask%20OR%20osecpu%20OR%20OS%E8%87%AA%E4%BD%9C%20-sekachaku

↑

2013.07.19 Fri

文章を書くときに、できるだけ難しい言葉や概念を使わないようにして対象者へのハードルを減らすことがあるけど（中学生でもわかる、とか）、それが常にいいこととは限らない。それでかえって回りくどくて分かりにくくなると、結局誰にとってもわからない文章になる危険性がある。

↑

2013.08.21 Wed

neriさんはCLEをスタックマシンベースに改造するらしいです。
- http://nerry.hatenablog.com/entry/2013/08/20/071532
```
スタックベースにするとレジスタベースの時より機能密度が上がることが期待できます。
```
- これは僕も何度も聞いたことがあります！
- でもこれってどうなのかな。僕はOSECPUでレジスタマシンでも負けないというか、レジスタマシンのほうがむしろ機能密度が高くなると証明したつもりになっています。
- スタックマシンだと確かにテンポラリ変数の扱いは有利です。長い式も有利です。でも実際のプログラムは i++; とか a = b + c; 程度の式ばかりで、むしろスタックに積みおろしをするための指示子の分（実質1ビット程度？）のぶんだけ損をしている気がします。
- しかしまあ結局はやってみないと分からないので、neriさんの結果から目が離せません！

↑

2013.08.24 Sat

neriさんの検討が面白いです。
- http://nerry.hatenablog.com/entry/2013/08/24/064220

僕だったらスタックマシンの試作を

|4|   load c
|4|   load b
|4|4| add
|4|4| store a
=24

とかにするかなあ。loadは使用頻度が高いので、0～Dで、14レジスタに対応。
- いくつかは定数ロードにしてもいいかも。
add はF0とか。
store a はE0とか。

しかし3レジスタの16に勝つのは難しい。とはいえ、OSECPUの場合
```
|12|4|4|8| add a,b,c
```
なので、28だったりする。・・・あれ？

OSECPUの3項型addが長いのは、2項型を優先しているため。
```
|8|4|8| add a,b
```
これなら20で済む。

OSECPUの第三項が8なのは定数を優先しているため。
```
|8|4|4| add a,2
```
これなら16で済む。

スタックマシンの場合2項型とかを工夫することはできず、つねに24になる気がする。
でもloadをひとつつぶしてそれをaddにするなら、addだけは20にできます。でもこれをやりすぎると、短い形式でloadできるものが減ります。
あとstoreも、load元へ書き戻すという命令を作れば、そしてそれもloadをつぶして実現するなら、2項演算みたいになって、addはついに16になるかも！
まあload元へ書き戻すのはよくても、add命令を4にするのはやりすぎかなあ。他の演算命令はどうするんだっていう話になるし。だからやっぱり演算子は8のままで。
ちなみにOSECPUの改善案では、演算子に応じてよく使う定数演算が変わるだろうということで、それを配慮してもっとコンパクトにしようとしています。つまり、文脈が活かせるレジスタマシンはやっぱり機能密度的に有利なんじゃないかと。

↑

こめんと欄

こんばんわ。ここへのリンクって貼っても大丈夫ですか？ちなみにMacだと/Volumesにラベル名でマウントされます（重複がない場合） -- neri 2013-03-07 (木) 23:00:52
リンクOKです。おお、Macは偉いですね！ -- K 2013-03-08 (金) 22:05:09
10年ほど前にOSASKに興味を持ち、当時はいろいろご質問させていただいたりとお世話になりました。現在もそうですが、当時はプログラミングなど全くできないレベルでしたが、現在もOSやプログラミングに興味を持っており、もしまた、OSASKやOSについて勉強させていただける機会があれば、ぜひまた、OSASKコミュニティに参加したいです。宜しくおねがいします。 -- まさや 2013-05-23 (木) 09:04:48
こちらこそよろしくおねがいします！ -- K 2013-05-25 (土) 16:00:23

コメント	お名前	NameLink