CPU - みる会図書館


検索対象: 月刊 C MAGAZINE 1991年6月号
22件見つかりました。

1. 月刊 C MAGAZINE 1991年6月号

0 T 黼Ⅳ AVOCET シリーズはマイコン開発を トータルにサポートするツールです。 AVXC シリーズ 各¥ 198 , 000 AVXC68K30 ( H8 / 500 用・・・¥ 213 , 000 ) ¥ 398 , 000 68000 / 10 / 20 / 30and68881 / 82 をサポートする産化 C コンパイラ。マク ロ・アセンプラ、リンカ、ロケータ、オプジェクト・ライプラリ、逆アセ ンプラ等付。 ROM 化可能。 R O M 化用 C コンパイラ。アセンプラ、リンカ、ライプラリアン、クロス リファレンス、オプジェクトファイルユーティリティ、ライプラリソース コードを標準装備。浮動小数点、 UNIX ライク関数、重要な ANSIC 関数、 アセンプラコード出力などをサホート。 XMAC68K30 各¥ 90 , 000 ( H8 / 500 用・・・¥ 128 , 000 ) Big Bang シミュレータ 68000 / 10 用 \ 120 , 000 68000 / 1 0 / 20 用 \ 130 、 000 ¥ 198 , 000 68000 / 08 / 10 / 20 / 30and68851 / 81 / 82 / 68322 用クロスアセンプラ、完全に Motor 司 a のマクロ装備。逆アセンプラ付き。 AVMAC シリーズ マクロ機能を持つリロケータブルクロスアセンプラ、リンカ、クロスリフ アレンス、ライプラリアン、エラーメッセージ機能付。ターゲット C PU は 以下のごとくラインアップされ、広範囲な開発環境を提供する。英文マニ ュアル及び和文サマリー付き。 シミュレートをしながらのフルスクリーンデバッガ。ジャンフ先、スタッ クエラー、割り込み処理もサホート。ターゲット CPU のフラグ、レジスタ、 スタック、マシンコード、データメモリエリア、インストラクションサイ クルなどの内容がスクリーンにウインドとして表示。ターゲット CPU は以 下のごとくラインナッフ。 AVMAC04 6804Famlly, 68HC04 AVMAC05 AI 16805 , 146805 , 68705 , 1468705 , 68HC05, Hltach16305 AVXC68K30 及び A68K30 用のシンポリック・デバッカ / レジスタ / メモリ / フラグなどの表小、データの変更や逆アセンプル、ディスクへのセープ、 モトローラ S -recod やバイナリファイルをロード。 l-code によりアセンプラソース出力可能。アセンプラソースは、ターゲッ ト CPU の他 8086 ( スモール ) コードをサホート、 AVMAC と組み合わせる ことにより ROM 化 - 可能、以下のターゲット用ラインアップ。 各¥ 158 , 000 AVSIM シリーズ PASCAL クロスコンバイラシリーズ各 \ 89 , 000 SIMULATOR/DEBUGGERS MACRO ASSEMBLERS COMPILERS AVSlM05 6805 : P 2 , P 4 , P 6 日 2 : 日 3 , IJ 2 , P 3 68705 : P 3 , P 5 , 日 3 , 日 5 , U 3 , U 5 146805 : E 2 , E 3 , F 2 , G 2 1468705 : G 2 6809Family, 6821 PIA 6804 PTM 6850 ACIA 6800 / 0102 / 0308 , 6801 / 6803 801U4 / 683U4 , 6301V1 / 6303V1 , 6821 PIA 6850 ACIA 68HC11A8 , 68HC11A0 ( no EPROM), AVSI M 1 1 68HC11A2 with 68MC24P 日 U 68000 : 68000 : 10/20 Big Bang AV M180 HD64180 , HC647180X AVSlM48 AI 16809Fam ⅱ y AVMAC09 6800 , 6801 , 6802 , 6803 , Hitachi6301 AVMAC68 AVSIM09 AVSlM68 AVXC68 6801 / 6803 , Fam ily (not 6800 ) Hltach16301 AVXCII 68HC11FamiIy 68000 / 08 / 1 0 / 20 / 30 , 68881 / 82 AVXC68K MXPAS68K 68000 AVXCZ80 See Z80 below H8/500Family AVXCH8 68HC11 AVMACII 68000 / 08 / 10/20/30, AVA68K 68851 / 81 / 82 / 68332 AVMACZ80 See Z80 below H8/300. H8 / 500 , HMCS-400 AVMACH8 AVMAC48 8021 , 8022 , 8035 , 8039 , 8041 , 8048 , 8049 , 8050 , 8041 A, etc, 8020.8021 , 8022 , 8035 , 8039 , 8040, 8041 , 8041 A, 8042 , 8048 , 8049 , 8050 , 80641 A, 8742 , 8748 , 8749. 80C35 , 80C39 , 80C48 , 80C49 , 8031.8032.8051 , 8752. 80C31. 8751 , 80C5 8085 CPU, with 8155 8355 , PascaI 8031 / 8051 MXPAS51 AVSlM51 AVSIM85 AVMAC51 8051 FamiIy 8080 , 8085 , Z80 (lntel Mnemomes) AVMAC85 8096Farmly AVMAC96 Z8, Supe 「 8, M ℃「 08 , Z86C00/11 Family AVMACZ8 AVMACZ80 Z80, 8080 , 8085 , ( Z ⅱ 09 Mnemonics) Hitachi HD64180(Enhanced Z80) Z 180 AVMAC18 RCA 1803 , 1804 , 1805 , 1806 AVMAC65 6500 , 6502 , 65C02 , 65010 ( 65F11 ) Mitusublshi Serles740 AVA65 65C816 AVMAC321 TMS32010, 320C10 , 320C15. 320E15 TMS32010 , 320C15 AV M321 AVMAC322 TMS32020, 320C25 TMS32020. 320C25 AV3M322 ※上記金額に消費税は含まれておりません。お買い求めの際は上記金額に 3 % がかかります 価格及び仕様は予告なく変わる場合がありますので、あらかじめご f 承ください。こに載っていないソフトも取り扱っておりますのでお間い合せ下さい 本社 : 〒 2 引横浜市中区太田町 4 ー 55 横浜馬車道ビル 容 045 ー 6 引ー 7360 FAX 045 ー 662 ー 0656 AVSlMZ80 Z80 CPU, with CTC ACIA AVXCZ80 Z80 , 64180Fam ⅱ y MXPASZ80 PascaI Z80, HD64180 6502 , 65C02 , w ith VIA ACIA AVSlM65 株式会社ソーテック 工人舎事業部 KOHJINSHA く資料請求番号 169 〉

2. 月刊 C MAGAZINE 1991年6月号

C あ磁 情報の省エ匕は standa 「 d に至る (?) 第の回 耳むずかしなカドジりました standard で versatile なもの たとえば「本」を例にとると , 当然のこと ながら , 本自体 , つまり本の内容は大切て、 すが , 本の入れ物て、ある本棚なんかは , 比 較的どうて、もよいと思うのて、す。 そこて、 , 私は , 本棚といえば , 長年 , カ ラーボックスを使っています。スーノヾーマ ーケットのバーゲンのちらしなんかに と きどき , [ 980 円 ! ] と出てたりするやって、 すが , 普通の置き方をタテ〃と呼ぶなら , あれを、、ヨコ〃に何段か積み重ねると , 結構 堅牢て、すし , 本の収容容量も意外と大きい のて、す。もうちょっと具体的にいうと , つのノヾーティションの , 奧を archive ないし semi-archive, そして手前ないし上部を temporary, という具合に , 常時ノヾラレルに 利用しています。 日用品は , カラーポックスに代表される ような , standard て、 versatile なものが好き て、す , 私は。たとえば , 衣類は , いわゆる 量阪店品の無名のシャッ , パンツ , ジャケ ットなどといったものが , もっとあらゆる 意味て、良質て、着やすく , 10 代から 60 , 70 代 まて、のすべての人を , 性別にかかわりなく , 岩谷宏 かわいく見せるものになってほしい。する と , 男女入り乱れた三世代家族て、すら , 部の日常衣料品に関しては , 完全なコミュ ニズムが実現するわけなのだ ! standard なものに対しては , 人間は気を ほとんど空気のように 使うことが少なく , 接することが可能になります。いわゆる高 度情報化社会において , 人間がより高度な 仕事に取り組んて、いくためには , 低レベル なものはどんどん標準化されて , それに対 して用いる意識の量の「省エネ化」が図られ ることが必要だと思います。 そういう意味て、 , やはり , マイクロプロ セッサ ( マイクロコンヒ。ュータ ) は , 理想を いえば , i80x86CPU て、はなくて , MC680X0 CPU を使っていたいて、すよ。 i80x86CPU は , ューザに要求されるチップ特有の特殊 知識の量が多すぎるんて、すよ , 意味もなく。 もちろん , せつかくのシンプルて、ストレー トて、パワフルな 680X0 の世界を , 奇妙にねじ まげてしまった ( = プログラミングに際して 制約や特殊知識の要請量が多すぎる ) Macintosh 国には , 絶対に移民したくはあり ませんがね ! また , いわゆる GUI ( グラフィカルユーザ インタフェイス ) が , ここて、いっている意味 て、の , ューザインタフェイスの、、標準化〃に なりえるかというと , 私は大いに疑問だと 思っています。このことについては , また 別の機会にお話したいと思います。 なぜ main( ) 関数が 必要なのか 今回の主テーマは , 「 C の標準ライプラリ 関数と文字列操作機能」のつもりなのて、す が , 最初にそれとは別の , 短い話題を片づ けます。 C をいじり始めてまだ 3 日目 ( はちょっとお おげさ ) というような人から , 「 C て、書くプロ グラムには , なぜ , main( ) という名の関数 が必要なのか」と聞かれました。私も , C を 使い始めてまだ 3 日目という段階て、は , この 質間に答えられなかったて、しよう。 昔々 , 今はなき某誌の C 言語入門連載記事 て、は , 筆者が「 main ( ) は , C のプログラムに は必ず必要な , オマジナイみたいなものだ と思ってください」と書いていました ( だい たいこの手の記事には , 似たような説明が 多い ) 。この話題にかぎらず , 入門書や入門 記事の , こういうタイプの書き方ってよく ない と私は思うのて、あります。こんな答 えて、は , 当の物事に対する , 生徒 ( 読者 ) の 理解にぜんぜんつながらないて、すから。 C 言語フォーラム 101

3. 月刊 C MAGAZINE 1991年6月号

X 68 k 活用講座 Fig. 2 一般的なアルゴリズム ( 1 ) Fig. 1 CRT を電子がなぞる様子 ←左右をたどるのが水平周期時間 期ってャッて、す。ことゲームに関していえ ば , このタイミングがすべての動作の基本 周期になります。 Fig. 1 がその様子て、す。 CRTC は , ①を走 査するときに決まったビデオ RAM のアドレ スを生成します。この初期値がスクロール を決定する値て、 , これは CPU が CRTC に設 定します。そこから一定の周期て、ビデオ RAM を読み , それをディスプレイに表示してい きます。 X68000 のアドレスはワード単位て、 増やされます。 1 水平ラインを描くと次のビ デオ RAM アドレスを生成 [ 注 5 〕し・・・・・・ 1 画面表 示します。 ②の位置から①の位置に戻るまて、の時間 は垂直帰線期間と呼ばれます ( この時間がも っとも重要な時間て、 , この処理のて、きいか んて、「クソゲー」になったりします ) 。たとえ ばプラウン管が③の位置を走査していると きに④の位置のデータを書き換えても , そ の結果は次の周期にもちこされて反映され ることになります。実際には水平方向にた どるときにも , 非表示期間があります。最 近て、はとくによくこれを利用するテクニッ クが用いられています。逆もまた真て、 , ④ を走査しているときに③を書き換えて、きれ ば「書き換えが見える」ようなことはなくな ります。 これら垂直同期 , 水平同期のタイミング は決まっていますが , 実際にはディスプレ イの同期がとれる範囲はある程度の幅があ ります。この幅が X68000 の CRTC て、は相当 ↑ 上下をたどる周期が 垂直同期時間 画面に関係のない , 部分の処理を行う あるいは現在表示されていない while ( ! 垂直帰線期間 ) 画面関係の処理を行う / * ひたすら待つ * / 柔軟に作られていて , ゲームによってはこ れらのタイミングを変更しているものも数 多く存在しています。それて、はなぜこれら のタイミングをいじる必要があるのて、しょ うか ? ( ' こからは推測の部分があります ) 先ほども述べましたが , 約 1 / 60 秒ごとに 垂直帰線期間が存在します。この期間は CRTC がビデオ RAM を完全に解放する時間 て、 , スクロールさせたり , ビデオ RAM を書 き換えたり , スプライトを出したり消した りしても , それは人間の目には反映されな い時間て、す。つまりこの時間内て、これらの 処理をすべて終えてしまえば , いかにも CPU が書き換えていることが , 、まったく目に止 まらなくなるわけて、す。 Fig. 2 がそのアルゴ リズムて、す。 かりに画面に関係ない部分の処理が遅れ て次の同期期間まて、待つようになるのが , いわゆる「重くなる」といわれる現象て、す ( 垂 直帰線期間を待たないとどうなるのかは次 にサンプルプログラムて、実証してみましょ う ) 。 垂直帰線期間内に終わらなければならな い処理が次の表示期間にまて、延びると , 「書 き換え」が見えてしまうという悪影響が出ま す。そこて、 , この垂直帰線期間を少し引き 延ばして ( この結果 , 表示されないビデオ RAM 領域が広がる ) 対処していると考えら れます。 実際にはこの垂直帰線期間は , X68000 て、 は MFP と呼ばれる周辺 LSI のポートを監視 することて、検出て、きます。 X68000 はこれを 検出すると今まて、に準備しておいたデータ をひたすら周辺 LSI やビデオ RAM などに書 き込みむことになります。 同様の手法として割り込みを使うことも て、きます。 X68000 て、は垂直帰線期間に CRTC が入ると , CPU に対して割り込みをかける ように設定することがて、きます。これを使 った場合のアルゴリズムが Fig. 3 になりま [ 注 1 ] ゲームジャンルからいえば「アクション」と 「シューティング」は区別される場合が一般 的て、すが , ここて、はいわゆるグラフィック なめらかスクロール , スプライト盛りだく さんのタイプを扱ってみます ( いわゆるアク ションロールプレイングも同じように扱え ます。シューティングと比較すれば処理が やや軽いとは思われますが・・・ [ 注 2 ] C 言語て、高速処理を要求されるタイプのゲー ムを作るのは難しいと思われていますが , 市販のいくっかのゲームは C 言語て、記述され ています。また , 連載て扱うテクニックは ゲームプログラミングて、はかなり常識的な ことになりますが , 意外と具体的なプログ ラム例が少ないようなのて、 , C マガジンては ディスクが添付されているメリットを生か してて、きるだけ実際的なプログラムを例と して掲載してみたいと思います。 [ 注 3 ] ゲーム雑誌ては , この言葉は「禁句」のよう て、す。ただ , X68000 のユーザはごく一般的 にこれを使っています。 [ 注 4 ] 別名「ゲーセン」。下手するとパソコンより 偉い CPU が使われているところてす。 [ 注 5 ] X68000 の水平方向 VRAM アドレス生成は , 水平期間ごとに行われているようてす。 CRTC によっては垂直同期と同時に 1 回だけ 行う可能性があります。 X68k 活用講座 97

4. 月刊 C MAGAZINE 1991年6月号

大喜びではない人も 3 人ぐらいは、いるかもしれませんが。・、 すごい口 OS 工クステンダ登場。 Phar Lap Software, lnc. MS - DOS の 640KByte という狭いメモリの制限を超えて、 4GByte という広大なアドレス 空間を利用者に提供するユーティリティ、それが 386 ー TOOL 日 OX です。 386 ー TOOLBOX は、 32bit プロテクトモードという従来のー DOS が十分に活用して し、なかった 80386 / 486CPLJ の特長を、 MS-DOS から 100 % 活用可能にしました。 386 ー TOOL 日 OX は、 8 ロ 386CPLJ をプロテクトモードに切り替えることによって、従来の MS - DOS 環境のままでユーザプログラムが MS - DOS の 640KByte のメモリ制限を破り、 実装されているメモリを全て連続した記憶域として利用できるようにします。さらに 8 ロ 386CPU 本来の実行速度や 4GByte のアドレス空間を活用して、従来の MS ー DOS プログラムより巨 大なメモリを使用する実行速度の速いプログラムの作成・実行を実現しました。 386 ー TOOL BOX は、 386 ー DOS ー Extende 「 ( DOS 工クステンダ ) のまか、 386 ー ASM ( アンセプラ ) 、 386 ー凵 NK ( リンカ ) 、 386 ー凵 B ( ライプラリアン ) 、 M ー NIBLJG ( テパッガ ) で構成されます。 ・別売りオプション仮想記憶マネージャ 386 ー VMM シンボリックテパッガ 386 ー DEBUG MetaWare lnc. MetaWa 「 e 社の HIGH C386 は、 80386CPU プロテクトモード用最適化コンヾイラです。 HIGH C386 は、 803 日 6CPU のプロテクトモード上で動作する八イレベルの C プログラム を構築するプロフェッショナルソフトウェア技術者のために設計されました。 正確なエラーメッセージと優れた特長を兼ね備えており、また、ソフトウェア開発者は多種多様な トグルスイッチとプラグマを活用して、各々の開発者のニーズに合わせたコンバイラの初期設定 や仕様の変更が可能です。 HIGH C386 は、 386 ー TOOL 日 OX に含まれる 386 ー DOS-Extende 「との組み合 わせにより、 80386CPU プロテクトモードの膨大なアドレス空間と高速な演算処理速度を活 MicroWay lnc. NDP FO 日 T 日 AN386 は、 FO 日 T 日 AN77 仕様に完全準拠した 8 ロ 386CPlJ プロテク トモード専用 FO 日 T 日 AN コンノヾイラです。 最大の特長てある、プロテクトモードの 4GByte のアドレス空間と、最適化による高速コードの 生成により、 VAX8600 / SLJN3 といった汎用コンピュータ / ワークステーションクラスの規模 と速度をもつ、アプリケーションの開発・実行を可能にしました。 特長 ・プロテクトモードのアドレス空間 4GByte を活用可能。 1 MByte を超えるプログラムや配列 の実行・定義ができ、上限はノヾソコン本体に実装されたプロテクトモード用メモリの量にのみ 制限されます。 ・数値演算コプロセッサ日 0387 をサポート。さらに、 80387 の約 3 倍 ( 浮動小数点テスト時 ) の性能をもつ、 Weitekl 167 / 3167 チップ、 Tu 「 bo - 3167 ホードをサポート。 NDP FO 日 T 日 AN386 で作成された計算ルーチンの速度をより向上させることができます。 動作環境 386 ー TOOL 日 OX ・ 386 ー VMM ・ 386 ー DEBIJG MS-DOS NDP FO 日 T 日 AN386 NDP C386 HIGH C386 386 ー TOOLBOX* 386 ー VMM* 386 ー DEBLJG* NDP FO 日 T 日 AN386 NDP C386 HIGH C386 ・印は、 32bit 機のみに対応します。 Ha 「 ddisk COP 「「 対応 対応 対応 必須 必須 対応 PC -9801 / H98 P 「 otectmode Memo 「 Y 1 MBYte 以上 1 MByte 以上 1 MBYte 以上 2MBYte 以上 2MBYte 以上 1 MBYte 以上 PC/AT 互換 FMR 用できるようになります。 べンチマークテスト WHETSTONE( 自社計測 ) 使用機器 . PC ー 98 ロ 1 日 L20MHz 十数値演 emulato 「十 noFPIJ emulato 「十 8 ロ 387 80387 inline code 58 200 1540 算コプロセッサ ( 80387 0 「 Tu 「 bo ー 3167 ) Tu 「 bO -3167 inline code 2380 価格 386 ー TOOLBOX ¥ 148 , 000 ( 単位 : K Whetstone) すべての価格に消費悦は含まれていません。 NDP FO 日 T 日 AN386 ¥ 148 , 000 386 ー VMM 386 ー DEBUG ¥ 86 , ロ OO \ 58. ロ OO NDP C386 HIGH C386 ¥ 148 00 ¥ 148.000 * 印は、使用する機種別 ( NEC ヨ BM 、 FMR ) に、購入していただく必要があります。 テッりソフト & プー辷ユ株式会社 コンビュータ事業部〒 273 千葉県船橋市本町 7-11-5 レランドセンタービル 5F Tel. ( 0474 ) 23 ヨ 322 Fax. ( 0474 ) 23-0202 く資料請求番号 003 〉

5. 月刊 C MAGAZINE 1991年6月号

ne Oint Edition 0 P C プログラム移植の秘訣 MS-DOS から Human68k へ 村田敏幸 異なる OS 間の移植には , 数々の題かプ「に行えるよとはいっても , MS-DOSi$bÆ きまとう言 MS-DOS から X68000 十 H いを日し m 68k への移植は必すしも作業第 、 man68k への C プログラム移植も例外で、が少ないわげでばないよともすれば数多 はなし man68k ば必要以上信 MS 、第あふな修正を加える単調な作業にな 00S に似せて作られており , いくつ力、の三 ~ る今回は MS ー DOS から Hum 台 n681f を塰 : ポイントさえおさえておけば比較的容易をの c プログラム移植問題を考察しよラ いうまて、もなく ,MS-DOS はインテル 8086 用の OS て、あり , Human68k は CPU にモトロ ーラ 68000 をもっ X68000 の専用 OS て、す。両 OS 間て℃プログラムを移植する場合 , CPU アーキテクチャの相違と C 処理系の相違が最 初の関門となります。 int サイズ C の int 型は , そのマシンがもっとも自然に 扱えるサイズのデータを格納てきるだけの 大きさをもちます。通常その大きさはプロ セッサの汎用レジスタのビット長に等しく , 8086 て、は 16 ビット , 68000 て、は 32 ビットて、 す。 int のサイズの違いは , 68000 から 8086 への 移植時には大問題となります。器の大きな ほうから小さなほうへ移すわけて、すから , オーパフローに注意し , 必要に応じて int を を long に書き換えるといった修正を加えな ければなりません。 逆に , 8086 から 68000 への移植時には , int のサイズの違いはさほど大きな障害にはな C PIJ りません。 16 ビット int に収まっていた値は まちがいなく 32 ビット int て、表現て、きます。 少なくともオーパフローの心配は無用て、す。 とはいっても , 世の中には 16 ビット int て、は オーパフローすることを利用したり , int と short の相互代入を繰り返すプログラムだっ てあるかもしれません。またビット操作が 絡むと , データサイズの違いが影響してく ることがあります。 典型的な例として Fig. 1 をあげましよう。 (a) は , 16 ビット int の処理系て、最下位ビット をリセットするときのごくふつうの書き方 て、す ( 変数 intvar は int 型とします ) 。しか し , このプログラムを 32 ビット int の処理系 にそのまま移植すると , 同時に上位 16 ビッ トもクリアされることになります。元の動 作を再現するためには , ビットマスクも 32 ビットにした ( b ) のように修正する必要があ るわけて、す。変数の定義自体を sh 。 rt に変更 するという対応も考えられますが , ほかの 部分とのつじつまが合わなくなる可能性が 高いのてあまり勧められません。また , 最 後の ( c ) は int のサイズによらずに同じ動作を する移植性の高い書き方て、す。 ところて、 , int のサイズが 16 ビットから 32 ビットになると , それだけ多くのメモリが 消費されます。もし , メモリ効率が問題に なるのなら , int を short に書き直すことも考 えてみるべきかもしれません。しかしプロ グラム全体に対して修正すると思わぬとこ ろて、破綻をきたすことがあります。大きめ の配列に絞って手を入れるのがよいて、しよ う。その場合は , 配列の定義部分に加え , 配列をポインタて、操作している部分も同時 に変更する必要があることも忘れずに。な お , 効率の追及は移植作業が一段落し , 動 作の確認がとれてから行うべきなのはいう まて、もありません。 工ノディアンの違い 8086 系の CPU と 68000 系て、は「複数バイト からなる整数データのメモリ上て、のバイト の並び順 ( 工ンディアン ) 」が逆になっていま す。 8086 系て、はアドレスの小さなほうに下 位バイトが格納され , 68000 系て、はアドレス の小さなほうに上位バイトが格納されます。 たとえば , 12345678H という 4 バイトデータ は , 68000 系て、は , アドレス大→ ←アドレス小 12 34 56 78 のような素直な順序て、 , 8086 系て、は , One POint Edition 81

6. 月刊 C MAGAZINE 1991年6月号

アルゴリズム・テータ構造入門 なります。また , UNIX などては , 連続した がリストの終わりに達した時点て、は , ポイ きるメモリ空間のことをいいます。これに 入力 ( シーケンシャルリード ) に対して , 自 ンタ a はリストの中央の要素を指していま 対して , 外部記憶というのは ( 磁気 ) テープ 動的にデータを先読みしてプログラムの入 す。そこて、 , ポインタ a の直後て、リストを二 やフロッヒ。ーディスク , ハードディスクな つに分割します ( 77 行目 ) 。最後に , 分割し どの ( 磁気 ) ディスクのことをいいます。 カ待ち時間を少なくする仕組みになってい データ構造やアルゴリズムを設計する際 ます。 たリストをそれぞれ再帰的に整列して , マ ージを行います ( 80 行目 ) 。 には , 外部記憶の性質のうち , アクセスす プログラムの行数は , 配列版よりもリス るのに時間がかかる , 入出力はバイト単位 ト版のほうが長いのて、すが , 実行時間は , て、はなく数百バイトから数十 K バイトの大き さのプロック単位て、行われるといった点に マージソートは , 外部記憶上のデータを 10000 個の要素を整列するのに , 配列版は 3.1 整列するのにも適しています。マージソー 秒 , リスト版は 2.0 秒て、 , リスト版のほうが 注意しなければなりません。 高速て、す ( PC ー 286V , 10MHz, LSI C ー 86 試 主記憶は , だいたいマイクロ秒のオーダ トを利用して外部整列を行う方法は , バラ の時間て、アクセスて、きます。それに対して , 工ティに富んて、います。その基本的な考え 食版 Ver, 3.11 を使用 ) 。これは配列版て、は 方は次のようなものて、す。 作業用配列への要素のコヒ。ーにかかるオー 外部記憶のアクセスには , 10 ミリ秒単位の バヘッドが効いているためと考えられます。 まずデータを主記憶に入る分量だけ読み 時間が必要て、す。たとえば , 今よく使われ ちなみにクイックソートて、は 1.6 秒て、した。 込みます。読み込んだデータを内部整列し ているハードディスクのアクセス時間は , 先ほど考察したように , マージソートは てから , 外部記憶に書き出します。この前 だいたい 10 ~ 数十ミリ秒くらいて、す。また , CPU が一つの命令を実行するのにかかる時 処理によって , データは , 主記憶に入る大 リストを整列するのに適したアルゴリズム 間はだいたいマイクロ秒単位になります ( 今 きさの ( 整列されている ) 塊に分割されます。 て、す。前回勉強したクイックソートも , リ 次に , マージのアルゴリズムを用いて , あげた数値はかなり大ざっぱなものて、すが , ストを扱えるように書き換えることがて、き れらの塊を一つの整列された列にまとめあ こて、はオーダだけを間題にしています ) 。 ますが , 運が悪いと計算量が O ( n ) になるとい げるわけて、す。 Fig. 1 のマージのアルゴリズ このように , 主記憶と外部記憶て、は , ア う問題があります。配列の場合には , 枢軸 ムて、 , 列 a と列 b を入力ファイル , 列 c を出力 を選択するのに左端 , 中央 , 右端の三つの クセス時間に 3 ~ 4 桁程度の開きがあります。 ファイルと見たてると , そのまま外部記憶 つまり , ひんばんにデータの入出力を行う 要素の中央値を選ぶという手法 (median-of 上のデータのマージのアルゴリズムになり プログラムて、は , CPU 処理にかかる時間と -three 法 ) によって , 実質的に最悪のケース 入出力時間を比べると , 後者のほうが大き ます。 を回避することが可能て、す。 なウェイトを占めることになります。 ( 主記 Fig. 7 をもとに説明しましよう。ここては しかし , リストて、は , 配列のようにラン マージを行うのに合計 4 本のテープを利用す 憶に入らないような ) 大量のデータを外部整 ダムアクセスすることがて、きないのて、 , 枢 るものとします ( もちろんテープの代わり 列するのは , ちょうどこのケースに当たり 軸を選ぶためにリストを 1 回スキャンしなけ に , ディスクて、もかまいません ) 。これらの ます。このようなプログラムて、は , ( 多少 CPU ればなりません。これは計算量のオーダに テープは 2 本が入力用 , 2 本が出力用として の処理時間をかけたとしても ) 入出力の回数 こそ影響しませんが , 定数項部分が大きく 使われます。入力側から出力側へとデータ を減らすことによりスヒ。ードアップにつな なり , 速度が犠牲になってしまいます。し をすべてマージすると , 入力用と出力用の たがって , リストの整列には , クイックソ がります。 テープの役目を入れ換えて , 今まて出力用 ートよりもマージソートのほうが適してい 外部記憶装置には , ディスクのようにラ だったテープから入力用だったテープに向 ンダムアクセスがて、きるものと , テープの るといえます。 かってマージ処理を行うようにします。 ようにシーケンシャルアクセスしかて、きな 話が少々極端かもしれませんが , 内部整 いものの 2 種類があります。テープて、は , 機 列は最大て二つの要素しか整列することが 構上ランダムアクセスは不可能て、す。また , て、きないと仮定しましよう。まず前処理と ディスクはランダムアクセスが可能だとは これまて、に取り上げてきたケースは , い して要素を二つずつ読み込んて内部整列を いっても , あくまて、入出力はプロック単位 ずれもデータを主記憶上て、整列するものて、 行って , テープ 1 と 2 に交互に書き込みます。 て、行われるのて、 , 注意が必要て、す。またデ した。このような整列を内部整列といいま 前処理が終った状態が Fig. 7 ①てす。この図 イスクて、も , シーケンシャルにアクセスす す。これに対して外部記憶上のデータを整 るのほうが , その機構上 , ヘッドの移動待 て、縦棒は連 ( run ) の区切りを示しています。 列することを外部整列といいます。ここて、 ち時間 , ディスクの回転待ち時間が短かく 連とは , 要素が昇順に並んだ部分列のこと 主記憶とはプログラム中て直接アクセスて、 外部整列 性 の 己 立ロ 外 アルゴリズムとデータ構造入門 65

7. 月刊 C MAGAZINE 1991年6月号

す。 ったとしても , もともとの処理がこのディ のプログラムは GCC Ver. 1.39 X6 05 ( ' 91 Fig. 3 て、は割り込みて、データを転送します スプレイの基本周期に間に合ってい要 CPU 年 5 月号付録ディスク収録 ) て、しか動作を確 が遊んて、いる時間が増えるだけて、 , ゲーム のて、 , このデータバッフアを複数用意して 認していません。少なくとも List 3 はこのコ 全体が速くなるわけて、はありません。 割り込み処理内て、どのバッフアを使うかを ンパイラて、ないとコンパイルて、きないのて 判定すれば , メインプログラム内部て、の余 注意してください なめらかスクロール 計な待ち時間が不要になります。最近のゲ グラフィックデータは別の専用 ( ? ) ェデ ームて、は Fig. 3 の方法がポヒ。ュラーになって イタて、作成したものて、す。これらのプログ います。 実際にグラフィック画面を多重スクロー ラムは home ( ) 関数を用いてグラフィック画 このふたつのアルゴリズムは , いわゆる ルさせてみましよう。 List 1 ~ List 3 がその 面をジョイスティックを読み取って多重ス スプライトとグラフィックそのほかを使っ メインルーチンて、す。関数 load and disp クロールさせています。 たゲームの基本的なものて、す。たとえば CPU data ( ) は map. c に定義されています ( 付録デ List 1 はハードウェアの状態をなにも考慮 の基本クロックが変更されて処理が速くな イスクに収録されています ) 。なお , これら しないて、スクロールさせた例て、す。 case 文 多重スクロール例 ( 1 ) 多重スクロール例 ( 2 ) List LiSt 1 : / * スクロールテストプログラム 1 2 : / * 何も考慮しないバージョン 3 : 4 : # i nc 1 ude く i oc s ⅱ b. h > 5 : #include く graph. h> 6 : 7 : extern void load-and-dispdata(void) : 8 : 9 : VO i d ma i n ( ) int port; int x,y; 13 : int xx,yy; i nt W a i t : load-and-dispdata ( ) : XX = YY = port while ( ! (port&0x20)) int JOY; CJOYGET(O)) & 0xff; port 22 : = port & 0xf; JOY switch (jOY) 23 : 24 : case 2 : 27 : break; case 1 : YY ー 32 : break: 33 : case 8 : 34 : XX 十 = 1 : 36 : break; 37 : case 4 : 38 : 39 : X X 40 : default: break: 42 : for ()a i t = 0 ; wa i t く 200 00 : wa i t + + ) 43 : 44 : home (0,x & 0x1ff,y &0x1ff); 45 : home (l,xx & 0x1ff,yy &0x1ff); 46 : screen ( 2 , 0 , 1. の : 48 : 49 : } 1 : / * スクロールテストプログラム 2 2 : / * 垂直帰線を検出 3 : 4 : # i nc I ude く i oc s I i b. h 〉 5 : #include く graph. h> 6 : 7 : extern void load-and-dispdata(void) : 8 : static void *stack; 9 : 10 : void main() int port; 13 : int x,y; 14 : int xx,yy; stack = B_SUPER ( の : load-and-dispdata() : 17 : XX YY = X port while ( ! (port&0x2 の ) 20 : int joy; 22 : port = CJOYGET( の ) & 0xff; 23 : 24 : = port & 0xf: jOY switch (jOY) 26 : case 2 : 27 : 28 : 29 : 30 : break : case 1 : 32 : 33 : YY - 34 : break : case 8 : 37 : XX 十 = 1 : break : case 4 : X X 42 : default: 43 : break : 44 : while ((*mfp) & 0X1 の 45 : home (0,x & 0x1ff,Y &0xlff): 46 : home (l,xx & 0x1ff,YY &0xlff); while (!((*mfp) & 0X1 の ) 49 : screen ( 2.0 , 1. の : B_SUPER (stack) : 52 : } volati le char *const mfp = 0Xe88001 : 98 C MAGAZINE 1991 6

8. 月刊 C MAGAZINE 1991年6月号

、、 far", 、、 huge" というポインタ型修飾子を使 って , たとえば , cha 「 far *p ; のように宣言します。修飾子をつけずに cha 「 * p ; と , ふつうに宣言した場合は , コンパイル 時に指定したメモリモデルによって決まる デフォルトのポインタサイズが適用されま す。メモリモデルというのは , デフォルト のポインタの種類を決めるものだと思って ください さて , 68000 にはセグメントなどという不 自然なものはありません。ポインタに near と far の区別もなければ , メモリモデルも存 在しません。長々と説明してきましたが , 移植時にはセグメントにまつわる部分をす べて無視すればよいのて、す。プログラム中 て、 near, far といった修飾子が使われていた ら , 無条件に削除します。これらは MS ー DOS 上の C 処理系て、は予約語て、あり , 同名の変数 が定義されている心配はありませんから , 工デイタなどて、すべて空文字列に置き換え てしまっても大丈夫て、す。さもなくば , プ ログラムの冒頭に Fig. 4 のような空のマクロ 定義を追加し , プリプロセス時に削除する 方法もあります。ヘッダファイルにまとめ ておき , 移植時に必ず取り込んて、もよいて、 また , セグメントとは関係ありませんが , MS ー DOS 上の C 処理系ては関数の呼び出し 規約を指定する $cdecl", $pascal" といった キーワードも追加されています。移植時に は , これらのキーワードも同様の方法て、削 除 / 無効化しましよう。 アイ、メントの間題 これは 68000 側の制限て、す。 68000 てはコ ード , データ ( バイトサイズを除く ) は基本 的に偶数アドレスに置かなければなりませ ん。奇数アドレスから 16 ビット , 32 ビット 単位てメモリアクセスしようとすると , お Fig. 5 Fig. 6 隙間のある構造体 (a) struct f00 char CI; char C2; char C3; / * 1 バイトの詰め物 * / アライメントの問題 (a) chara [ 10 ] ・ int * p = &a [ 1 ] ・ intval; ne Oint Edition 0 P struct f00 { char C; / * 1 バイトの詰め物 * / charaCIO] ・ a [ 2 ] intval & Ox 幵 ; (intval > > 8 ) & Ox 幵 ; 馴染みのアドレスエラーが発生します。も ちろん , 68000 の C コンパイラはこのあたり の事情を把握していますから ,short や int の 変数が必す偶数アドレスに置かれるよう , 必要に応じてレヾイトの詰め物を入れてワー ド境界に整合します。たとえば , Fig. 5 のよ うな char 型メンバを奇数個もった構造体て、 は , 図に示したような位置に 1 バイトの詰め 物が入ります。 ( a ) はともかく ( b ) の場合も , 構造体を配列にすることを考慮し , 末尾て、 偶数アドレスに整合することに注意してく ださい 86 系 CPU はアラインメントに関しては 68000 よりも制限が緩やかて、 , 偶数境界をま たいて、メモリアクセスしてもエラーになり ません。ただし , CPU はメモリアクセスを 2 回に分けて行うことになるため , 実行速度 は低下します。この効率低下を嫌って 86 系 の C てもデータを偶数アドレスに整合する場 合もあるようて、す。 さて , この両プロセッサの違いが移植に どのように影響するかて、すが , 移植元のプ ログラムが常識的なコーディングになって いれば , ほとんど影響しないといってよい て、しよう。すて、に述べたように いちばん 問題になりそうな構造体に関しては C コンパ イラがきちんとつじつまを合わせてくれま す。ただ , 構造体のメンバがすべて隙間な く並んて、いることを前提にするプログラム て、は問題が発生します。また , 構造体を使 えばすむところを char 配列とインデックス て、操作するプログラムになると , かなりめ んどうなことになります。 Fig. 6 ( a ) はその 後者のケースを単純化した例て、す。 char 配 列の奇数バイト位置に int データを書き込ん て、います。この場合は int のサイズとエンデ ィアンの違いまて、絡むのて、 , Fig. 6 ( b ) のよ うに修正します。 Human68k は , 外見だけて、はなく内部仕 様まて、 MS ー DOS を参考にして作られていま す。しかし , よく似ているからこそ移植時 には細部の相違に注意しなければなりませ ん。 OS One Point Edition 83

9. 月刊 C MAGAZINE 1991年6月号

1 数には , たとえば MS-DOS というシングル らて、す。そのため , C は「汎用マクロアセン じ BASIC の使用経験があるがゆえの C プログ タスクのオペレーティングシステムの上て、 プラだ」と皮肉つほ。く定義されることもあり ラミングのドジ > を犯す可能性のある方々 は実現不可能というタイプのものも多くあ ます。 が , どれくらいらっしやるて、しようか ? ります。つまり実装の可否が , 基本システ ご存じのように , C の予約語 ( キーワード ) しかし , とにもかくにも , 今回はおもな ムに相当左右されます。 の数はごくわずかて、すし , しかもそのほと 話題がそれなんて、す。 また , 外見的には UN Ⅸと同じ仕様 ( 関数 んどが , データ型の定義用 (int, char, 上記の① B と① C , ② B と② C は , それぞれ 名など ) て、実装されているような関数て、も , struct, etc. ) と , 条件分岐や繰り返しなどの メモリ上の動的・静的実態および CPU の動 たとえばある引数の意味や値域などが MS ー フロー制御を記述するためのもの (for, 作として完全に等価て、はありません。 DOS と UNIX て、は全然違うというようなも while, if, etc. ) て、す。 まず , BASIC て、は変数の 1 タイプとしての のもあります。要するに , ソースコードを C 以外て、 , 私がある程度それについて語れ 文字列変数というものがサポートされてい る高級言語は BASIC て、す。 BASIC て、も , 関 ますが , これと同じ変数型は C には存在しま 手直しする必要はなくそのまま UNIX にもっ 数という処理単位を記述することはて、きま せん。上記① C や② C に登場する x や y などは ていける純正互換の関数と , そうはいかな すが , 関数は C におけるほど中心的・支配的 ポインタ変数てす。そしてその値が , なん い関数の , 少なくとも 2 種類に分けて考える な機構て、はありません。逆に BASIC は , らかの文字列の ( 先頭 ) アドレスて、す。 必要があります。 ANSI C 互換 / UNIX 互換 ( ただし少なくと 語本体のプリミテイプ ( 基本機能 ) として , そして C の文字列は , 文字列の終わりを null も 2 タイプ ) と見てくると , その次の層は , 豊富な機能をもっています。 ( 値が 0 の 1 バイト ) て、示すところの , 1 バイト オペレーティングシステム依存の関数群て、 たとえば , 典型的なテキスト表示は , C て、 変数 ( それらの値は原則として文字コード ) す。たとえば「 MS ー DOS 独特」と注記されて は printf ( ) などの関数をコールして行います の配列て、す。 C の場合 , 文字列に関して , 処 いる関数て、す。 が , BASIC には言語本体に PRINT というコ 理系がユーザに図ってくれる便宜は , その さらにその外側が CPU 依存 , そして最も マンドがあります。 最後に自動的に 0 を入れてくれるという点だ 外側が BIOS やいくっかの特殊アドレスなど BASIC は文字列を操作するための機能が けて、す。ューザにとっての便宜というより , に代表される , ハードウェアシステム依存 処理系自身のための便宜といった方が適切 豊富て、す。たとえば , の関数群ということになるて、しよう。 かもしれませんが・・・ 文字列変数 x = 文字列変数 x 以上 , 関数の具体名など挙げずに , 抽象 ・・・① B 十文字列変数 y 逆に , C はよく使うが BASIC のことは知ら 的に書いてきました。拙訳「 Turbo C の技 とか , ないという人が , ① B や② B の文を見ると不 法』 ( 工学社刊 ) の付録の部分て、 , Turbo C 文字列変数 x = 文字列変数 y 安になるて、しようね。 C の頭 , つまり文字列 = Ver. 2.0 の標準ライプラリ関数に関して , ・・・② B 十文字列変数 z 文字コードの配列という頭て、見ると , 配列 上記のような分類を試みています。プログ のような記述がて、きます。① B の文は , 実行 のサイズが気になるからて、す。連結によっ ラムの ( ソースリストのレベルて、の ) 可搬性 後 , x が x と y を連結したものになります。 C て , x はオーパフローしないだろうか・ に関心のある方は , 一度ご覧ください。 て、は = 〃やヾ十クという演算子に , こんな便 「配列は , そのサイズがランタイムに可変 利な機能は提供されていません。そこて、 , て、はない」という点が重要て、す。これは , C C と BASIC との これを標準ライプラリ関数を利用する C の文 て、も BASIC て、も同じて、す ( そして , 繰り返せ 「文字列」の違い として書くと , たとえば , ば , BASIC の文字列変数は、、配列〃て、はな ・・・① C 。配列扱いされない。その点を以下に述 strcat( x, y ) : となるて、しようか。 C の処理系が , オマケ以上のもっと本質的 べます ) 。 ② B を同じように C て、書くなら , な構成部位として , 標準ライプラリ関数と ところが , BASIC という言語は , 文字列 ・・・② C 変数に関して , そういった面倒を自動的に strcat( y, z ) : いう名の数百個もの関数群を提供している X あたりてしよう。 処理してくれるのて、す。つまり BASIC て、は 理由は , よくいわれることてすが , C は言語 今の時代て、 , つまり本誌の読者て、くなま 「文字列変数半文字コードの配列」なのて、す。 本体に高度な機能を何も実装していないか c 言語フォーラム 103

10. 月刊 C MAGAZINE 1991年6月号

連 コンノヾイラは GCC 。楽しく役立つ欲張り企画のスタートで な機能を使いこなす C プログラミングを学ぶ立体講座。使用する 曲宀 のは周知の事実。 X68k をベースにゲームを作りながら , 田 X68k の機能をフルに活用すれば完成度の高いゲームが組める 吉野智興 なめらかスクロ—) レの秘訣 第 1 回 X68k 活用講座 プロクラミング 68 ゲーム GCC で学ぶ ろっぱ ~ ゲーム プログラミング 発売からすて、に 4 年を経過した X68000 て、す が , そのホビー的な面はいささかも衰えて はいません。とくに最近発売されているア クションゲームプログラム [ 注 1 ] は , X68000 の 機能を使い切ったすばらしいものが数多く あります。ゲーム雑誌て、行われているアマ チュアゲームの応募作品においても量・質 の面て、 , 普及台数て、は比較にならない某 DOS 見たゲーム プログラミングから ていきたいと思います [ 注 2 ] 。 ミングにおける基本的なテクニックを扱っ そこて、 , 今回から C て、このゲームプログラ マシンを凌駕しています。 は相当多大な負担になります。リアルタイ このふたつの特長は , プログラムにおいて 処理も行う ・ほとんどの場合 , FM 音源などの並列 ・完全にリアルタイム処理である と以下の特長があります。 プログラムからアクションゲームを見る 1991 6 ム性を損なうと , いわゆる「クソゲー [ 注 3 ] 」扱 96 C MAGAZINE いされるて、しよう。 また , X68000 て、は , ・なめらかなスクロール ・きれいなグラフィック ・多彩なキャラクタ は「当然」のように要求されます。 一昔前て、 は ( 一部のマシンて、は現在もそうて、すが ) な めらかなスクロールを得るために , あらゆ るプログラミングテクニックを駆使して実 現していました。たとえばグラフィックを 構成するマップデータをくふうして , 書き 換えを最小限に抑えれば「書き換えが見える」 ようなスクロールをある程度回避て、きます。 書き換え量自体を少なくするために画面全 体を用いないて、 , その一部分だけを利用す る方法もよく用いられています。スプライ トをもっていないマシンて、は背景とキャラ クタの重ね合わせをうまく実現させていれ ば , それだけて、評価が上がるのがこのゲー ムの世界て、す。 X68000 て、は一昔前ならアミューズメント センター [ 注 4 ] のマシンとして , 十分通用する だけのハードウェア機能を備えています。 独立して上下左右自由にスクロールて、きる グラフィック画面 , 最大 256 個のスプライ ト , 8 チャンネルの FM 音源 , AD-PCM 機能 など。ただ , これらを実際に使いこなすに はそれなりの知識が必要て、す。 そこて、 , C プログラムて、可能な範囲て、 X68000 の機能を改良し , 実際にゲームソフ トを作りながら C プログラミングを学んて、い こうと思います。プログラム自体はべった り機種依存て、すが , 考え方は TOWNS のよ うなホビー向けパソコンにも通用するて、し よう。 いきなりティスプレイ いきなりて、すが , パソコン内部にあるビ デオ RAM からディスプレイに表示されるま て、の話から始めます。ゲームをプログラム する場合にはこの原理を理解しておかない と先に進めませんから。 ゲームの綺麗なグラフィックも , ビデオ RAM にあるただのバイトデータの並びて、し かありません。パソコンて、はこのビデオ RAM のデータを CRTC と呼ばれるハードウェアを 介してディスプレイに表示します。普通の ディスプレイて、は約 1 / 60 秒に 1 画面を表示し ています。つまり , かりに CPU がこれより 速くビデオ RAM を書き換えてもムダになり ます。この周期がいわゆる垂直表示期間周