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

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
また不可解な挙動を見つけました。今度はappackかdecoderのどちらかだと思います。
```
#include "osecpu_ask.h"

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

CALL(L_func2);

beginFunc(L_func); endFunc();
beginFunc(L_func2); endFunc();
```
上のプログラムをosecpu076dで実行しようとすると「JITC: label not defined」とエラーが発生します。a_4ose.oseのダンプとdebug:2オプションで得られるdebug2.binのダンプを読み比べると、後者からはfunc2の定義が失われてしまっています。当然、ラベルは定義されません。このバグは9個目の関数を書いたときに見つけましたが、起きる条件はまだ分かりません。回避方法があればそちらも教えていただきたいです。 -- yao 2013-09-17 (火) 03:38
「現状のappackとdecoderの組み合わせでは、一度も使われていないラベルで始まる関数の末端でバックエンドコードへの変換が中止される」という仮説を立てました。使っていなかった関数のラベルをPLIMMで一度使ってみるとエラーが起きなくなったので、ほかに何かあるまでこの方法で回避してみます。 -- yao 2013-09-17 (火) 08:57:32
利用されていないラベルを勝手に削除する機能は確かにあります。それが悪さをしている感じですね・・・。すみません。多分これも短時間で直せそうです、時間が確保できれば。 -- K 2013-09-17 (火) 09:04:25
ここまでで教えていただいたバグは全て対応しました。 -- K 2013-09-18 (水) 18:47:36
対応ありがとうございました。近いうちにこちらでもバグが取れたか確認してみます。さて、宣伝ですが、先ほどOSECPU-VMの「上で」動く世界初(たぶん)のプログラミング環境をリリースしました。 https://github.com/yuta-aoyagi/osecpu-lisp Pure Lispでプログラムを書くのは少し苦労するかもしれませんが、びっくりするくらい小さなインタプリタになりました。リリースモードだとわずか1412バイトです。もしよければ使ってみてください。 -- yao 2013-09-19 (木) 23:14:25
おお、すごーい！・・・Lispを使えない自分が残念です・・・。 -- K 2013-09-20 (金) 07:52:01
yaoさんのプログラムは、DAT_ENDマクロを使いこなしているところがかっこいいです（まだ紹介してないのに！）。 -- K 2013-09-20 (金) 09:36:57
page0056に登録していただきありがとうございます。ここまで小さくできたのは、作ったのがPure Lispと呼ばれる、最小限のLispだからでしょう。今のバージョンでは数値も文字列も扱いません。それでも、通常コンピュータで計算可能なあらゆる関数を計算できる(メモリと時間は十分に使えるとすれば)能力があります。実装し始めたときに考えた計画では、これから数値と文字列をサポートし、そしてこのLispからOSECPUへのコンパイラをLisp自身で書こうと考えていました。Lispであるというだけでユーザが少ないのは悲しいので、この2つより先にこのLispのチュートリアルを書き始めました。第1版は数日中に公開できる見込みです。 -- yao 2013-09-20 (金) 09:38:16
OSECPU-VMは実装も小さいので疑問に思ったことはすぐに調べやすいんです。DAT_SAマクロがデータ開始命令を書き行番号のデバッグ情報の出力を抑制するのだから、デバッグ情報の出力を許可するのは対になるであろうDAT_ENDマクロが妥当だと判断しました。そういえば、OSECPU-Lispを更新した場合ここで宣伝してもいいものでしょうか？　それとも自分のページを作ってそこに書いたほうがいいですか？ -- yao 2013-09-20 (金) 09:56
このimpressionsは基本的にOSECPUに関することなら何を書いてもいいので、ここで宣伝や告知をしていただくことはまったく問題ありません。でももちろんページを作ってくださってもいいです。両方でもいいです。 -- K 2013-09-20 (金) 13:19:00
私は http://ja.wikipedia.org/wiki/Brainfuck のインタプリタを作ってみたいと思いました。98バイトよりも小さくできるだろうか・・・。実用性のない、ただのサイズのチャレンジですみません！ -- K 2013-09-20 (金) 13:25:49
OSECPU-LispでLispのコンパイラを作るという計画は、かっこよくてわくわくしますね！ -- K 2013-09-20 (金) 13:31:29
[宣伝]OSECPU-Lispのチュートリアルの第1版を公開しました( https://github.com/yuta-aoyagi/osecpu-lisp/blob/master/tutorial.md )。感想や改良点の提案、やってみたという報告だけでもいただけるとうれしいです。 -- yao 2013-09-23 (月) 23:14:31
[宣伝]OSECPU-Lispのチュートリアルの第2版を公開しました(URLは上のものから変化していません)。主な変更は(1)S式の評価に記法を導入(2)リストと組み込み関数の関係の説明(3)特殊形式condの説明、の3点です。感想や改良点の提案、やってみたという報告だけでもいただけるとうれしいです。 -- yao 2013-10-19 (土) 01:15:18
mandel59さん、ようこそ！ -- K 2013-10-20 (日) 10:31:32
Osecpu 078d で新たに追加されたテトリスの出来が良すぎて生きるのがつらい・・・ -- 名無しさん 2013-10-21 (月) 00:37:19
MacOSX版OSECPUにメモリリークバグを発見しました。osecpu078dのosecpu.cで3311行目に相当するdrawRect関数ですが、colorSpaceとimageが解放されていません。CFReleaseでそれぞれの変数を解放する必要があると思います。 -- hikarupsp 2014-03-11 (火) 22:02:29
わおー。Livaさんに聞いてみますね。＞メモリリークバグ -- K 2014-03-14 (金) 16:18:03
hikarupspさん、バグ報告ありがとうございます。仰る通りcolorSpaceとimageでメモリリークバグが発生していますね。実はお恥ずかしい話、Macアプリの開発の経験不足より、contextの解放についてよく分かっておらず、（今でも分かってないのですが）contextを解放した時にプログラムが落ちるという挙動を見て、colorSpaceとimageも下手に解放してしまうのが怖かったため、解放せずに放置したと記憶しています。先ほど試した所、この２変数については解放できると分かったので、次のosecpuの更新でbug fixが為されるかと思います。今後ともバグを発見され次第、このwikiで報告をして頂けると非常に助かります。これからもよろしくお願いします。 -- Liva 2014-03-15 (土) 00:53:31
対応ありがとうございます。自分もこのバグを自力で発見したというよりは、XCodeのAnalyze機能で何度も同じようなバグを指摘されたために、すぐに思い至ったのです。もしXCodeをお使いでしたら、Product>Analyzeで、メモリリークの可能性のあるコードを検出できるので、活用してみるのもいいかもしれません。最近のコンパイラはすごいですよね（笑）。 -- hikarupsp 2014-03-15 (土) 13:32:45
hikarupspさんのUTF-8型のポインタっていうのは、実はSINT32でもできる。ファイルから読んだり書いたりするときにコンバートすればいいと思う。で、そういうコンバートは確かにシステムでやってくれたらいいのになとは思う。 -- K 2014-03-26 (水) 22:04:52
UUIDの利用支援も面白そうなアイデア。UUIDは128ビットなので、UINT128型を扱えれば、それで問題は一応解決する。OSECPUの先にある第三世代OSASKでは、レジスタ幅は最大256ビットになるので、128ビットくらいは余裕で扱える。・・・でもOSECPUとしては32ビットが上限なので、支援するにはAPIかなあ。 -- K 2014-03-26 (水) 22:08:57
Ubuntu13.10(32bit) などでも osecpu078d を動くように修正するパッチです。GCC4.8.x 以降で ++ のルールが変わったことが原因だったようです。 https://gist.github.com/takeutch-kemeco/9846313 -- けめっぽ 2014-03-29 (土) 20:40:41
Linux(32bit) での非X11環境（起動直後またはCtrl+Alt+F1〜7などで行けるDOSのような黒い画面）でも osecpu078d でテトリス遊べるようにするドライバーです（と、それをosecpu078d/osecpu.c に組み込んだ場合のサンプルも）。32bitリトルエンディアンのグラフィックボードのみ対応してます（Intel G31 オンボードグラフィックで動作テストしてます） https://gist.github.com/takeutch-kemeco/9703915 -- けめっぽ 2014-03-29 (土) 20:56:57
osecpu077dをクラッシュさせるバグ(脆弱性？)を見つけました。テストしてませんがおそらくosecpu078dも同様でしょう。
```
#include "osecpu_ask.h"
DB(0x03,0x81-0x40); DDBE(0);
junkApi_fopenRead(R00, P01, 1);
```
関数jitCompilerでPLIMMをコンパイルする際にレジスタの番号をチェックしていないため、構造体Regsのポインタレジスタより高位のメモリ領域を破壊できてしまうことが原因だと思われます。 -- yao 2014-03-31 (月) 14:01:15
これはひどい！教えてくださりありがとうございます。 -- K 2014-04-01 (火) 18:09:21
けめっぽさん、GCC4.8.x以降での問題を突き止めてくださりありがとうございます。そして、マニアックなドライバもありがとうございます！ -- K 2014-04-01 (火) 18:20:59
osecpu077dで任意のx86コードを実行させる脆弱性を見つけました。 https://gist.github.com/yuta-aoyagi/9935015 -- yao 2014-04-02 (水) 23:20:24
free周りの手抜きを狙われてしまった！！・・・ご指摘ありがとうございます。 -- K 2014-04-04 (金) 18:16:21
えっと,FrontPageがスパムを受けていたので回復しました。必要ないと思いますが、書いてあった文を載せます -- MANA 2014-05-26 (月) 05:39:01
スパムとされてしまい、投稿できませんでした。(当たり前か)。バックアップページ：http://osecpu.osask.jp/wiki/?cmd=backup&action=source&page=FrontPage&age=61 -- MANA 2014-05-26 (月) 05:44:19
MANAさんありがとうございます！ -- K 2014-05-26 (月) 07:50:16
FrontPageが書き換えられていました。緊急な対処が必要だと思ったので、勝手ながら最後のバックアップからコピーandペーストして”復旧”させていただきました。一応表示は戻りましたが、履歴から復元するやり方が間違っていたら申し訳ありません。確認していただけたらありがたいです。 -- ttwilb 2014-05-26 (月) 23:34:42
さらに数時間でまた書き換えられたようです。ttwilbさんと同じ方法で復元しました。 -- MANA 2014-05-27 (火) 04:34:52
さらに数分で書き換えられました。またも同じ方法で復元しました。 -- MANA 2014-05-27 (火) 04:43:46
戻し方は問題ありません。ありがとうございます。攻撃が激しいようなので、ページを凍結しました。 -- K 2014-05-27 (火) 07:09:25
このたびサーバーを作りまして、いろいろ作りました。それで、OSECPUの勉強を兼ねて、「30日でできるOS自作入門」みたいに、「初心者でもわかるOSECPU入門」というサイトを作りたいのですが、作ってよいでしょうか。 -- MANA 2014-05-31 (土) 11:58:08
もちろんいいですよ。＞MANAさん -- K 2014-06-01 (日) 09:43:03
ありがとうございます。Media Wikiで作成します。 -- MANA 2014-06-01 (日) 11:29:42
ところで、OSECPUのロゴ(カオスちゃんみたいな)はないのですか。 -- MANA 2014-06-01 (日) 13:14:19
やっぱり第三世代OSASKになる、ということでカオちゃんなのでしょうかね。あと109aのinteger.c:326 で初期化していない変数bitを使っているようですが...。 -- ttwilb 2014-06-01 (日) 18:00:36
うーん。kさんはどう思われますか。 -- MANA 2014-06-01 (日) 20:29:38
そうですね。そもそもOSECPU-VMプロジェクトはOSASK計画の一部なのです。ということで、ttwilbさんの予想は正しいです。 -- K 2014-06-02 (月) 11:25:30
初期化していない変数「bit」の件、発見ありがとうございます！ -- K 2014-06-02 (月) 11:27:51
では、「初心者でもわかるOSECPU入門」のロゴにhrb.osask.jp/wiki/hrblogo1.gifを使ってよろしいでしょうか。 -- MANA 2014-06-02 (月) 19:49:56
hideyoshiさんのサイトにもいっぱいありますよ！でもライセンスは分かりません。ごめんなさい。(追記: 大変ありがたいことに、このサイトの素材は自由に使ってよいようです。) -- ttwilb 2014-06-02 (月) 22:28:22
ttwilbさん、ありがとうございます。開設しました。http://mnas.0am.jp/osecpu/です。アクセスできたら、そこに何かページを作ってもらえませんか。まだ外部からアクセスしたことがないので。あとOSWiki も作りました。http://mnas.0am.jp/oswikiです。どちらもゆっくり書いていきます。 -- MANA 2014-06-03 (火) 07:59:13
MANAさんのサーバーにはつなげないっぽいですよ。そちらの環境からドメインが通っているか確認してみてください。 -- ttwilb 2014-06-03 (火) 22:45:42
ドメインは通っているけど、osecpu及びoswikiサブディレクトリにはつなげません。ディレクトリやファイルのオーナーやパーミッションを確認してください。 -- ttwilb 2014-06-03 (火) 22:52:43
ドメインに関連づけられているipアドレスがローカルアドレスみたいですよ(192.168.11.8)。だから外部からは接続できないのだと思います。ドメインに設定するアドレスはグローバルipアドレスでなければ、外から接続できません。グローバルipアドレスは取得されましたか？>MANAさん -- hikarupsp 2014-06-03 (火) 23:16:16
あと、小さいことですが、execStep_checkBitsRange()内で、prefix[0]がセットされている時はレジスタ値(といってもプログラムから見えない部分だと思いますが)をセットしているので、checkという名前にはすこし違和感があります。(ちなみにairJOsecpu Rev.2ではarrangeRegisterUpperBitsという名前にしています) -- ttwilb 2014-06-03 (火) 23:25:30
hikarupspさんの続きですが、ここのページの「あなたのIPアドレス」に表示されているIPをMyDNSのIPアドレス指定ボックスに入力してくださいね。 -- ttwilb 2014-06-03 (火) 23:27:17
質問ばかりで申し訳ないですが、VisualStudio君によればosecpu108aではRxxにBIT_DISABLE_REGを設定しているコードはないそうです。しかしinteger.cのいたるところで、Rxxがこの定数でないことを確認するIF文が見られます。では、この定数には一体どんな役割があるのでしょうか。 -- ttwilb 2014-06-03 (火) 23:59:59
Wikiがメインページへ転送させる際、ローカルアドレスで指定したようです。…うぅ設定中にOSが壊れちゃいました。復旧に時間がかかります。 -- MANA 2014-06-04 (水) 07:32:05
>checkという名前にはすこし違和感があります。・・・なるほど、それは一理あります。まあprefix[0]による修飾はかなり「まれ」なので、ほとんどの場合は名前のとおりcheckなのです。だから関数名はそのままにしますが、コメントは入れておくことにします。正しい名前はcheck-or-fixくらいでしょうかねえ・・・。 -- K 2014-06-04 (水) 08:31:03
BIT_DISABLE_REGについて。ご指摘のとおり、今のVMではRxxのbitがBIT_DISABLE_REGになることはありません。ではこれがセットされるのはどういう状態かというと、高速モードなどの「bitを持たないVM」が実行していた状態をいったん停止して、bitなどのフィールドを付与して安全モードで再開した直後の場合のみに生じる状態です。もともとフィールドがなかったので値が分かりません。仕方ないのでBIT_DISABLE_REGにすることになっています。 -- K 2014-06-04 (水) 08:59:23
今更命令セットについて一つ考えたのですが、DATA命令はこれまでラベルの直後にしか出現しない命令だったと思います。なので、DATA命令のオペランドに、直前のLB命令にあたるフィールドを入れれば、わずかではありますがアプリサイズを削減できると思います。 -- hikarupsp 2014-06-04 (水) 20:06:51
つまり、今までLB+DATAでセットだったのを、DATA命令のみで完結できるようにしたらどうか、ということです…。 -- hikarupsp 2014-06-04 (水) 20:08:13
なるほど、そういうことでしたか。bitが無い環境のことも考えられているのですね。そうすると、bitが無い環境だと、prefix2f[0]が立っている時に違う動作をしてしまうということで、VMを作る側もプログラムを書く側も気を付けた方がよいですね。 -- ttwilb 2014-06-04 (水) 23:02:50
>bitが無い環境だと、prefix2f[0]が立っている時に違う動作をしてしまうということで、VMを作る側もプログラムを書く側も気を付けた方がよいですね。・・・この部分についてもう少し理解してもらえるように説明します。 -- K 2014-06-05 (木) 06:14:03
- 2F-0プリフィクスがあると、安全モード・高速モードで結果が変わるのではないか？・・・これはYesです。しかしNoでもあります。
- 高速モードでは、bit[]がなく、したがってレンジチェックもされず、レジスタの上位ビットにゴミが混ざっていても放置されます。高速モードでは2F-0プリフィクスがあっても無視されて値の補正はありません。ゴミがあっても問題ないからです。
- 安全モード時に上位ビットのゴミを常に取り除いてきれいにしておくのは、レンジチェックのためだけなのです。
- 上位ビットのゴミを明示的に取り除くためには、SBXという命令を実行します。いつでもこれでゴミのない結果に修正できます。これは安全モードでも高速モードでもどちらでも確実に動作します。
- ということで2F-0プリフィクスがあってもなくても、ゴミ部分以外の意味を持つビットだけに注目すれば結果は変わっていないはずです。しかしゴミ部分については結果は変わっているでしょう。先のYes・Noはそういう意味です。
- 2F-0プリフィクスの意味：この演算結果は一時的にどうしても上位ビットにゴミを生じてしまうので、たとえ安全モードであってもレンジチェックをするな、プログラマはわかってやっているのであって、ミスではないぞ。
```
たとえばこんな状況：
R00に0x12、R01に0x34が入っている。R00とR01はどちらもbit=32。これらを足し合わせて、下位4ビットだけがほしい。
これには2つの書き方がある。
(1) ADD(32, R02, R00, R01); LIMM(4, R3F, 0x0f); AND(4, R02, R02, R3F);
(2) PREFIX_2F(0); ADD(4, R02, R00, R01); LIMM(4, R3F, 0x0f); AND(4, R02, R02, R3F);
1のやり方はプレフィクスがいらないけど、ADDは32ビットで演算している。これは必要のない精度の計算だといえる。
無駄な書き方を「強要」しなければいけないとしたら、それは本当に「いい仕様」といえるだろうか？
それに対して2は不要な演算は全くない。
```
復旧が終わると同時にWikiの方もなおりました。Wikiの感想ページに何か書き込んでもらえませんか。 -- MANA 2014-06-05 (木) 18:57:26
http://mnas.0am.jp/osecpu/ とhttp://mnas.0am.jp/oswiki -- MANA 2014-06-05 (木) 18:58:42
ttwilbさん、ありがとうございます。 -- MANA 2014-06-06 (金) 05:53:14
なるほど、ということはVM側のbit[]は、オーバーフローのチェックと各オペレーションの引数bitのチェックをするためのもので、それが必要ない(エラーのない)コードであればVM側にbit[]が無くても正しく処理できる、ということですね。そう考えるといろいろな仕様がつながってくるように感じます。ありがとうございます。 -- ttwilb 2014-06-06 (金) 11:59:53
osecpu本体のみですが、MacOSXで動作するようにいくつか変更を加えてみました。主な変更部分はdriver.cのmain関数です。それと、これをコンパイルするために必要なMakefileもつけました。
- https://sourceforge.jp/users/hikarupsp/pf/OSECPU_VM_2/scm/blobs/mod_for_mac_110d/vm/driver.c
- https://sourceforge.jp/users/hikarupsp/pf/OSECPU_VM_2/scm/blobs/mod_for_mac_110d/vm/Makefile -- hikarupsp 2014-06-12 (木) 23:10:32
どうやらdriver.cを修正しなくてもMakefileの変更だけでうまく動くのですが、XCode経由でビルドしたときにウィンドウが出ない症状を直すためには、上記のdriver.c:main()の修正が必要みたいです。 -- hikarupsp 2014-06-12 (木) 23:17:21
hikarupspさんへ。どうもありがとうございます。そのドライバを採用させていただきます！ -- K 2014-06-13 (金) 09:28:11
ttwilbさんへ。bit[]について分かっていただけたようでうれしいです！ -- K 2014-06-13 (金) 09:32:57
hikarupspさんへ。LB+DATAの提案の件です。まずサイズ重視のフロントエンドコードでは、rev1の時点ですでにhikarupspさんの提案のようになっています。しかしシンプルさ重視のバックエンドではrev2でもDATA命令にLBの機能を含ませていません。これがいいかどうかは確かに疑問もあるのですが、とりあえずこのまましばらくはやってみたいと思います。 -- K 2014-06-13 (金) 09:41:54
beginFunc()とendFunc()で何をやっているのか教えてください。 -- ttwilb 2014-06-22 (日) 09:57:18

コメント	お名前	NameLink