2024年4月25日木曜日

必要に迫られて自作したアセンブラ等のツールソフトの紹介(第2回)

 必要に迫られて自作したアセンブラ等のツールソフトの紹介(第2回)です


【11月15日追記】クロスアセンブラ(6809用、6800用)の修正版を11月15日のブログ「必要に迫られて自作したツールソフト(クロスアセンブラ)の紹介(第3回)」にアップしましたので、そちらの方を参照ください。また、6801用、6303用も同時に公開しました。


【5月23日追記】コメントでご指摘いただいた点を改善した6809AsmWin.exeと6800AsmWin.exeを公開しました。末尾を参照ください。


【4月30日追記】コメントでご指摘いただいた点を改善中です。かなり大幅に書き換えましたので、他の箇所でバグが発生していないかチェック中です。チェックが済みましたら改めて、6809AsmWin.exeと6800AsmWin.exeを公開する予定です。


2021年9月1日のブログ「必要に迫られて自作したアセンブラ等のツールソフトの紹介」https://www.blogger.com/blog/post/edit/1662007451717538019/137356729684879777

で私が日常使用しているいくつかの自作ソフトを紹介して公開しましたが、その後、必要に応じて修正を重ねてきましたので、ここで改めて最新のバージョンを紹介することにしました。

紹介するものはほぼ前回と同じです。

(1)クロスアセンブラ

 ・6809クロスアセンブラ 6809AsmWin.exe  

 ・6800クロスアセンブラ 6800AsmWin.exe 

クロスアセンブラの主な修正点はFCB疑似命令のオペランド処理の改善です。

「'A',-'B'」や「'A,-'B」のような両書式に対応しました。また、カンマ「,」やスペース「 」もそのまま「','」や「',」の形で使用できます。ただし、文末にカンマやスペースが来る場合は誤変換が生じる場合がありますので、「','」のように閉じの「'」をつける必要があります。


(2)クロス逆アセンブラ

 ・6809クロス逆アセンブラ 6809DasmWin.exe

 ・6800クロス逆アセンブラ 6800DasmWin.exe

逆アセンブラの修正点は、データ部をスキップさせる場合の範囲指定処理の改善です。


(3)転送ツール

 転送ツールとして良く使用するのは仮想ドライブ構築ソフトです。それぞれのDOS(?)に合わせて4種類制作しています。

 ・Flex9用のFlexDrvWin.exe

 ・OS-9用のOS9DrvWin.exe

 ・F-BASIC3.0用のFBasDrvWin.exe

 ・CP/M-80用のCpmDrvWin.exe

主な修正点は、扱えるファイル書式を.D77、.DSKに加えて、各セクタの先頭に16バイトのセクタデータを付加した.DAT形式に対応したことと、パソコンとの通信にRS232Cに加えてFT245高速通信カードに対応したことです。


(4)ツールソフト

 ・CnvTxtTl1Src.exe

  Windows機で作成したTL/1やGAMEのプログラムをTL/1形式やGAME形式に変換するソフト

 ・CvtMotHexBin.exe

  バイナリファイルをBin, Hex, Mot形式に変換するソフト

 ・CvtDskD77.exe

  フロッピィディスクイメージの形式を変換するソフト 


その他として、

(5)FT245高速通信カードを用いたFM-7とWindows機との間の高速通信ソフト

 ・ディスクコピープログラム(F-BASIC3.0用、OS-9用、FLEX用、CP/M用)

 ・ファイルコピープログラム(F-BASIC3.0用、OS-9用、FLEX用、CP/M用)

がありますが、その都度ブログで報告していますのでそれらをご参照ください。


各ソフトを画像で紹介しておきます。

(1)クロスアセンブラ

アセンブルしたいファイルを「ファイル名」ボックスにドラッグ&ドロップして「アセンブル実行」ボタンを押します。


6809AsmWin.exe


6800AsmWin.exe


(2)クロス逆アセンブラ

アセンブルしたいバイナリファイルを「ファイル名」ボックスにドラッグ&ドロップし、「オプション」メニュー中の「オフセット指定」でスタートアドレスを設定してから「逆アセンブル実行」ボタンを押します。

バイナリファイル中にデータ範囲があるようなら、その範囲を推定して「オプション」メニュー中の「スキップ範囲追加」で設定します。


6809DisAsmWin.exe



6800DisAsmWin.exe


(3)仮想ドライブ構築ソフト

 ドライブ0~3にディスクイメージファイルをドラッグ&ドロップすればその内容が左下のボックス中に一覧表示されます。イメージファイル形式ですがD77(D88)形式だけでなくDSK形式(単純にセクタデータを順番に並べたもの)やDAT形式(各セクタの先頭に16バイトのセクタ情報が付いた形式)も読み込めます。
左下のボックスにファイルをドラッグ&ドロップすればイメージファイル中に書き込まれます。ボックス中のファイルをマウスの左ボタンで選択して右ボタンでメニューを表示させることで、「読み出し」、「削除」、「名称変更」ができます。また、イメージファイル中の全ファイルを一気に読みだす場合はメニューの「編集」→「全ファイル読み出し」を用います。



FbasDrvWin.exe

 

Os9DrvWin.exe



CpmDrvWin.exe



FlexDrvWin.exe


FlexDrvWin.exeの例のように、FM-7等との通信を行う場合には、右のボックス中に送受信しているセクタの情報が R/W,Drv,Trk,Sctの順に表示されます。


(4)3種のツールソフト

(4-1)プログラムソースファイルをTL/1やGAME形式に変換します。

CnvTxtTl1Src.exe


(4-2)バイナリファイル変換ソフト
 Bin, Hex, Motファイル間の変換ソフトです。さらにFlex9のバイナリ形式にも変換できます。

CvtMotHexBin.exe


(4-1)ディスクイメージファイル変換ソフト
 普段はディスクイメージファイルの中を見やすいDSKファイルを使うことが多いのですが、XM7やGOTEKのためにはD77形式に変換する必要があります。今まではそれぞれのDOS用に制作したコンソールソフトを使用していたのですが、不便なので全DOSに対応したフォームソフトを制作しました。トラック数が40か80かは自動判別しますのでどちらでも使えます。

CvtDskD77.exe


これらをまとめてOneDriveに上げておきますので、もし使用されてみて動作がおかしいということがありましたらご一報いただけると有難いです。

(前回もこのような文を書いておきましたが、特に連絡をいただけることはありませんでしたので、恐らく使用されてみた方はいらっしゃらないのだとは思いますが、自分自身の試みの記録を兼ねてブログにアップしました。)


【5月23日追記】コメントでご指摘いただいた点を改善した6809AsmWin.exeと6800AsmWin.exeをOneDriveに公開しました。改善点などを記述した文書も添付してあります。


2024年4月20日土曜日

コンパイラ作成の試み その4 言語の拡張(FOR文の完成そして6809用へ)

 マイクロCコンパイラmccにようやくFOR文を拡張することができました。

2023年7月4日のブログ「コンパイラ作成の試み その2 言語の拡張(コメントとFOR文など)」(https://flexonsbd.blogspot.com/2023/07/for.html)の続きです。


ブログ用画像の表示のために置いてあります


その際には、繰り返し変数が初期値の次の値から始まってしまうという不具合があり、スタックを使用している言語のため、初期値、終了条件、増分を順に読んでいくしかないので、それが解消できないようだと書きました。

そのため、このマイクロCコンパイラを6809用に改造しようという意欲が失せてしまい、そのまま放置してあったのですが、GAMEインタプリタ・コンパイラの移植、TL/1コンパイラの移植が完了しましたので、これについても何とかしたいと考えていました。そんな時に手持ちの書籍(末尾の参考文献)を読んでいましたら、FORステートメントの実装の説明として、下図のFOR生成2のようなコード生成方式の方が実装が簡潔化できるとありました。


2つのFOR生成方式

なるほどと思い、この形で実装できないかと試みてみました。具体的には、必要な個所にラベルを設定し、そのラベルへのジャンプ命令を追加することで、処理の順序を変えることができました。

そのプログラムを示します。

    

このようなサンプルプログラムも正常に動作しました。

    


6809用コンパイラへ...とりあえずデータ幅8ビットで...

これで必要な(と思われる)拡張が済みましたので、次はいよいよ6809用コンパイラへの移植ですが、このコンパイラはデータ幅が16ビット、レジスタも16ビットを想定していますので、そのままでは6809への適用はかなり難しそうです。

しかし、TL/1コンパイラのようなデータ幅が8ビットのコンパイラもありますので、まず第一段階としてデータ幅やレジスタが8ビットでも動作しないだろうかと考えました。

それを確認するために、コンパイラが生成した仮想CPU用のアセンブルリストを手作業で6809のアセンブルリストに書き換えて走らせてみました。いくつかの注意点がありましたが、ほぼ機械的に書き換えることができました。使用したのは上記のサンプルプログラムからfor文を取り除いて短くしたものです。コンパイラが生成したアセンブルリスト(.CS)と手動で書き換えた6809用のリスト(.TXT)を示します。

仮想CPU用のアセンブルリストです。

    

手作業で書き換えた6809用アセンブルリストです。仮想レジスタR0、R1には2バイトずつ割り当ててありますが、当然1バイトずつしか使用されていません。
(機械的に置き換えただけで最適化を行っていないために、冗長な部分がかなり多いです。)

    

プログラム中に i * 2 という乗算がありますが、その結果が2バイトを超えていないので正常に動作しました。

このことから、もちろん制約はありますがデータ幅、レジスタ長が8ビットでも動作するようだという見込みが立ちましたので、まず第一段階の目標として、8ビット長の6809用コンパイラを目指すことにします。
時間がかかるとは思いますが、じっくりと取り組んでみたいと思います。


参考文献
・作りながら学ぶコンパイラ/インタプリタ 滝口政光著(CQ出版社)

2024年4月14日日曜日

6800用TL/1コンパイラの6809マイコンへの移植がようやく完了

 

 6800用のTL/1コンパイラの自作6809ボードへの移植がようやく完了しました


時代錯誤ではありますが、折を見ながら昔のマイコン時代に使用していた6800用TL/1言語を6809に移植する試みを続けていまして、今までに1回報告しています。

・2021年5月9日のブログ「6809ボードマイコンにTL/1コンパイラを移植する」
https://flexonsbd.blogspot.com/2021/05/6809tl1.html

その報告ではバグの原因であるインデックス命令をアキュムレータオフセット命令で置き替えることでバグを解消できたと書きました。

その記述がこれです。
===== ここから =====

バグの原因は、STA n,Xというインデックス命令でした。6800ではnは8ビット範囲であるのに対して、6809ではnが0~7Fの範囲では5ビット命令となるのです。TL/1ではSTA n,Xのnを動作中に書き換えるというコードを多用していますが、例えばnを0から1ずつ増やしていくと15までは正値ですが、その次は負値の-16になってしまうのです。

6809ではアキュムレータオフセット命令がありますので、

  6800での命令        →  6809での命令

  (2命令で計5バイト)       (1命令で2バイト)

  STB xxxx  (xxxxはnのアドレス)   STA B,X

  STA n,X

という計5バイトの命令を2バイト命令に置き換えることができ、これでバグを解消できました。

===== ここまで =====

しかしもちろん、上記のようなAccBの値を使うインデックス命令の他にも通常のインデックス命令も多用されており、それらを単純にSTA n,X (A7 n) やLDA n,X (A6 n)などで置き換えてもnの値が15を超えると異常動作をすることになってしまいます。
ということで、これらの命令をA7 88 nやA6 88 nという8ビットオフセット命令に置き換えなければなりません。
ソースを検索すると$A7は直値で書かれている箇所が見つかりますが、$A6は見つかりません。にもかかわらず生成コード中にはA6 nという命令が作られているのです。
この原因を掴むのに数週間を要しましたが(他の方の作られたアセンブラソースはなかなか理解できない...)ようやく、AccAに直値で$86を入れておいてそれに$20を加えて$A6にしている箇所を見つけ、それをA6 88 nに書き換えることでバグを解消することができました。
他にもCMP, ADD, SUBなどのインデックスモード命令も直値として記述されていないので該当箇所を見つけるためにソースプログラムを何度も読むことになりましたが、最後まで見つけにくかったのがインデックスモード命令ではないABA($1B)命令でこれもPSHS B($34 $04); ADDA ,S+($AB $E0)の4バイト命令に書き換える必要がありました。
前回の報告ではASSIST09のステップ動作を利用して不具合の原因を掴むことができましたが、上記のようなバグの原因はこれでは掴めず、コンパイル結果を書き出して逆アセンブルし、そのリストを正常に動作することが分かっている6800用TL/1の結果と比較するという手間のかかる手順を何度も何度も繰り返すことで、何とかバグを解消することができました。

これらによるバグは雑誌に掲載されていたサンプルプログラムの8QUEENやMIYAMAでは現れることはなく、移植が完了したと思い込んで、試しに作成しようとしたメモリダンププログラム(MDUMP)で現れました。MDUMPでは通常の変数の他に複数の配列を使用しましたが、その配列の要素を一つ目の変数の先頭に置かれたポインタ(グローバルポインタGBやローカルポインタLB)からのオフセットで指示しますので、変数や配列の数が多くなって15までのオフセットで収まらなくなってバグが現れたというわけです。


使用した6802/6809デュアルボード
(ブログの画像表示のために入れてあります)


MDUMPも正常に動作しましたし、現在のところ不具合は見つかっていませんので移植は完了したものと考えています。
そもそも移植の目的が6800用TL/1のソースの最小限の変更で6809用のソースを得ることでしたが、単なる6800命令の6809命令への置き換えだけでは済まなかったために、結構変更箇所が多くなってしまいました。最小限の変更ということで高速化や機能拡張などとは全く無縁ですし、また、メモリ配置もほとんど変更していません。
(オリジナルの6800用TL/1のソースも同梱しておきますので、比較していただけると変更箇所が分かります。)

メモリ配置を示します。

メモリ配置図


左図のように、オリジナルの6800用TL/1ではコンパイラ本体を$1000からに置き、ソースプログラムを$3000からに入れてコンパイルし、その結果を$216Bからに生成するようになっていますので、公開する6809TL/1でもほとんど同じ配置にしてありますが、これらはもちろん変更可能で、その場合はソースの先頭のアドレス設定(RUNBEG、SRCB、START)で変更します。変更した例が右図です。なお、いずれの場合もGAMEインタプリタはTL/1の動作には無関係ですので、ソースをGAMEで作成する場合以外は不要です。

私の場合のプログラム作成・コンパイル・実行手順を次に示します。


プログラム作成・コンパイル・実行手順


慣れてしまえばGAMEインタプリタの行編集機能で修正するよりも楽ですし、Windows上にソースが必ず保存されることになるので、TL/1を使用する場合にはGAMEを使うことはありません。

参考までに、私が作成しましたメモリダンププログラム(MDUMP.TL1)を示します。


見ていただくとお分かりのように、複数の配列に加えて手続き(PROCEDURE)や関数(FUNCTION)も使用しており、当然ですが正常に使用できています。

この2か月ほどの間、GAMEインタプリタ・コンパイラの移植とTL/1コンパイラの移植にほとんどかかりきりになってしまいました。他の方から見ると、今時何を無意味なことに時間をかけているのかと不思議に思われることでしょうが、目的は6809用のコンパイラを自作することで、そのための実装に関する知識を得ることでした。今回の経験をぜひコンパイラ作成に生かしたいと考えているのですが。。。

作成したTL/1コンパイラのソースやサンプルプログラム(8QUEEN、MIYAMA、MDUMP)、使用したツール類(CvtTxtTl1Src.exe、CvtMotHexBin.exe)などをOneDriveに上げておきます。なお、私は自作モニタで使用していますが、ASSIST09上で動作させる場合の変更点も記してあります。