Origin : piece-me.org
File :
Source code :
Original description :
「PNG形式」の画像ファイルを、P/ECE上で表示します。
インストール方法は次のとおりです。
操作方法は次のとおりです。
Origin : piece-me.org
File :
Source code :
Original description :
「GIF形式」の画像ファイルを、P/ECE上で表示します。
インストール方法は次のとおりです。
操作方法は次のとおりです。
Origin : piece-me.org
File :
Source code :
Original description :
「TGA形式」の画像ファイルを、P/ECE上で表示します。
インストール方法は次のとおりです。
操作方法は次のとおりです。
Origin : piece-me.org
File :
Source code :
Original description :
P/ECE上で、ポリゴンモデルの輪郭描画を行うデモです。
インストール方法は次のとおりです。
操作方法は次のとおりです。
Origin : piece-me.org
File :
Source code :
Original description :
3D Benchもどきバージョンアップしました。変更点は次のとおりです。
Origin : piece-me.org
File :
Source code :
Original description :
P/ECE上で、マンデルブロ集合を描画します。
インストール方法は次のとおりです。
操作方法は次のとおりです。
Origin : piece-me.org
File :
Source code :
Original description :
SWFプレイヤーバージョンアップしました。変更点は次のとおりです。
再生中に、パッドの左右ボタンを押すと、静止テキストの描画方法を、「デバイスフォント」と「埋め込みフォント」に切り替えます。
「デバイスフォント」とは、P/ECE内蔵フォントのことで、これまでの版と同じ描画方法です。
「埋め込みフォント」とは、個々のSWFファイルに格納されている、ベクトルフォントのことです。
埋め込みフォントを使うと、文字を図形として描画するので、再生環境に依存せずに、正確なテキスト表示が可能です。(理想上は…ですが(^^;)
静止テキストの、拡大・縮小・回転アニメーションもできるようになりました。
Origin : piece-me.org
File :
Original description :
P/ECE開発環境付属の「isd.exe」及び「run.bat」には、以下の不具合があります。
P/ECEのプログラムが、pceAppProc()の中で長時間の処理を行い、5秒間ぐらい処理を返さない時に、PC上で「run.bat」を実行すると、P/ECEがハングアップする。
不具合の原因は、「isd.exe」が、P/ECEのプログラムが終了するのをきちんと待たずに、見切り発車でsrfファイルを書き込み、実行開始してしまっていることでした。
具体的には、「\usr\PIECE\tools\isd\isdsub.c」のismWriteSrfFile()の処理が、適切ではありません。
厳密には、「isd.exe」や「run.bat」の不具合ではなく、「pieceif.dll」の不具合なのですが、今回は、「run.bat」を代替する修正プログラムを作ることにしました。
理由は、「pieceif.dll」を差し替えると影響が大きいですし、「pieceif.dll」は32ビット環境と64ビット環境で異なるので、差替えの手間がわずらわしいからです。
「r.exe」の使用方法は、P/ECE開発環境付属の「run.bat」と同じです。
「r.exe」を、実行パスの通ったフォルダに、置いておいてください。
srfファイルが在るフォルダで、「r」を実行すると、srfファイルをP/ECEに転送し実行します。srfファイル名の指定は不要です。
P/ECE開発環境の「run.bat」で転送しようとすると、P/ECEがハングアップしてしまうようなプログラムでも、「r.exe」ならば、ハングアップせずに転送し実行できます。
Origin : piece-me.org
File :
Source code :
List of supported functions :
Original description :
次はアプリケーションプログラムを作るつもりだったのですが、予定を変更して、もう一度計測プログラムをバージョンアップしました。
変更点は次のとおりです。
高速化した結果は、こうなりました。
| 結果[個] | 時間[ms] | |
|---|---|---|
| C(int) | 62 | 21 |
| C(flt) | 62 | 110 |
| C(dbl) | 62 | 441 |
| Lua | 62 | 828 |
| Tcl | 62 | 490970 |
約1.68倍の高速化です。
前回以降、P/ECE用Tclインタプリタを使って、簡単なボードゲームを作りかけていたのですが、実行速度が遅すぎて断念しました。
スクリプトを数行実行するたびに、数秒間止まるぐらい遅いです。
元々このP/ECE用Tclインタプリタは、コードサイズを小さくすることが目標で、速度は度外視だったのですが、それにしても限度があります。
そこで、少しは高速化することにしました。
とはいえ、Tclインタプリタ自体に手を入れると、複雑になったりコードサイズが増えて元の目標から外れるので、別の方法で高速化しました。
主にメモリ管理の高速化で、下記三点の変更を行いました。①②③の順に、高速化の効果が高かったです。
Origin : piece-me.org
File :
Source code :
Lua programming language 5.3.0 :
Original description :
年始頃に、「Lua 5.3.0」がリリースされていました。
Lua 5.3.0の新しい機能の中で、特に注目するのは、整数演算が対応されたことです。
Lua 5.2.xまでのLuaは、標準設定では、数値の内部処理が全て実数演算で処理されていました。
一見遅そうですが、実際には極端に遅い事も無く、良い割り切り方だと思っていました。確かAwkとかもそうですよね。
そんなわけで、実数演算のままでもさほど困らないのですが、Lua 5.3.0では整数演算が対応されました。
整数同士の演算ならば整数で処理するという動作で、普通のプログラム言語に近くなった感じです。
尚、Lua 5.3.0では、整数同士の演算でも、除算(/)だけは常に実数で処理されます。VBAと同じ感じですね。
「Lua 5.2.xとLua 5.3.0とで、同じ式を書いても結果が違う」というような非互換性は、無さそうです。
内部処理が整数か実数かの違いも、あまり気にしなくて良さそうです。(多分です…今後使って検証しようと思います。)
整数同士の演算が整数演算になったということで、高速化が期待できます。
というわけで、また速度計測を行ってみました。
計測条件の詳細は、前回(2012年2月8日)の記事を参照してください。今回は全て、高速RAM使用,48MHz駆動で計測しました。
結果はこうなりました。
| 結果[個] | 時間[ms] | |
|---|---|---|
| C(int) | 168 | 175 |
| C(flt) | 168 | 991 |
| C(dbl) | 168 | 3978 |
| Lua | 168 | 5232 |
まず、前回の結果に較べて、C(int)の結果が少し早くなっていますが、これはLuaとは関係ありません。
前回の計測から二年間の間に、自作の整数除算ルーチンを少し高速化した事が効いたのだと思います。
C(int)は置いといて、Luaの速度も早くなっています。前回の結果に較べて、約23%の高速化です。
しかし、実数演算を整数演算に置き換えたにしては、意外と高速化の効果が小さいです。
効果が小さい理由は、Lua 5.3.0の整数演算が、64ビット整数(long long)だからです。
P/ECEのCPU S1C33209は、32ビットCPUで、64ビット整数演算の命令は持っていません。
64ビット整数演算は、ライブラリ関数を呼び出してソフトウェアで処理する事になり、整数演算とはいえあまり早くありません。
実は今回の計測結果は、64ビット整数演算も高速RAMに配置して実行したのですが、それでも結構足を引っ張っているみたいです。
Lua 5.3.0の標準設定では、実数演算はdouble,整数演算はlong longで処理されます。
コンパイル時に特定のシンボルを定義しておくと、実数演算と整数演算の型を変える事も出来ます。
シンボル「LUA_USE_C89」を定義しておくと、実数演算はdouble,整数演算はintで処理されます。
シンボル「LUA_32BITS」を定義しておくと、実数演算はfloat,整数演算はintで処理されます。
これらの設定でも、速度計測してみました。
結果はこうなりました。
| 結果[個] | 時間[ms] | |
|---|---|---|
| C(int) | 168 | 175 |
| C(flt) | 168 | 991 |
| C(dbl) | 168 | 3978 |
| Lua | 168 | 3253 |
| 結果[個] | 時間[ms] | |
|---|---|---|
| C(int) | 168 | 175 |
| C(flt) | 168 | 991 |
| C(dbl) | 168 | 3978 |
| Lua | 168 | 2990 |
前回の結果に較べて、LUA_USE_C89は52%の高速化、LUA_32BITSは56%の高速化になりました。
ところで、LUA_USE_C89とLUA_32BITSで速度が違うのはなぜでしょうか。
整数演算は、どちらもintで行われるので、違いは無いはずです。
『2～1000の範囲にある素数の数』を求めるスクリプトには、一見、実数演算になる箇所も無さそうです。
しかし良く見ると、剰余演算(%)が有り、この箇所が実数演算で処理されるのだと思います。
LUA_USE_C89ではdouble，LUA_32BITSではfloatで処理され、その違いが速度差になるのだと思いました。
P/ECEとS1C33209のような、組み込み用32ビットマイコンでは、きっと、LUA_32BITSで使うのが適切なのでしょうね。
ゲーム用途ならば、実数演算はfloat,整数演算はintで大丈夫そうです。(floatはちょっと心許ない場合も有りますが…)
でもまずは、Lua 5.3.0の標準設定のまま、実数演算はdouble,整数演算はlong longで使ってみようと思います。
これまでlong longを多用することは無かったので、64ビット整数演算ルーチンの動作検証をする良い機会です。
