(toppers-users 472) Re: 16bit integer の場合

[TAKADA Hiroaki]

松川さん wrote:
> (Xstormy16)のintは16bitなのですが、以下の点が
> 気になりましたので、ご報告させていただきます。
> 特に問題がなければ、コメント不要です。

ご報告いただきありがとうございます。今後のリリースで取り込む or 参考に
させていただきたいと思います。

> (その１)
> time_event.hの58行目で、
> #define TMAX_RELTIME ((1u << (sizeof(EVTTIM)*8-1))-1)
> とありますが、intが16bitの場合、コンパイラでの定数式
> 評価でオーバーフローとなります。正しくは、
> #define TMAX_RELTIME ((((EVTTIM)1) << (sizeof(EVTTIM)*8-1))-1)
> とすべきと思われます。(H8S等では大丈夫でしょうか?)

確かにご指摘の通りと思います。次のリリースで修正します。おそらく、エラー
になるかどうかが、コンパイラ依存なのだと思います。

> (その２)
> config.txtで、「intが16bitで64bit整数がサポートされない場合
> _16BIT_INT_を指定」とあります。Xstormy16はint16bitですが
> 64bitも使えるので、_16BIT_INT_を指定していなかったのです
> が、良く見ると、itron.hの78行目で
> #define __int32 int
> となっていました。
> これを
> #define _int32 long
> としていただくと、intが16bitのCPUでも32bitのCPUでも

** Cut quoted 2 lines by the mail filter. **

今の _16BIT_INT_ は、パッチ的な定義でして、あくまでも「intが16bitで
64bit整数がサポートされない場合」に特化したものとお考えください。つま
り、ちゃんと対応しようとすると、「intが16bitで64bit整数がサポートされ
ている場合」が必要になるわけです。

ただ、itron.h ですべてのコンパイラのバリエーションを吸収するのは、読み
やすさを損なうと考えており、コンパイラ (ないしは開発環境) 依存のヘッダ
ファイルを分離する方向で考えています。

ご提案の __int32 を long と定義する方法も考えられますが、long が 32ビッ
トという保証もないので、程度問題である気がしています。

高田広章
豊橋技術科学大学