C

NC30には、指定したアドレスにオブジェクトを配置するための#pragma ADDRESS指令があります。これは通常、SFRにアクセスするために用いるもので、*(volatile unsigned char*)0x0052 などと書くより便利です。また、1ビットのビットフィールドにアクセスする場合には、bset などのビット命令に展開されるという強みもあります。

今回、まず初めに調査したのは、CとC++に共通した内容として、#pragma ADDRESSで使用したオブジェクトを直接使用した場合は効率のよいコードが生成されるけれども、ポインタや（C++の場合は）参照を使って間接的にアクセスした場合はどうかということです。実際試してみた結果、間接的にアクセスした場合はビット命令は生成されず、通常のオブジェクトと同じように扱われることが分かりました。

次に調査したのは、C++で#pragma ADDRESS指令を使う場合、オブジェクト名の指定はどの程度のことができるのかということです。というのは、Cであればオブジェクト名は単純な識別子で必ず表現できますが、C++の場合は、名前空間やクラス名やテンプレート引数が絡んでくるからです。

今回もR8CおよびM16C用の純正コンパイラNC30付属の標準ライブラリの話題です。今回取り上げるのは setlocal.c です。名前からもわかるように、setlocale関数を定義しています。

このソースコードは、最初は1999年に書かれたもののようです。改訂履歴がありませんので、おそらくはCopyrightの年を変えただけで、実際のコードは何も修正されてこなかったのだろうと思います。普通なら、十数年の実績があるコードといえるわけですが、実際にはベンダも含めてまともに使った、あるいは評価した人は誰もいないのではないかと思います。

この関数の最初の部分は第一引数の正当性を評価していますが、括目してよく見ると、とんでもないバグが見えてきます。

かなり引っ張ってしまいましたが、今回で最終回です。これまでに実装したutoa関数を使ってitoa関数を実装することにしましょう。

今回は、最後に残った方法、すなわち再帰を使ってitoa関数を実装する方法についてです。例によって、「itoa関数を自作する」というタイトルにはなっていますが、まずはutoa関数を作っています。このutoa関数を使ったitoa関数の実装については、次回に書くことを予定しています。

今回は、いったん逆の並びの文字列を作っておき、後からそれを逆に並べ替える方法についてです。前回同様、「itoa関数を自作する」というタイトルにはなっていますが、まずはutoa関数を作っています。

前回に引き続き、itoa関数の自作について書いていきます。今回は、事前に桁数を求めるための計算を行い、その後、実際に各桁の文字（数字）を書き込んで方法についてです。なお、「itoa関数を自作する」というタイトルにはなっていますが、前回書いたように、まずはutoa関数を作っていますので、誤解のないようにお願いします。

itoaという関数は、非標準ゆえにあらゆる処理系で使えるとは限りません。ただ、itoa関数を使わずに、整数値を文字列に変換しようとすると、C90の標準関数の範疇ではsprintf関数を使うしかなく、ローエンドのマイコンなどでは許容できないでしょう。

そこで、itoa関数を自作しようという話になってきます。ベテランのプログラマであれば難なく自作することができると思いますが、必ずしもそんな人ばかりではありませんので、今回あえて取り上げてみることにしました。ちょっと長くなりそうなので、何回かの連載にしたいと考えています。

今回は、ルネサス製のマイコンM16CおよびR8C用のC/C++コンパイラであるNC30で日本語識別子を使う方法について考えてみることにします。以前、GCCで日本語識別子を使うという記事を書きましたが、それと同じ方法がNC30でも使えることが分かってきました。つまり、NC30でも国際文字名を使うことができるのです。

今後、仕事でR8C/Tinyを使う機会が増えてきそうな予感がしているので、改めて開発環境について調査してみました。今回は、ほんの触りだけですが、そのレポートをしてみたいと思います。

先日までGCCで日本語文字列がどうのこうのということを書いていましたが、その過程でMinGWをいろいろ調べることになりました。その際に、MinGWのprintf系関数がずいぶんまともになっていることに気付きました。

MinGWのランタイムライブラリは、C99で追加されたようなものを除けば、msvcrt.dllに依存してます。これはMIcrosoft Visual C++ 6.0のライブラリです。C99に対応していないのはもちろん、long double型がVC++では64ビット、MinGWでは96ビットと異なることが原因で、"%Lf"などのlong double型用の書式が正しく動作しませんでした。