page0101 のバックアップ(No.3)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• page0101 へ行く。
  • 1 (2014-07-23 (水) 18:06:44)
  • 2 (2014-07-23 (水) 18:08:46)
  • 3 (2014-07-24 (木) 06:40:23)

---

フロントエンドコードを見てみよう(2)

• (by K, 2014.07.23)

(0)

• osecpu121dより、osectolsにdumpfrというツールが追加されました。それの紹介みたいなものです。
• ちなみに、ここで示されているバイトコードはosecpu122dのもので、将来のバージョンでは改善されている可能性があります。

(1)

• app0100_.oseを最初の例にしようと思います。
• これはカラーグラデーションのアプリで、昨年のrev1のころはこれが17バイトで書けることですごいと言われましたが、現在のrev2では13バイトになっています。
  • なお、ウィンドウサイズの設定を略した「本気バージョン」もあり、それだとなんと9バイトになっています（app0118）。

• ソースコードは以下の通りです。

  #include "osecpu_ask.h"
  
      Int32s c:R00, x:R01, y:R02;
      api_openWin(256, 256);
  //  c = 0;
      for (x = 0; x != 256; x++) {
          for (y = 0; y != 256; y++) {
              api_drawPoint(MODE_COL24, c, x, y);
              c += 0x100;
          }
      }

  • 少し補足すると、c = 0;がコメントアウトされているのは、OSECPU-VMでは整数レジスタの初期値が0であることが保障されているので、これを省略してバイナリサイズを節約しているのです。
• このアプリのフロントエンドコードをバイナリエディタ等で確認すると次のようになっています。

        +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +a +b +c
  0000: 05 e2 59 09 b0 69 b1 69 b2 45 23 00 9b

  • この通り間違いなく13バイトなのですが、しかしこれでは少し読みにくいです。
• ということで、これを命令ごとに切って表示させてみます。

  prompt>osectols tool:dumpfr in:app0100_.ose
  0000: 05e2            OSECPU-VMアプリの2バイトのシグネチャ
  0004: 5_90_9b_0       api_openWin(256, 256);
  000a: 6_9b_1          for (R01 = 0; R01 != 256; R01++) { ...
  000e: 6_9b_2          for (R02 = 0; R02 != 256; R02++) { ...
  0012: 4_5_2_3         api_drawPoint(MODE_COL24, R00, R01, R02);
  0016: 0_0_9b          R00 += 0x100;

  • 上記のダンプリストと比べると、命令の区切りやパラメータが分かりやすくなっています。
  • 4回ほど出てくる9bが定数の256を意味しています。rev1→rev2では定数256を表現するために必要なバイトコードが1.5バイトから1.0バイトに変更されたので、グラデーションアプリはそれだけで2バイトも改善されました（4バイトの改善のうちの半分はこの効果によるものです）。
  • 命令番号6がfor文を表していることも観察できると思います。

(2)

• app0115_.oseを次の例にしようと思います。これは2014年度のキャンプ生がOSECPU-VMの勉強用に作ったものです。
• バイナリサイズはわずか19バイトですが、とてもきれいな模様が出ます。
  
• ソースコードは以下の通りです。

  #include "osecpu_ask.h"
  
      Int32s x:R01, y:R02, c:R00;
  
      api_openWin(256, 256);
      for (y = 0; y != 256; y++) {
          for (x = 0; x != 256; x++) {
              c = x ^ y;
              c *= 0x10101;
              api_drawPoint(MODE_COL24, c, x, y);
          }
      }

• フロントエンドバイトコードは次のようになります。

  prompt>osectols tool:dumpfr in:app0115_.ose
  0000: 05e2
  0004: 5_90_9b_0       api_openWin(256, 256);
  000a: 6_9b_2          for (R02 = 0; R02 != 256; R02++) { ...
  000e: 6_9b_1          for (R01 = 0; R01 != 256; R01++) { ...
  0012: 4_91_1_0_0      R00 = R01 ^ R02;
  0018: 96_0_7510101    R00 *= 0x10101;
  0022: 4_5_2_3         api_drawPoint(MODE_COL24, R00, R01, R02);

  • ここで演算命令を少し詳しく見てみようと思います。
  • OSECPU-VMでは、R00 = R01 ^ R02;が3バイトで記述できています。これはすごいのでしょうか。すごくないのでしょうか。
  • 同じことをx86でやるとなると、EAX = ECX; EAX ^= EDX;になると思います。これは89_c8 31_d0とかになって、4バイトを要します。
  • 同様にR00 *= 0x10101;についても比較してみます。OSECPU-VMは5バイトです。それに対してx86では69_c0_00010101とかになって、6バイトを要します。

(3)

• app0103_.oseを次の例にしようと思います。毎度おなじみのbballアプリです。
• バイナリサイズはわずか63バイトですが、とてもきれいな模様が出ます。
  

• ちなみにバイナリサイズの比較です。

  「はりぼてOS」      350バイト（改良の余地あり、参考記録）
  第一世代OSASK       186バイト
  TownsOS             185バイト
  MSX-DOS/MSX2        140バイト
  Human68k+IOCS       116バイト
  MS-DOS/NEC PC-9801  114バイト (OSECPU-VM以外での世界最小記録)
  OSECPU-VM (rev1)     71バイト
  OSECPU-VM (rev2)     63バイト

• ソースコードは以下の通りです。

  #include "osecpu_ask.h"
  
  %define	L_POINT		LOCAL(0)
  LOCALLABELS(1);
  
  //  PLIMM(P01, L_POINT);
  
  DAT_SA(L_POINT, T_UINT8, 16 * 2);
      DB(196, 100, 187,  61, 164,  29, 129,   9,  90,   5);
      DB( 53,  17,  23,  44,   7,  81,   7, 119,  23, 156);
      DB( 53, 183,  90, 195, 129, 191, 164, 171, 187, 139);
      DB(196, 100);
  DAT_END();
  
      Int32s col:R00, x0:R01, y0:R02, x1:R03, y1:R04, i:R05, j:R06;
  
      for (i = 0; i != 15; i++) {
          REM34(); LMEM0PP(32, R01, T_UINT8, P01); LMEM0PP(32, R02, T_UINT8, P01); // x0, y0.
          PLIMM(P02, L_POINT);
          for (j = -8; j != 8; j++) {
              col = i - j;
              REM34(); LMEM0PP(32, R03, T_UINT8, P02); LMEM0PP(32, R04, T_UINT8, P02); // x1, y1.
              if (col <= 0) { col = 1 - col; }
              if (col <= 7) {
                  api_drawLine(MODE_OR, col, x0, y0, x1, y1);
              }
          }
      }

• フロントエンドバイトコードは次のようになります。

  prompt>osectols tool:dumpfr in:app0103_.ose
  0000: 05e2
  0004: ae_3_a0_c464bb3da41d81095a053511172c07510777179c35b75ac381bfa4abbb8bc464
  0049: 6_8f_5          for (R05 = 0; R05 != 15; R05++) {
  004d: b4              R01 = *P01++;
  004f: 88_1_0_1        R02 = *P01++;
  0054: 4_3_0_2         P02 = &data[0];
  0058: 4_6_b8_88_6     for (R06 = -8; R06 != 8; R06++) {
  005f: 4_95_5_0_0      R00 = R05 - R06;
  0065: b4              R03 = *P01++;
  0067: 88_1_0_3        R04 = *P01++;
  006c: a5_0_0          if (R00 <= 0) {
  0070: 97_0_1          R00 = 1 - R00;
  0074: 1               }
  0075: a5_0_87         if (R00 <= 7) {
  008a: 4_5_3_4         api_drawLine(MODE_OR, R00, R01, R02, R03, R04);

• aeで始まるデータ記述命令を1命令と数えても、14命令しかありません。
• 命令b4はプリフィクスで、次に出てくる命令を2次元ベクトル化します。

  (例) b4 88_1_0_1 は次のように展開される
    88_1_0_1  R01 = *P01++;
    88_1_0_2  R02 = *P01++;

  • n次元化する命令b5もあります。
  • ソースコード上ではREM34();という記述が命令b4の生成を促しています。

(4)

• （準備中）

こめんと欄

コメント	お名前	NameLink

     

Site admin: K

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.6.40. HTML convert time: 0.022 sec.