自己紹介
- 名前:hikarupsp
- OsaskWiki内のページ
- はりぼてOSからKさんの世界に引き込まれた。
- CHNOSProjectという自作OSのプロジェクトを（今のところ一人で）進めている。
- 最近は人工知能を研究しようとしていて、OS自作の方は進まなくなってしまった。
- 人工知能を研究している理由は、膨大な情報を分かりやすい形に変換することができれば、人類はまだ進化の余地があると考えたから。
- 進化に伴って知るべき情報は増えてゆくけれど、それにかかる学習の時間は以前より増えてしまう。
- そうすると、やがては人類は、「すでに分かりきったこと」を学習するだけで寿命がつきてしまうのではないか？と思った。
- その意味では、Kさんの考える「機能密度」という概念は、人類の処理能力という有限のリソースを十分に活用するためにも使えるのかもしれない。
- 学校が忙しくて、人工知能すら進まない…。
OSECPU関連計画
- WebCPU-VM
- OSECPU-VMのJavaScript実装（動作する状態・APIの大部分は未実装）
- OSEC
- OSECPU-VMのためのC言語風言語（一応動作する）
- 最初はJavaScriptで作って、その後OSECを使ってOSECPUで動くOSECコンパイラを作ればいいと思う（笑）。
- HeavyOSECPU
OSECPUに欲しい機能
あったらさらにOSECPUの発展性が上がりそうだと個人的に思う機能（そのうち派生版OSECPUを作ると思います）
- ポインタタイプにUTF-8が欲しい
- テキストの扱いを簡素化できるし、既存のUTF-8データを簡単に利用できる。
- サイズを追求する、という点ではボトルネックになるかも
- そのメモリを読み書きすると、ポインタを一つ進めると文字を一つ進めたことになり、取得・設定できる値はUnicodeの値そのもの。
- 実は人工知能をOSECPUで実装したい。
- だけど日本語テキストを扱える環境がまだそこまでなってないから…
- UUIDを簡単に使える機能
- UUIDレジスタ、それに関する代入命令、UUIDラベル、UUIDジャンプ、UUID生成命令が欲しい
- 異なるアプリやライブラリ間で関数呼び出しをするとき、SINT32のラベル番号のみでは衝突が容易に発生しそう
- UUIDを利用したラベルもあれば、確実に飛び先の関数を特定できる
- アプリごとにUUIDを割り振って、そのUUIDとSINT32のラベル番号を指定しても飛べるようにする。
- 同じ機能を持つ関数には同じ「機能UUID」を振って、さらに「固有UUID」を振れば、ライブラリ関数のバージョンを取っ替え引っ替えするのが簡単になる？
- でも結局はサイズが大きくなる問題が…
- OS側がUUID対応表を持てば、デフォルトではそこに指定されているUUIDを参照するから、ライブラリ関数をコールする場所が無駄に肥大することはないと思う。
OSECPU Tips
- Macでamakeの代わりをするには "make appname.ose"
OSECPU Bugs
- @064a
- app0023(bball)をコンパイルしたところ、
db2bin: error: LMEMPP(R00, 0x03, P01);
となってコンパイルできない。
- osecpu_ask.hにLMEM0PPのところを真似して
#define LMEMPP(reg, typ, preg) LMEM(reg, typ, preg, 0); PADDI(preg, typ, preg, 1)
と書いたところコンパイルも通り、正しく実行できた。これはアプリソースとヘッダファイルどちらを直すべきなんだろう…
amake.sh
amakeはバッチファイルなのでMacintoshでは動かない…。
こんなことしなくてもmake appname.ose で生成できるじゃん…もっとよく調べるべきだった。
#!/bin/sh
# gcc実行コマンドを設定
cc=gcc
${cc} -x c -E -o a_0ask.txt ${1}.ask
./osectols tool:aska in:a_0ask.txt out:a_1oas_${1}.txt
${cc} -x c ${2} ${3} ${4} ${5} ${6} ${7} ${8} ${9} -E -P -o a_2cas.txt a_1oas_${1}.txt
./osectols tool:lbstk in:a_2cas.txt out:a_3cas.txt lst:a_3lbl.txt
./osectols tool:db2bin in:a_3cas.txt out:a_4ose.ose
./osectols tool:appack in:a_4ose.ose out:${1}.ose
- ポイント
gccはファイル形式を拡張子で判断してしまうので、"-x c"オプションで、言語解釈をCだよと教えてあげないとプリプロセッサすら通してくれない。"linker input file unused because linking not done"とか言われる。
osecpuをMacOSX Xcodeで！
HariboteOSでも同じことをしているので。
- osecpu.cとtek.cを追加。
- BuildSettingsでPreprocessorMacroにシンボル定義"JITC_OSNUM=0x0002"を追加
- FileTypeはCSource
- BuildPhase.LinkBinaryWithLibrariesにCocoa.frameworkを追加。
現状:Illegal instruction: 4で落ちます…。
配布されている状態で、説明の通りにコンパイルを行っても、落ちます…。
Xcodeなんて使わなくても、forMacOSフォルダ内のMakefileをソースと同じディレクトリにコピーして、
make osecpu
で、きちんと動作するバイナリが生成されます。
"make"だけじゃだめだった…。
default:
make osectols
make osecpu
をMakefileの一般生成規則の下に追加すると良いかもしれない。
コメント
- 時間なんて所詮四つの次元の内の一つでしかない。 -- ttwilb 2013-07-09 (火) 00:55:55
- MacOS版のosecpu生成で、forMacOSディレクトリからMakefileを取り出して、それをosecpuディレクトリにコピーしてからmakeしたらうまくいきますか？ -- K 2013-07-09 (火) 10:05:21
- あ…できました！Makefileをコピーして、"make osecpu"でosecpuバイナリが生成されるんですね…。
昨日は"make"しか試していなくてosectolsしか生成されておらず、今Makefileを読んで、defaultターゲットがないのに気付きました。ありがとうございます。
bball(app0023.ose)もきちんと動作しました。お騒がせしてごめんなさい。 -- hikarupsp 2013-07-09 (火) 16:08:35
- Xcodeでうまく行かない原因もわかりました。64bitでコンパイルすると、jitfuncのあたりがずれてしまって動かないようです。32bitでコンパイルすれば問題なしでした。 -- hikarupsp 2013-07-09 (火) 16:23:36
- 解決して何よりです。 -- K 2013-07-09 (火) 17:17:36
- HeavyOSECPUをcloneして少し読ませていただきました。Sourceforgeのフォーラムは無効だったので、おせっかいかもしれませんが2点こちらにコメントいたします。(1)あなたとttwilbさんとではソースコードの改行コードが違うようです。mergeのたびにconflictが発生していて、見ていて危なっかしく感じます。どちらか一方に統一してはいかがでしょうか。あるいは(どちらかがWindows環境ならば)core.autocrlfオプションを導入を検討されてはいかがでしょう？ (2)PRegCopyは「*dst = *src」と実装すべきではないかと思われます。もしコメントアウトされている実装に変更してからエラーが発生するようになったとしたらこれが原因かと。もしエラーが発生するがためにコミット4d5d6faの変更をしたのだとしたらこちらの勘違いなのでこの点は無視してください。 -- yao 2014-03-17 (月) 10:36:48
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
