自己紹介

  • 名前: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を参照するから、ライブラリ関数をコールする場所が無駄に肥大することはないと思う。
      • その対応表にもUUIDをつけて…
↑

OSECPU Tips

  1. Macでamakeの代わりをするには "make appname.ose"
↑

OSECPU Bugs

  1. @064a
    1. app0023(bball)をコンパイルしたところ、 　db2bin: error: LMEMPP(R00, 0x03, P01); となってコンパイルできない。
    2. 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
  • yaoさん、ご指摘ありがとうございます。ttwilbさんはWindowsのVisualStudio,私hikarupspはMacOSXのXCodeで開発しており、改行コードはCRLF,文字コードはUTF-8(BOMなし)に統一しているつもりなのですが、どうしても完全には同じにならないようです。何か良い解決策があれば教えていただけたらうれしいです。 -- hikarupsp 2014-03-17 (月) 17:23:58
  • PRegCopyの件ですが、この関数内に書かれているコメントアウトのコードは確かに間違っていました。yaoさんの言われた通りに元の実装ではなっていた（別関数ではなく直接書かれていた）のですが、MacOSX環境下ではこの方法ではMOVDQA命令が発行され、スタックのアライメントが合わず、アライメントエラーで落ちています。コメントについては、コミット7abdd91で修正させていただきました。ありがとうございます。 -- hikarupsp 2014-03-17 (月) 17:33:14
  • yaoさん、重要なご指摘ありがとうございました。我々開発者としても、コミットする環境の違いによってdiffがうまく動かないなど、様々な弊害を抱えておりました（困るのは開発者だけではないのですね）。アドバイス頂いたことを参考に改善に取り組みたいと思います。 -- ttwilb 2014-03-17 (月) 17:50:24
  • yaoさんのご指摘をふまえ、core.autocrlfの再設定を行いました。diffも正常に動作しているようなので、このまま様子を見たいと思います。今後も私の不勉強ゆえの問題があれば、ご指摘いただければ幸いです。よろしくお願いします。 -- ttwilb 2014-03-19 (水) 00:09:30
  • pullして調べてみました。(1)エンコードはファイルを最後に編集・コミットした人の設定に変更され、改行にはhikarupspさんはCR+LFを、ttwilbさんはLFを使っているようです。文字コードはお二人ともBOM付きUTF-8でした。こちらの勘違いで、このようなケースではcore.autocrlfは意図した挙動をしません。私は使ったことがないですが、gitattributesを設定するのがよさそうに思われます。次の2点をおすすめします: (a)一度エンコードの変更だけを含むコミットを行い、その後お二人とも一度ワークツリーを作り直す、(b)コミット前にはエンコードの確認もかねてgit diff --cachedを見ておく。(2)MOVDQAという命令があったんですね。16バイト境界にないと例外になる命令を、それを保証できないメモリ領域に対して吐くというのはコンパイラのバグではないでしょうか。この問題への対応を思いつくままに列挙すると、(a)単純さ優先: MOVDQA命令への最適化を(あれば)コンパイラオプションまたはpragmaで抑制する。(b)速さ優先: 関数OsecpuMain内でstruct Regsを定義している文に、メモリの16バイト境界に配置するよう強制するよう(あれば)pragmaを書く。(c)関数PRegCopy内で構造体のメンバを一つずつ代入する代わりにmemcpyで一気にコピーする(規格に厳密に従う書き方ではなかったはずですが、CでJITコンパイラを書くのにそんなこと言っても仕方ないですし)。(d)struct Regsより15バイト大きい領域をmallocで動的確保し、16バイト境界で始まる領域を指すポインタを作って使う。といったところでしょうか。いずれの方法にしても、こういう対処をしたとコメントに残しておくほうがよいでしょう。 -- yao 2014-03-19 (水) 22:44:03
  • うろおぼえだけどMOVDQAってたしかSSE2のあれで、たしかXMMレジスター用のMOVだったと思うけどこれってコピー元や先のメモリーの位置が１６バイト境界に無いとあれなんだけど、これじゃなくてMOVDQUっての使えば１６バイトになってなくても動いたような記憶。あとそうじゃなくてosecpuのドライバー側がやってるmallocWRCだかいうマルロックの中を作るときに、適当に１６バイトアラインするようなマルロックで作っとけば偶然上手くいくんじゃないかなとおもいました、マルロックのかわりにposix_memalignとかで。ためしても無いのにてきとう言ってます。まちがってたらごめんなさい -- けめっぽ 2014-03-21 (金) 16:14:27

コメントお名前NameLink
トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2014-03-21 (金) 16:14:27 (2040d)