XC8とMPASMの混在は無理そう・・・
2012-12-08
先の記事の続き・・・今日は何とか「XC8とMPASMの混在」に時間を割いてみましたが、結局上手くいかないようだということが判りました。
そもそも、PIC16系より小さなものは詰め込めるプログラム量も限られており、ライブラリ化なんて考える必要はないとも言えるわけですが、高級言語(C言語も一応、アセンブラに比しては高級言語としておきます)向けに本格的になっているのはPIC18系より上だ・・・ということで、コンパイラが抱えているリンカやライブラリアンの作りも、XC16⇒XC32の順に充実していっています。もっと大規模なプログラム作成には、自前のライブラリは結構重宝ですからね。
その代わり、XC8には「ちゃんとしたMacro Assembler」が入っており、インラインアセンブラに向けての扱い易さなどに工夫があって、結局これを使い倒せば「C言語ライクな楽なプログラミングが可能だよ」ということのようだと、「MAPALB X IDE」のHELPを眺めていて判ってきました。
試行錯誤も自分の判る範囲で工夫して随分やってみましたが上手くいかず・・・流石にちょっと飽きたわ
まぁ、少々残念ですがライブラリにしたかったアセンブラソースを、XC8の「ちゃんとしたMacro Assembler」へ移植しようと思います。差分が沢山あったら、別途まとめようと思います。
そもそも、PIC16系より小さなものは詰め込めるプログラム量も限られており、ライブラリ化なんて考える必要はないとも言えるわけですが、高級言語(C言語も一応、アセンブラに比しては高級言語としておきます)向けに本格的になっているのはPIC18系より上だ・・・ということで、コンパイラが抱えているリンカやライブラリアンの作りも、XC16⇒XC32の順に充実していっています。もっと大規模なプログラム作成には、自前のライブラリは結構重宝ですからね。
その代わり、XC8には「ちゃんとしたMacro Assembler」が入っており、インラインアセンブラに向けての扱い易さなどに工夫があって、結局これを使い倒せば「C言語ライクな楽なプログラミングが可能だよ」ということのようだと、「MAPALB X IDE」のHELPを眺めていて判ってきました。
試行錯誤も自分の判る範囲で工夫して随分やってみましたが上手くいかず・・・流石にちょっと飽きたわ

まぁ、少々残念ですがライブラリにしたかったアセンブラソースを、XC8の「ちゃんとしたMacro Assembler」へ移植しようと思います。差分が沢山あったら、別途まとめようと思います。
XC8とMPASMの混在が微妙・・・
2012-12-08
そろそろ環境を整えてC言語への乗り換えをと考えたものの、やはり高速部分やよく使いそうなルーチン群(例えば、LCD表示や割り込みを使った正確なタイマなど)は、アセンブラによる高速化・コンパクト化も魅力があるため、こうした「混在環境」の構築が可能か確認してみました。
アセンブラルーチン群は、「ライブラリ」という固まりにしてしまい、その時に作るものに合わせて必要なものをチョイスするのがカッコイイわけです(っていうか、常套手段です)が、使用するチップに依存する部分をきちんと排除しないと汎用性がなくなり上手くありませんから、既存の(っていうか、既に作ってしまってある)アセンブラソースをそのまま流用することはできませんが、あまり様変わりさせるのもちょっと面倒・・・。
逆に、テンプレートのようなイメージでプログラムファイルを用意しておき、毎度カスタマイズするというのがPICの場合の常套手段とも言えますから、このライブラリ化については「メリット・デメリット」をよく考える必要があるのですが、何れにせよ「XC8とMPASMの混在」がどんな風に実現できるのか(リンカが上手く動いてくれるのか)を確認することにしました。
◆ ソースの種類ではスイッチできない
C言語ソースはXC8でコンパイル、アセンブラソースはMPASMでアセンブル(※)・・・こうすれば、今まで作ったLCD表示やタイマ制御部分が少しのカスタマイズで「ライブラリ化」できる・・・そう踏んでチャレンジしたのですが、このIDEの場合、あるプロジェクト内のコンパイラ(アセンブラ)の選択が1つしかできません。

プロジェクトのプロパティで選択できるのは、右の方にある「Compiler Toolchain」から1つを選ぶ形になるため、少なくともC言語を使うプロジェクトでは「C言語のコンパイラ」を選択するしかありませんので、アセンブラソースをMPASMで・・・と頑張ってもそれは無理なようです。即ち、MPASMの既存のソースを「そのままの形では活かせない」ということになります。
◆ XC8内蔵の「Macro Assembler」
XC8では、アセンブラとの親和性が高いことを謳い文句の一つにしていますが、これは「MPLAB XC8 Assembly Language」として、XC8の中に「Macro Assembler」が内包される形で準備されているからです。
ところが、このアセンブラの文法やリンクする際の各種の宣言がMPASMとは「似て非なるもの」であり、MPASM用に作ったアセンブラソースをそのままXC8でアセンブルしてもエラーが出てしまいます。特に頻出する数値表現なども少し違っているため、始めはかなり沢山エラーが出ることを覚悟する必要があります。
勿論、これを1つひとつ修正していけばよいのですが、結構手間が掛かるのと幾つかバグ(LIST~NOLISTのネストがおかしい・・・など)を見つけてしまったため、ちょっとゲンナリしています
◆ ライブラリが課題
昨晩は、上記で手こずった挙げ句、結局ライブラリの上手な作りに持っていくところまでには到達しませんでした。これを片付けてしまわないと実際のプログラム作成に入り難いため、今日はこの辺りを片付けようと思いますが、どうもリンクエラーが取れないんで弱っています・・・。
※ プログラムソースを翻訳して機械語に直すことは「コンパイル」と言いますが、アセンブラソースを
翻訳することは特に「アセンブル」と言います。
ツール | Ver | |
環境 | MPLAB X IDE | 1.51 |
C言語 | XC8 | 1.11 |
アセンブラ | MPASM | 5.47 |
アセンブラルーチン群は、「ライブラリ」という固まりにしてしまい、その時に作るものに合わせて必要なものをチョイスするのがカッコイイわけです(っていうか、常套手段です)が、使用するチップに依存する部分をきちんと排除しないと汎用性がなくなり上手くありませんから、既存の(っていうか、既に作ってしまってある)アセンブラソースをそのまま流用することはできませんが、あまり様変わりさせるのもちょっと面倒・・・。
逆に、テンプレートのようなイメージでプログラムファイルを用意しておき、毎度カスタマイズするというのがPICの場合の常套手段とも言えますから、このライブラリ化については「メリット・デメリット」をよく考える必要があるのですが、何れにせよ「XC8とMPASMの混在」がどんな風に実現できるのか(リンカが上手く動いてくれるのか)を確認することにしました。
◆ ソースの種類ではスイッチできない
C言語ソースはXC8でコンパイル、アセンブラソースはMPASMでアセンブル(※)・・・こうすれば、今まで作ったLCD表示やタイマ制御部分が少しのカスタマイズで「ライブラリ化」できる・・・そう踏んでチャレンジしたのですが、このIDEの場合、あるプロジェクト内のコンパイラ(アセンブラ)の選択が1つしかできません。

プロジェクトのプロパティで選択できるのは、右の方にある「Compiler Toolchain」から1つを選ぶ形になるため、少なくともC言語を使うプロジェクトでは「C言語のコンパイラ」を選択するしかありませんので、アセンブラソースをMPASMで・・・と頑張ってもそれは無理なようです。即ち、MPASMの既存のソースを「そのままの形では活かせない」ということになります。
◆ XC8内蔵の「Macro Assembler」
XC8では、アセンブラとの親和性が高いことを謳い文句の一つにしていますが、これは「MPLAB XC8 Assembly Language」として、XC8の中に「Macro Assembler」が内包される形で準備されているからです。
ところが、このアセンブラの文法やリンクする際の各種の宣言がMPASMとは「似て非なるもの」であり、MPASM用に作ったアセンブラソースをそのままXC8でアセンブルしてもエラーが出てしまいます。特に頻出する数値表現なども少し違っているため、始めはかなり沢山エラーが出ることを覚悟する必要があります。
勿論、これを1つひとつ修正していけばよいのですが、結構手間が掛かるのと幾つかバグ(LIST~NOLISTのネストがおかしい・・・など)を見つけてしまったため、ちょっとゲンナリしています

◆ ライブラリが課題
昨晩は、上記で手こずった挙げ句、結局ライブラリの上手な作りに持っていくところまでには到達しませんでした。これを片付けてしまわないと実際のプログラム作成に入り難いため、今日はこの辺りを片付けようと思いますが、どうもリンクエラーが取れないんで弱っています・・・。
※ プログラムソースを翻訳して機械語に直すことは「コンパイル」と言いますが、アセンブラソースを
翻訳することは特に「アセンブル」と言います。