impressions のバックアップ(No.18)

impressions

(by K, 2012.09.09)
簡易掲示板です。

自己紹介ページを作っていない人は、NameLinkにチェックを入れないでください。 -- K 2012-09-10 (月) 06:58:43
カウンタのyesterdayがいまいちうまく機能していない様子。まあいいや。 -- K 2012-09-11 (火) 07:34:54
ついに誰かが見始めたかも！？けいじばんはここですよー。 -- K 2013-03-14 (木) 15:42:52
質問がある場合はこちらへどうぞ。 -- K 2013-07-07 (日) 15:17:48
今、niliumのサブプロジェクトでOSECPU4Androidのようなものを作ろうと考えているのですが、そういった需要ってあるのでしょうか？ -- ttwilb 2013-07-18 (木) 14:16:13
つまりOSECPUのアンドロイド版ですよね。はい、需要あります。少なくとも僕はほしいです。・・・当面は一部の命令しかサポートできてなくてもいいです。でももちろんバイトコードは共通でお願いしますね。 -- K 2013-07-18 (木) 15:57:16
了解です。試してみます。ただしJITコンパイラは難しいと思います(笑) -- ttwilb 2013-07-19 (金) 10:34:25
C#でOSECPUバイナリインタプリタを作ればiOSにもAndroidにもLinuxにもMacにも移植可能ですね。VM on VMなのはあれですがOpenGLで描画をすれば描画APIもすべての環境で動作します。 -- lambdalice 2013-07-19 (金) 16:03:12
JITコンパイラをあきらめれば、移植性はかなり上がるということか・・・なるほど・・・。それでOSECPUは遅いと誤解されたら嫌だけど、でも動かないよりは動いたほうが断然マシなので、「インタプリタ実行＋OpenGL描画」版っていうのはありなのかもしれない・・・。 -- K 2013-07-19 (金) 16:10:01
MacOS版は既にかなり移植されていますし、Linux版については、x86用ならそれほど苦労せずにできそうかなあという気はします。 -- K 2013-07-19 (金) 16:14:19
あと、OSECPUのLLVM front/backendを作って（難しそう）あげれば、C++でもC#でもLLVMに対応するあらゆる言語で書いたコードをOSECPU上で動かすことが可能です。 -- lambdalice 2013-07-19 (金) 16:16:58
こういう意見が出て、そしていつか本当にやってくれる人が出てくるので、オープンソースプロジェクトはやめられないですね！ -- K 2013-07-19 (金) 16:21:49
でもLLVMのバイトコードを実行するだけであればOSECPUである必要はないと思います -- ttwilb 2013-07-19 (金) 20:33:20
そんなこと言ったら、なんだってOSECPUである必要はなくなってしまうんじゃないの？・・・僕は逆に考えるなあ、OSECPUアプリを好きな言語で作れるようになるんだから、とってもいいじゃないかと。 -- K 2013-07-19 (金) 20:44:13
僕が言っているのは、LLVMのバイトコードからOSECPUのバイトコードを生成するという意味です。LLVMのバイトコードをそのままOSECPU上で実行するという意味ではありませんので誤解なきよう。 -- K 2013-07-19 (金) 20:46:16
あ、なるほど、そういうことでしたか。失礼しました。もしそれができたら確かにLLVMの恩恵を活用できそうですね。 -- ttwilb 2013-07-19 (金) 20:55:35
.NETのクラスライブラリもガリガリ使えるし。 -- ttwilb 2013-07-19 (金) 20:57:29
ttwilb/leafのページを管理者権限で削除しました。 -- K 2013-07-27 (土) 18:23:32
WebCPU-VMの紹介をしていただきありがとうございます！なのですが、どうやら紹介ページへのリンクが韓国語版？になってしまっているようなので、日本語版に修正していただけると嬉しいです… -- hikarupsp 2013-09-04 (水) 17:54:05
おやまあ！失礼いたしました。・・・koをはずせばいいのかな？ -- K 2013-09-04 (水) 21:41:01
よく分からない挙動を見つけたのでバグか仕様か教えてください。
```
#include "osecpu_ask.h"

#define L_func	LOCAL(0)
LOCALLABELS(1);

#define func(x) P31 = x; CALL(L_func)

// main
do {
	VPtr p:P01;
	junkApi_malloc(p, T_VPTR, 1);
//	PSMEM0(P28, T_VPTR, p);
	func(p);
	R23 += 0x23;
}

beginFunc(L_func);
do {
	R20 += 0x20;
	PLMEM0(P21, T_VPTR, P31);
	R22 += 0x22;
}
endFunc();
```
上に貼り付けたプログラムをosecpu074dで実行すると、R20=0x20、P21=null、R22=0x22、R23=0x23と期待通りの結果を得ました。ここでPSMEM0の行を有効にして実行すると、P21=P28だけが変化すると期待していますが、P21=P28のほかにP22=0も変化してしまいます。どうやらPSMEM0の行が有効ならば、PLMEM0以降の命令は実行されずにfuncから帰るようです。かなり不可解な挙動なのでこれはバグではないでしょうか？ -- yao 2013-09-12 (木) 22:42
上記の文の「P22=0」は「R22=0」の書き間違いでしょうか。なるほど、確かに不可解ですね。別の方からはPADDもなんか微妙におかしいという指摘も受けました。どちらもたぶんバグです。少し時間をかけて調べます。できれば今月中に何とかしたいです。 -- K 2013-09-14 (土) 00:16:16
yaoさんへ。上記再現コードを使って確かにおかしいことを確認しました。syslib.oseのバグです。手元では修正できたので次のバージョンで反映します。どうもありがとうございました。 -- K 2013-09-14 (土) 01:02:30
どういたしまして。「P22」は書き間違いでした。さて、今度は、仕様なのかバグなのか本当に境界的な挙動を見つけました。
```
#include "osecpu_ask.h"

junkApi_malloc(P01, T_VPTR, 1);
PSMEM0(P28, T_VPTR, P01);
PLMEM0(P01, T_VPTR, P01);
```
上のプログラムをosecpu076dで実行するとP01に不正なポインタが入ります。P01=P28であっても、PLMEMの両オペランドが一致してはならないという仕様でも、どちらでも納得はできます。 -- yao 2013-09-14 (土) 22:59
おっとこれはバグ（脆弱性）ですね・・・。P01=P28になるのが正しい動作です。セキュアなOS（VM）だと言っている以上は、不正なポインタなど生じてはいけないので、何とかして直します。 -- K 2013-09-15 (日) 06:52:53
原因： PLMEMの両オペランドが一致した場合に対する考慮が不十分。P01とP02でこの現象が起きる。P03以降は実レジスタに割り当てられていないのでこの問題が起きない。・・・たぶん1時間もあれば修正と動作チェックができると思うのですが、なかなか時間が取れません。それまでは回避してもらえると助かります。 -- K 2013-09-16 (月) 12:33:04

コメント	お名前	NameLink