型
前回のTECS CDLの説明で、型について説明していませんでした。ここで説明します。TECSの型はTOPPERS/ASPなどTOPPERS新世代カーネルで共通定義されている型に統一しています。
その中でも以下の型はTECS CDLの組込まれていて、定義しなくても使用することができます。
int8_t int16_t 1nt32_t int64_t int128_t float32_t double64_t bool_t char_t uint8_t uint16_t u1nt32_t uint64_t uint128_t
intptr_t, int_tなどは、サイズがターゲット依存になりますので、使用を推奨しません。しかしながら、現実にはこれらの推奨しない型が用いられる機会は少なくありません。実際のところTOPPERS/ASPではこれらの型が多用されています。
ヘテロな環境でのリモート呼出しではサイズが問題になりますし、仕様を曖昧化する元ですので、なるべく避けるべきです。
バイナリモデル
TECSではソースコードの互換性を重視していますが、リファレンスとしてバイナリモデルを定義します。バイナリモデルは、とりあえず理解していなくてもTECSを使ったアプリケーション開発は可能です。
しかし、組込み開発技術者の諸兄は、Cコンパイラがどのようなコードを生成するか気にされている方も多いと思います。そのような方にとって、ジェネレータによってどのようなコードが生成されるのか、どのようにメモリ上にレイアウトされるのか、オーバーヘッドはどうなのか、透明性はどうなのかというところ気になるはずです。
さて、図1は、呼び口側のセルCBから、受け口側のセルCBに至るデータ構造図です。
あるセルタイプが複数のセルを持ち、それらのセルのある呼び口が異なるセルタイプに結合されているている場合、呼び口を通して呼ばれる関数は、結合先に合わせて呼び分けられる必要があります。このために関数テーブルを介した呼び出しが行われます。
これはC++のvirtual関数の呼出しに類似しています。しかしC++の実装に比べ、多少冗長なところがあるように思われるかもしれません。
ところが、これらはジェネレータの最適化により、不要と判断された場合には、関数テーブルを介して呼出すのではなく直接呼出されますので、オーバーヘッドが低減されます。
C++ではvirtualと指定されれば関数テーブルが生成され、関数テーブルを介した呼出しになりますが、TECSでは組上げ記述まで行いますので、結合状態により不要と判断されれば、関数テーブルを介した呼出しではなく直接結合されます。この場合、関数テーブルも省略されますので、メモリが節約されます。
つまりC++のvirtualの使用はオーバヘッドの増加が暗黙的な了解事項になりますが、TECSでは最適化によりオーバヘッドの増加が最小限に抑えられます。
まとめ
今回は、TECSを使ったコンポーネントの実装、すなわちセルタイプコードの記述について見ていきました。これまでの説明で、TECSを使った開発を行うために必要な、基本的な事項を見てきました。
次回は、TECSのもっとも強力な機能であるプラグインについて説明します。
