以下のコードは、「format.hpp」にある、二進表記関数だ。
しかし、致命的なバグがある・・

void out_bin_(int32_t v) {
    char* p = &buff_[sizeof(buff_) - 1];
    *p = 0;
    uint8_t n = 0;
    do {
        --p;
        *p = (v & 1) + '0';
        v >>= 1;
        ++n;
    } while(v != 0) ;
    out_str_(p, 0, n);
}

バグの存在に気がついただろうか？

引数「v」が「負」の場合、「ｖ」の右シフトは、符号が消えない為、「０」判定が正常
に機能しない為無限ループとなり、配列を超えて不正なアクセスが起こる。
※通常、プログラムはクラッシュするだろう・・

void out_bin_(uint32_t v) {

それで、上記のように、関数の引数を「int32_t」から「uint32_t」にすれば解決する。

「format.hpp」は、以前に、かなり広範囲にチェックしていたが、テストケースが抜けて
いた。
十分チェックしたつもりで、頑丈だと思っていたので、こんな危険なバグがあった事はショ
ックだが、仕方ない、よりよいテストを行う事と、危険な橋を避ける必要があるようだ。

format による二進表現は現在まであまり使わなかったので、この大きなバグによる弊害は
無かったが、危ない瞬間だった・・

ＥＳＰ３２やＡｒｄｕｉｎｏ系で走る「レイ・トレーシング」プログラムがある。

これを、ＲＸ６５Ｎで、どのくらいのパフォーマンスなのか知りたくて、ポートしてみた。

元プログラムはＣ＋＋で書かれたもので、良くできている。
※ソースコードは、ココから拝借したが、多少修正してある。
※ポーティングは極めて簡単だった。
ＲＸマイコンは、浮動小数点の演算には定評があるので、少し期待していた。
結果は７．７秒と、まずまずの値ではある。
※元ソースを大きく修正するとベンチマークにならないものの、いくつかの修正を行った。
追記（２０１８年１１月１６日）：
・浮動小数点関係の関数をRXマイコンの専用命令で置き換えた（FSQRTにより、約１／２の改善）
・実数の定義を明示的に「ｆｌｏａｔ」に修正（改善は少ない）
・オリジナルでは、進捗割合（％表示）と、実時間表示があるので、それに対応
・時間計測用に1/1000（1ms）のタイマーを追加
・RX65Nのキャッシュを有効にした（約１０％の改善）
以上の改修で、「３．１秒」まで改善した。
※一番利いているのは、平方根命令の変更
※ピクセルを描画しない場合、「２．１秒」となる。（これはあまり意味が無い）
※速度比較の為、解像度３２０×２４０でレンダリングしている。

追記（２０１８年１１月１８日）：
・比較していたサイトのベンチマークと、条件が異なっているとの指摘から、やり直した。
※大本のソースでは「raysPerPixel = 4」だったので、その条件で行っていたが、実際のスケッチでは、「raysPerPixel = １」で行っており、１／４のレンダリング時間になるようだ。
・その結果、「８３７ｍｓ」（０．８秒）と、かなり高速にレンダリングする事が判った。
この値は、200MHz動作のARM（STM32F7）の０．６２秒より遅いものの、動作周波数が１２０ＭＨｚのＲＸ６５Ｎなので、十分良い値のように思う。
謝辞：
この問題を指摘してくれ、ＦＳＱＲＴのマクロを提供してくれた「fujita nozomu 」さんに感謝したい、ありがとうございます。

コンパイラのバージョン：

rx-elf-gcc (GCC) 6.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

最適化は「O3」

-------

Raytracing with ESP32
上記リンクには、各マイコンのレンダリングにかかる時間が載っている。
ＥＳＰ３２（１６０ＭＨｚ）は、１３秒みたいなので、それより低速（１２０ＭＨｚ）のＲＸマイコン
はそれなりに優秀なのだと思う。
ただ、「STM32F7 (200MHz) 0.62 秒」に比べると、かなり見劣りする結果かもしれない・・
※クロックを差し引いても、かなり遅い・・・

全ソースは、GitHub にある。

-------
macsbug, cbm80amiga さんありがとう～

追記：
gcc の最適化によってどのくらい違うのかを確認しておいた。
・古い gcc-4.9.4 も確認したかったが、constexpr 関係がコンパイルできずにエラーとなったので、
コンパイラは gcc-6.4.0 のままだ。
・ベンチマークは「目安だ」プログラムの性質により大きく異なる場合が多いし、ほんの少し条件が変
わるだけで、結果が逆転する場合もある。
・ルネサス純正Ｃコンパイラでも評価したいところだが、環境を揃える事が難しいので、実験をしてい
ないが、ネットの情報を見ると、浮動小数点が多い場合は、gcc の方が優秀な場合があるようだ・・
※コメント欄のリンクを参照

・O2、O3 でほとんど差が出ないが、バイナリーサイズは多少異なっている。

追記：（２０１８年、１１月３日）
RX65のハードウェアーマニュアルを眺めていたら、ＲＸ６５にはＲＯＭキャッシュ制御ビットがあり、通常「Disable」になっている事が判った。
※「フラッシュメモリ」、「59.3.2 ROM キャッシュ許可レジスタ（ ROMCE ）」
このビットを有効にして、レンダリングをしてみた、そうすると「６．８秒」と１０％くらい速度改善している。
一応、標準で「有効」にするように設定したが、「キャッシュ」有効により、正常動作しない「実装」もあるかもしれないので、少し評価を徹底したい・・
※「volatile」キーワードが適切にあれば問題無いと思う。
※他のプロジェクト（ファミコンエミュレーター、音楽再生など）も確認したが問題ない。