5月に公開した、Pure Dataからlogue SDKオシレータユニットを生成するWebアプリをマイナーアップデートしました。Pure Dataからの生成ロジック自体は変更はありませんが、先日公開したツールを統合して、オシレータのバイナリサイズ32KBの制限を超過した場合の詳細情報を出力できるようにしています。
Webアプリへの反映はそのうちやろうと思っていたのですが、その矢先にGitHubのほうでサイズに問題ないように見えるがビルドに失敗したという問い合わせを頂いたので、やっぱり詳細情報があったほうが良さそうだ・・・ということで、この週末に対応しました。
なお、このmapファイルの情報を改めて見てみるとlibm.aからのリンクが予想以上に多いと感じます。理由は２つありそうです。
１つ目は、hvccのコードの実装にあります。Pure Dataの算術演算のオブジェクトは、hvccではすべての演算が１つのクラスで実装されています。そのため、算術演算オブジェクトが１つでも使われていれば、hvcc変換後は（Pure Dataで用いられている）すべての算術演算関数がリンクされてしまいます。
もう１つは、想定外の関数がリンクされていることです。今回のPureData⇒logue SDK変換のコードの中では、logue SDKで近似計算が定義されている算術演算はできるだけそれを使用するようにしています。ところが、それにも関わらずlibm.aのほうの関数もリンクされてしまうケースがあります。
例えば、logf()はlogue SDKで近似値の計算fastlogf()が定義されていますので、これを使用するようにhvcc側の定義hv_logf()を書き換えています。従って生成されたコードはlogf()を一切コールしないはずなのですが、それでもlogf()がリンクされてしまいます。おそらく、これはlibm.aの中のlogf()以外の関数が、内部的にlogf()をコールしているためではないかと思います。
やはり、32KBの制限はちょっときついなとは感じますが、NTS-1 mkIIではこの制限は48KBに緩和されますので、だいぶ余裕が出るはずです。
コメント