２０１８．７．１２
前へ
次へ
ホームページトップへ戻る


１６ビットマイコンボードの製作
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
いつか使ってみるつもりで入手してそのまま置いてあった１６ビットＣＰＵのことを思い出しました。
ＡＭＤ社のＡＭ１８８です。
その名の通り、ＣＰＵコアは８０１８８互換の１６ビットＣＰＵです。
そのＡＭ１８８を使った１６ビットマイコンボードの製作記事です。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

［第５４回］



●ＡＭ１８８ＥＭのＣＬＯＣＫ（４）

前回からの続きです。
カメレオンロジアナは「ＴＴＬでＣＰＵをつくろう」［第３７４回］で紹介いたしました。
なかなかに便利な優れものです。
右下に見えるのがカメレオンロジアナです。


前回までのテストで、どうもＡＭ１８８の命令とクロックの間になにやら不適切な関係がありそうな疑いが濃厚になってきました。
そこでカメレオンロジアナでチェックし易いように、うんとシンプルなプログラムを実行させてみることにしました。
下がそのリストです。

2018/7/11  7:226  86cktst8.LST
[00001]                     ;;; clock test for am188
[00002]                     ;
[00003]                         ORG=8000
[00004]                     ;
[00005] 8000  FEC0          LOOP:INC AL;3
[00006] 8002  EBFC90            JMP LOOP;14 <8000>
[00007]                     ;
[00008]                     ;END
LOOP         =8000

もうこれ以上簡単なプログラムは無い、というくらいシンプルなプログラムです。
なおＪＭＰ　ＬＯＯＰのマシン語コードは
ＥＢＦＣ９０
になっていますが、これは自作８０８６アセンブラの手抜きで、
ＪＭＰ　ＬＯＯＰのマシン語コードは
ＥＢＦＣ
です。
そのうしろの９０はＮＯＰです。
アセンブラの都合でこういうマシン語になりますが、実用上問題はありません。
このプログラムを実行して、それをカメレオンロジアナで観測しました。



画面では一部が隠れていますがＰＲＯＢＥ００〜０７がデータバスＤ０〜Ｄ７、ＰＲＯＢＥ０８〜１５がアドレスバスＡ０〜Ａ７です。
ＰＲＯＢＥ１６がＣＬＫＯＵＴＡ（１０ＭＨｚクロック）、ＰＲＯＢＥ１７はＲＡＭＲＤです。
ちょうど６００ｎｓの近辺でアドレス８０００の読み込みが行なわれています。
そのあと８００ｎｓ（８００１）、１０００ｎｓ（８００２）、１２００ｎｓ（８００３）、１４００ｎｓ（８００４）とＲＡＭからの読み込みが行なわれ、少し間が空いて１７００ｎｓ近辺で再び８０００の読み込みに戻っています。
一巡するのに１１００ｎｓかかっています。

ところでこのループは上のリストに記載したクロック数で計算すると１７クロックですから、１７×０．０５＝０．８５μｓ（８５０ｎｓ）のはずです。
おかしいじゃありませんか。
２５０ｎｓもオーバーしています。
どこかがおかしい？
？？？？？
！
あっ！
そういうことか！
なんてこったい。
この何日間もの間、貴重な時間を費やして、それがこんなことだったとは。

ううむ。
なんと愚かなことを。
もっと早く気が付くべきでありました。
やっぱりＺ８０や８０８０の頭でつい考えてしまっていました。
８０８６は１６ビットである以上に、８０８０やＺ８０とはそのアーキテクチャが全く異なっていたのでした。

Ｚ８０や８０８０は命令をメモリから読み込んでそれを解読し実行し、そしてまた次の命令をメモリから読み込んで、という流れで処理を進めます。
当然命令にかかる実行時間はメモリから読み込む時間とそれを解読して実行する時間の合計です。
ところが８０８６は（当然ＡＭ１８８も）そこのところが全く異なっていたのでした。
８０８６は命令をメモリから読み込む部分と、命令を解読して実行する部分を分離して独立させました。
メモリから読み込む機構は、命令の実行とは関係なく（実際は無関係にはできないのですが）メモリから命令をアドレス順に読み込んでバッファに蓄えていきます。
それを実行する機構はバッファから順次命令を読み出して解読し実行していきます。
ＡＭ１８８のデータシートにあった命令の実行クロック数は、この内部的に解読し実行するのにかかるクロック数で、それと「無関係に」並行して行なわれるメモリからの読み込み時間は、命令の実行クロック数には含まれていなかったのでした。

それで疑問が解けました。
ＡＭ１８８がメモリからコードを読み取るのには４クロックかかります。
前回のメモリＲＥＡＤのＷａｖｅｆｏｒｍを参照してください。
ところが上のリストにありますようにＩＮＣ　ＡＬのクロック数は３クロックです。
メモリから１バイトを読むのに４クロックかかるのに、実行時間が３クロックというのはおかしいじゃありませんか。
それはメモリから読み込むのにかかる時間を除外した内部だけの実行クロック数だったのでした。
そういうことだったのです。

仮にスタートした直後でバッファには何もまだ読み込まれていないとすると、ＣＰＵは結局バッファに命令が読み込まれるまで待っているしかありません。
そして４クロック後にやっとＩＮＣ　ＡＬが読み込まれて、それをＣＰＵが３クロックで実行してしまったとしても、またバッファは空ですから、やっぱりもう１クロックは待つしかありません。
そこに計算よりも余計にかかるクロック数の存在が認められます。

そしてＪＭＰ命令とかＣＡＬＬ命令にはもうひとつ困難な問題があります。
それが上のロジアナのチャートに表われています。
８ビットの概念でメモリから読み込まれるときのアドレスを追跡すると、下のようになります。
８０００→８００１→８００２→８００３→８０００
ところが上のロジアナのチャートでは
８０００→８００１→８００２→８００３→８００４→８０００
のようになっていました。
ＡＭ１８８ＣＰＵの内部の実行の様子は見ることはできません。
ロジアナのチャートからわかるのは、メモリから読み込む機構の読み込み動作だけです。
アドレス８００４は本来は読み込む必要はないものなのですが、メモリからの読み込みは命令の解読実行とは一応無関係に行なわれるので、読み込まれてしまいます。
その直後にＪＭＰ命令が解読実行され、そこで８０００番地の命令を読め、というコマンドが内部的に出されて、すると読み込まれていたバッファの内容はそこで破棄されて、新たに８０００から読み直すという動作が行なわれます。
おそらくこの間のロスタイムが上の計算で出てきた、余分にかかった２５０ｎｓ（５クロック）だったと考えられます。
このような流れの変更によるバッファのクリアおよび別のアドレスからの再読み込みはＪＭＰ命令だけではなくて、ＪＮＺなどの条件ジャンプ命令やＣＡＬ、ＲＥＴでも発生するはずです。
また流れは変わりませんが、メモリへのデータの書き出しや、ＩＮ、ＯＵＴ命令の実行の間、メモリからの連続読み込みは一時中断されます。

ここまで書いてきて、突然ですが、もうひとつ疑問に思ってきたことの意味がわかりました。
データシートに記載されている命令の実行クロックが８０８６と８０８８で同じになっている命令が多くあるのはなぜか、という疑問です。
８０８６のデータバス幅は１６ビットですからメモリから一度に２バイトを読み込みます。
８０８８のデータバス幅は８ビットですから一度に１バイトしか読めません。
それならその分だけ８０８８は８０８６よりも実行クロック数が余計にかかるはずではないか？
という疑問だったのですが、おそらく８０８６と８０８８のＣＰＵコアは同じはずで、だから内部の命令解読実行クロック数は８０８６と８０８８で同じであっても何の不思議もなかったのでした。
当然メモリから命令データを読み込むのにかかる時間は、８０８８は８０８６の倍を要します。
命令の実行クロック数に関係なく８０８８は８０８６よりも実行時間は遅くなるはずです。

さてそういうことになると。
そもそもことの発端でありました、ＤＳ１３０７との通信のために必要な５μｓのウェイトタイマーは作れないじゃないか、というお話になります。
その通りです。
８０８０やＺ８０ならばクリスタル発振の精度に合う程度の正確さでソフトウェアによる遅延タイマーを実現することができます。
しかし８０８６では、今まで説明してきました理由から、おそらくそのような正確なソフトウェアタイマーを作ることはできません。
５μｓが７μｓになってしまう程度のアバウトさは認容するしかありませんでしょう。

１６ビットＣＰＵがそんないい加減なことでよいのか？
然り。
そこは８ビットの頭を１６ビット対応に切り換えるべきでありましょう。
おそらく１６ビットの世界では正確なタイマーは外部ペリフェラルに求めるべき、というのが常識なのではありますまいか。

１６ビットマイコンボードの製作［第５４回］
２０１８．７．１２ｕｐｌｏａｄ

前へ
次へ
ホームページトップへ戻る