Mobileその他」カテゴリーアーカイブ

ARM CPU 上の開発環境とコンパイル時間の比較

最近のハイエンドスマートフォンは 6G ~ 8GB もの RAM を搭載しており PC との差がなくなってきました。termux というアプリを使えば Android 上でも開発環境を整えられるとのことなので、コンパイル時間を比べてみました。

Smartphone SoC RAM thread time1 time2
Galaxy S6 Edge Exynos 7420 3GB 8 77.8 79.8
ZenFone AR Snapdragon 821 8GB 4 118.3 127.7
Nexus 5X Snapdragon 808 2GB 6 195.6 181.0
Nexus 5 Snapdragon 800 2GB 4 244.1 233.0

・2回連続で計測しており単位は秒です。time1, time2 の値が小さい方が高速です。

big.LITTLE で 8 core の Galaxy S6 Edge が際立つ結果となっています。4 core PC で 30秒ほどなので十分なな速度と言えそうです。

今回のビルドは RAM 容量よりも Thread 数が有利に働いたようです。Galaxy S6 はビルドに 8 core 全部使われており、LITTLE core も使って並列度を増やした方が速いことが分かります。下記は Galaxy S6 と ZenFone AR でスレッド数を変えて試した結果です。bit.LITTLE を意識して制限するよりも全 core 使った方が高速でした。

↓Galaxy S6 Edge (4+4 big.LITTLE 8 core)

thread数 time
8 76.3
6 84.8
4 111.7

↓ZenFone AR (2+2 big.LITTLE 4 core)

thread数 time
5 128.9
4 118.3
3 142.0
2 174.0

以下はスマートフォン以外のデバイス含めてテストした結果です。

Smartphone (clang-6.0) SoC RAM CPU core thread time1 time2
Galaxy S6 Edge Exynos 7420 3GB A57 2.1 + A53 1.5 4+4 8 77.8 79.8
ZenFone AR Snapdragon 821 8GB Kyro 2.3 + Kyro 1.6 2+2 4 118.3 127.7
Nexus 5X Snapdragon 808 2GB A57 1.8 + A53 1.4 2+4 6 195.6 181.0
Nexus 5 Snapdragon 800 2GB Krait 400 2.2GHz 4 4 244.1 233.0
Tablet (clang-6.0) SoC RAM CPU core thread time1 time2
Tegra Note 7 Tegra 4 1GB Cortex-A15 1.8GHz 4 4 159.7 145.4
Fire HD 6 MT8135 1GB A15 1.5 + A7 1.2 2+2 4 203.3 202.5
Nexus 7 2013 Snapdragon 8064 2GB Krait 1.5GHz 4 4 262.2 260.5
Nexus 9 Tegra K1 2GB Denver 2.3GHz 2 2 317.7 356.8
Fonepad 7 ME372CL Atom Z2560 1GB Saltwell 1.6GHz 2 4 686.5 682.8
MeMO Pad 7 ME176C Atom Z3745 1GB Silvermont 1.33GHz 4 4 294.5 291.6
TV (clang-6.0) SoC RAM CPU core thread time1 time2
SHIELD TV Tegra X1 3GB A57 2.0GHz + A53 4+4 4 76.0 76.0
Nexus Player Atom Z3560 1GB Silvermont 1.8GHz 4 4 339.8 334.3
Fire TV Stick 2015 Broadcom 28155 0.5GB Cortex-A9 1.0GHz 2 2 596.7 569.2
SmartWatch (clang-6.0) SoC RAM CPU core thread time1 time2
FossilQ Marshal Snapdragon 400 0.5GB Cortex-A7 0.8GHz 4 2 810.5 810.7
SBC (clang-3.5) SoC RAM CPU core thread time1 time2
Dragonbaord 410c Snapdragon 410 1GB Cortex-A53 1.2GHz 4 4 117.3 118.7
Raspberry Pi 3 BCM2837 1GB Cortex-A53 1.2GHz 4 4 175.3 159.8
Raspberry Pi 2 BCM2836 1GB Cortex-A7 0.9GHz 4 4 337.1 301.2
Chromebook (clang-6.0) SoC RAM CPU core thread time1 time2
Chromebook Flip C101PA RK3399 4GB A72 1.8 + A53 2+4 6 106.0 105.1
Chromebook C720 Haswell 4GB Celeron 2955U 1.4GHz 2 2 220.7 219.3
PC (clang-3.8) SoC RAM CPU core thread time1 time2
X370GTN (W10+WSL) Ryzen 7 1800X 32GB Zen 3.7GHz 8 16 25.4 22.2
H97I-PLUS (W10+WSL) Core i7-4770 16GB Haswell 3.4GHz 4 8 28.7 28.2
A88M-ITX (W10+WSL) A10-7870K 8GB Steamroller 3.9GHz 4 4 65.9 61.6
MacBook Pro Core i5-3210M 2GB 8GB Ivy Birdge 2.5GHz 2 4 83.7 90.8
Q1900B-ITX (16.04LTS) Celeron J1900 8GB Silvermont 2.0GHz 4 4 112.2 108.8

・Chromebook は termux ではなく Crouton + Ubuntu を使用しています。

スマートフォンやタブレットは計測時のばらつきが結構あります。2回目以降の方が遅くなるケースも多く、形状が小さいデバイスほど発熱の影響を多く受けているものと思われます。

ARM で一番速かったのは Tegra X1 の SHIELD TV です。こちらは他の ARM デバイスと違い内蔵ファンによる熱対策が行われています。

キーボードがつながらないので実用性はほぼ無いものの Wear OS (Android Wear) の Smartwatch でも動きました。

null

関連エントリ
AMD CPU Ryzen とコンパイル時間の比較 (2)
AMD CPU Ryzen とコンパイル時間の比較
ARM Cortex-A53 の浮動小数点演算速度とコンパイル時間の比較
2955U vs N3150/J1900/Athlon5350 (コンパイル時間の比較)
Raspberry Pi 2 で速くなったコンパイル時間の比較
BayTrail vs Kabini (Celeron J1900 vs Athlon 5350)
コンパイル時間の比較 BayTrail
Atom vs Core i7

ポケコンエミュレータ Pokecom Go と SC61860

Android 用ポケコンエミュレータで LC-3 コンパイラが動いたとの連絡を頂いたので紹介させていただきます。

Pokecom GO

LC-3 について幾つか質問もいただいたのですがだいぶ忘れていました。資料が残っていると思うので発掘できたら紹介させていただきます。

また LC-3 の配布に関しては自由に行っていただいて構いません。ダンプリスト、バイナリ等、任意に掲載していただいて結構です。

SHARP のポケットコンピュータに使われた CPU SC61860 は、小型でポケットに入る電卓サイズの機種に搭載されています。小型&安価な機種ながら、8bit でマシン語が使えることから人気が出ました。それ以前のポケットコンピュータ PC-1211/10 は 4bit CPU が使われており BASIC しか使えませんでした。また最上位機種 PC-1500/1501 はより強力な CPU を搭載しており性能が高かったものの、サイズも大きく高価でした。

PC-1250/51/45/55 当時のポケコン向け BASIC は非常に低速で、アクションゲームのようなリアルタイムな処理はほぼ不可能でした。数値演算はすべて10進数の BCD で行われており、内部表現は単精度で 8byte も消費します。整数型はありませんし CPU Clock も 576KHz です。

画面に任意の dot pattern を表示することができず、表示できるのは ASCII の A~Z 大文字のみ。しかも BASIC 演算実行中は画面の表示が強制的に off になり、画面に文字列を表示できるのは表示命令で実行が止まっているときだけです。

サウンドも予め内蔵されている BEEP 音を一定期間鳴らすことしかできず、音程等はありませんでした。

しかしながら隠し機能だったマシン語を使うことで、これらのこれらの制限がほぼなくなることが判明します。PC-1250/51 向けのマシン語解析記事が当時の雑誌に掲載され、さまざまなゲームも作られるようになります。

マシン語を活用すると動作も高速でリアルタイムなキー入力も可能。常時画面表示を ON にしたまま任意のドットパターンを表示することができました。サイクル計算次第では任意の音程のサウンド再生も可能です。

ただ上記の通り RAM が圧倒的に足りません。RAM は不揮発性でストレージを兼ねていましたが、外部記憶装置はカセットテープなので外部から容易に読み込むこともできません。

そのため当時のマシン語プログラミングは動作効率よりもいかにサイズを減らすかが重要でした。1byte 減らすためには何でもしました。

例えば相対ジャンプは前後 8bit 範囲 (= 9bit 512byte 範囲) にしか飛べないので、リロケータブル前提で大きなプログラムを作る場合は途中に中継地点が必要です。無駄な命令が増えるので、条件付きジャンプだったとしても同じ番地に戻る命令があればそこを再利用します。もちろん飛ぶ前にフラグが誤動作する組み合わせにならないように、前後の命令を入れ替えるなどして調整します。

A:
           ; 目的位置

B:
  102Dnn   ; DP を破壊しても良い前提で中継地点を埋め込む。2Dnn が A: に飛ぶ命令


  41       ; I--
  29nn     ; JRNZ ; 中継地点の B: +1 に飛ぶ。

A:
           ; 目的位置

C:
  2Bnn     ; JRNC ; たまたま同じ A: に飛ぶ別の命令 (条件付き)


  41       ; I--
  29nn     ; JRNZ ; C: に飛ぶ。41 により C=0 が保証されている

これで中継地点が不要となり 3byte 減ります。CMP/INC/DEC 系はフラグを破壊するので、代わりに BIT TEST や 5A/D2 (SHIFT) を使うのもありです。リロケータブル化が不要な場合でも絶対ジャンプと比べると 1byte 削減になります。

CPU の未定義な挙動も使いました。そのため CPU エミュレータを作るには、ドキュメント化されていない CPU の内部挙動まである程度再現する必要があるかもしれません。

有名なところだと特定の命令で Q レジスタに定数(レジスタ番号)が格納されることでしょう。

1302    Q=02

もし A を破壊しても構わなければ INC A を代わりに使うことができます。これで 1byte 減ります。

42      A++   (副作用で Q=02)

35 命令は PC を使ってメモリ内容を読み出すことができます。PC が破壊されると困るので、内部で一時的にスタックに PC を保存しているようです。そのため 35 命令を使うとスタックに PC の痕跡が残ります。

ただし PC の読み出しなら 35 命令を使わなくても、内RAM 内ROM 内の任意の 37 (RTN) を一度呼び出せば良いので、あまり使わなかったように思います。

SC61860 は RAM にアクセスするには必ず特定のレジスタを経由しなければなりませんでした。DP もしくは PC です。

メモリアクセス可能なレジスタ

Register 内ROM 外ROM 外RAM VRAM
DP Y Y Y
PC Y Y Y

内ROM (CPU 内蔵 ROM) はプロテクトがかかっており通常のデータアクセス用 DP では読み出すことができませんでした。ですがプログラムの実行はできるので、PC は当然読み出すことが可能です。35 命令は PC を使うことで、本来読み出せないはずの内 ROM の内容を読み込むことができます。

マシン語モニタを作る場合は DP ではなく常に PC (35命令) を使えばよいかというとそうではなく、今度は VRAM を読むことができません。すべてのメモリにアクセスするには、DP, PC 両方を併用する必要があります。ちなみに PC は VRAM にアクセス出来ないので、VRAM にマシン語コードを書き込んでも実行できませんでした。

byte 削減のために一番活用したのはやはり 内ROM で、少しでも都合が良い命令並びがあれば積極的に 内ROM CALL を多用していました。たった 3byte の命令並びでも、内ROM CALL だと 2byte で済むからです。

関連エントリ
24年ぶりに「おくやくん」が移植されました。ポケコン PC-1245
BASICコンパイラと手書き原稿の時代
28年前のモバイル PC-1211 他
20年前のモバイル PC-1417G

Android LuvPad AD100 を1日持ち歩いた

持ち歩いて使ってみました。
予想に反して自分の中では理想に近い良くできたブラウザ機でした。

マウスコンピュータ LuvPad AD100

 NVIDIA Tegra 250 に Android OS 2.2 (Froyo) を載せた 10インチタブレット。
 Tegra2 は現在主流の ARM Cortex-A8 よりさらに新しい Cortex-A9 (1GHz) を
 2core 搭載した非常に強力な物。GPU はもちろん GeForce の流れをくむ。

●ブラウザ

ポータブルルータは UQ WiMAX URoad-5000 + UD01SS を使用。
現段階でもブラウザ専用と割りきってしまえば十分快適なことが判明。

メモリが多い、画面が大きい、速い

(1) メモリが多い

ウィンドウを多数開いても大丈夫。
iPad だと複数ひらくと切替時にリロードが発生することがあります。
LuvPad はとりあえず限界の 8枚開いても余裕でした。
8枚以上開けないのが惜しいところです。

(2) 画面が大きい

解像度が高いと拡大しなくても文字が読めますが、
画面が大きいと拡大しなくてもリンクをタッチできます。
スマートフォンより Tablet が優れてると思ったのはこの点。

(3) 速い

ブラウザのレスポンスが高速です。
加速センサーのちょっとした揺れに追従して水平に置いたときは激しく向きが
切り替わることがあります。画面の回転に全くもたつきが無いため。

問題点

・なぜかブラウザだけマルチタッチ出来ない

 他のソフトでは 2点まで使えています。
 画面が大きいので拡縮する頻度が少ないのが幸い。

・液晶が見づらい

 視野角が狭く画面を縦にすると見づらい。

・ちょっと重い

 でもプラスチックで若干厚みがあるせいか iPad ほどずっしりした感触はない。

●電源

結構持ちます。
スリープしても左下のバッテリーと Wi-Fi LED が点灯したままなので心配に
なりますが、一晩経っても全く減っていなかったので大丈夫そうです。

スリープからは瞬時に復帰しますが、電源を切ってからの起動も速いです。
実測で 20秒で起動しています。

●まとめ

昨日はじめて触った感想では、操作性やアプリの無さ、安定度などいまいちな
印象でしたがブラウザに関しては気に入りました。

逆に現状まだアプリを入れておらず、ブラウザしか使い道がないとも言えます。
洗練度はまだまだだけど、隠れた潜在能力の一端は見ることが出来ました。

●その他

・RAM 空間は 448MB。残りの 64MB は VRAM?
・カーネルは SMP。本当に CPU はマルチコアらしい。
・Adreno (旧ATI) 系と違って頂点テクスチャなし

NVIDIA Tegra2

pshader constant = 1024
vshader constant = 256
vshader input    = 16
vshader output   = 15
pshader texture  = 16
vshader texture  = 0
max texture size = 2048

Compress Format
83f0   GL_COMPRESSED_RGB_S3TC_DXT1_EXT
83f1   GL_COMPRESSED_RGBA_S3TC_DXT1_EXT
83f2   GL_COMPRESSED_RGBA_S3TC_DXT3_EXT
83f3   GL_COMPRESSED_RGBA_S3TC_DXT5_EXT
8c70   GL_COMPRESSED_LUMINANCE_LATC1_EXT
8c71   GL_COMPRESSED_SIGNED_LUMINANCE_LATC1_EXT
8c72   GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT
8c73   GL_COMPRESSED_SIGNED_LUMINANCE_ALPHA_LATC2_EXT
8d64   GL_ETC1_RGB8_OES

GL_NV_platform_binary 
GL_OES_rgb8_rgba8 
GL_OES_fbo_render_mipmap 
GL_NV_depth_nonlinear 
GL_NV_draw_path
GL_OES_EGL_image
GL_OES_vertex_half_float
GL_NV_framebuffer_vertex_attrib_array
GL_NV_coverage_sample
GL_OES_mapbuffer
GL_ARB_draw_buffers
GL_EXT_Cg_shader
GL_EXT_packed_float
GL_OES_texture_half_float
GL_OES_texture_float
GL_EXT_texture_array
GL_OES_compressed_ETC1_RGB8_texture
GL_EXT_texture_compression_latc
GL_EXT_texture_compression_dxt1
GL_EXT_texture_compression_s3tc
GL_EXT_texture_filter_anisotropic
GL_NV_get_tex_image
GL_NV_read_buffer
GL_NV_shader_framebuffer_fetch
GL_NV_fbo_color_attachments
GL_EXT_bgra
GL_EXT_texture_format_BGRA8888
GL_NV_unpack_subimage 

Tegra2 GPU と Cortex-A9 を試す時間がほしい。

関連エントリ
マウスコンピュータ LuvPad AD100

24年ぶりに「おくやくん」が移植されました。ポケコン PC-1245

●移植された!

「おくやくん」 は SHARP のポケットコンピュータ、PC-1245/50/51/55 で動くゲームです。
工学社の雑誌、PiO 1985年の 11月号に掲載されたので、もう 24年も前になります。
その古いゲームを、なんと 24年の時を経て他の機種に移植してくれた方が現れました。
下記ページで公開されています。

「ポケットコンピューター」について

こちらには新たに移植された PC-1450 版、PC-1260/61/62 版(*1)がありますし、
16ステージ分オンメモリに改良された PC-1251/55 向けも掲載されています。
BASIC による PC-G801/E200 版もあります。

ページに掲載されているプログラムは音声形式 WAVE ファイルで、これをカセット
インターフェースから読み込ませるとポケコン本体に転送できるという仕組みです。

このカセットインターフェース用のセーブ音を聞くだけでもう懐かしくて涙が出そうです。

●電卓みたいなコンピュータ

SHARP のポケコン PC-1245/50/51/55 や PC-1260/61/62 は非常に小さくて薄くて
ただの電卓にしか見えません。

今更こんな写真を見せられても、コンピュータとして使い物になるのかと疑問に思う方が
きっと多いことでしょう。
いや当時もそう思いました。

でもそこが魅力の一つでもあります。
見かけは薄っぺらな関数電卓なのに、BASIC だけでなくマシン語プログラムが走り、
高速なゲームが動いてサウンドの演奏もできます。当時としてはどれも驚くべきもの。
見た目のギャップと実力の差、中に詰まった感じが良かったのです。

●ゲーム内容

横画面のアスレチックぽい仕様となっていますが、実際は迷路ゲームです。
画面が 1行しかないことを逆手に取り、先が読めず決断を迫られることと、若干の
暗記力が必要でした。

一番の特徴はドット単位の上下スクロールです。
VRAM 構造上の制約もあったため、掲載時はまだ珍しかったように思います。
2D 風のフィールドを移動できてマシン語で比較的高速に動作するし、
内容もかなり緩いゲーム性だったこと、コンストラクションモードがあって自由に
面データを作れたのが良かったのかもしれません。

●おくやくん作成の話と機械語プログラミング

このゲームを作った目的はやっぱりスムーズな上下スクロールでした。
ただ最初はそこまで深く考えていなかったため、あまりきれいな作りではありません。
結局はライン単位でパターンを展開しているし、スクロールにキャラが付いてこない
ところも不完全です。
もっときちんと作っておけば良かったと、ここだけがずっと心残りでした。
完全に 2D 空間を滑らかにスクロール出来たのは、その後の別のゲーム
トロピカルアイランドだったように思います。

おくやくん はほぼ全部マシン語で書かれています。
アセンブラもパソコンも無かったので、紙に手でプログラムを書いていました。
ニモニックは使わずに 16進数で命令を並べ、自分で相対ジャンプを数えて、ある程度
出来たらマシン語モニタで直接 RAM に命令を書き込んでいきます。

これだとあとから大きな修正ができないので、プログラミングは完全にボトムアップです。
キー入力ルーチンやサウンド部分から始めて、パターン転送ルーチンなど小さい部品を
作り、テストしながらメモリ上に配置していきます。
ゲームとして全体が繋がるのは最後でした。
RAM が 2~10KByte しかなかったおかげか、こんな方法でも十分だったのです。

記憶メディアはカセットテープしかなかったものの、ポケコンは今で言うスリープ相当。
RAM の内容はバッテリーで保持されています。
ファイルやディスクといった概念もなく、メモリを書き換えたらそれがすべてです。
プログラムもエディットしたステージデータもずっと RAM 上に保存されています。

そのためプログラム実行時は最初に必ず初期化ルーチンが必要で、ワークエリアを
クリアしたり、パラメータの初期値を転送しなければなりません。
いつも最後に作るのがこの部分でした。

その頃には RAM エリアはすでに後ろまでいっぱい使い切っており、たいてい入る場所
が無くなっています。そこで逆にアドレスの前方に伸ばしていきます。ぎりぎりまで
BASIC エリアを浸食するようになるわけです。
プログラムの一番先頭にワーク初期化用のデータテーブルがあったり、プログラムの
スタートアドレスが途中の中途半端な番地になっているのもそのため。

ちなみに 「おくやくん」 というのは当時の友人、奥山君のこと。

●ポケコンユーザー

移植してくれた柳田さんありがとうございました。
今後他の機種へも移植を行っていくとのことです。

今年の 2月にもLC-3 コンパイラが欲しいとの問い合わせもあって、意外にもまだまだ
ポケコンを使ってる方が結構いらっしゃるようです。
このように問い合わせのメールをいただく度にいつも驚いています。
そして謝ります。すみません、コンパイラはまだ用意できてませんでした。

*1: PC-1260 には過去にも移植版があったようです。森岡氏 PC-1260

関連エントリ
BASICコンパイラと手書き原稿の時代
28年前のモバイル PC-1211 他
20年前のモバイル PC-1417G