SSブログ

連載Macの開発環境(月刊ASCII 1987年2月号10) [月刊アスキー廃棄(スクラップ)]

「Macintoshの開発環境はどうなっている?」という連載記事。以前私の記憶でこのブログに書いた「Macの開発者が勘違いしてソフトウエアで実現した」と「Macでプログラムを作ると68000なのに32Kbytesのセグメントがある」の裏付けとなる記事にあったのでスクラップする。
ASCII1987(02)d01Mac開発環境_W520.jpg

ASCII1987(02)d02Mac開発環境_W520.jpg
これがソフトウエアで機能を実現したの記事
天才のとんでもない錯覚
から生まれた?
QuickDraw

 Apple社のプログラマ,Bill Atkinsonが作ったビットマップ処理ルーチン,QuickDrawは,Toolboxの中で最大の特徴になっているパートである.Xerox社のPARCで,AltoやDoradoなどのスーパー・ビットマップ・マシンを見た彼は、すべてのビットマップ処理(ビットブリット)をソフトで行っていると錯覚し,同じことをMacでも実現しようとした.その成果がQuickDrawというわけである.実際には,たいていのビットマップ・マシンは,高速のビットマップ処理を行うためにビット単位のデータ転送,and処理,or処理などを行うハードウェア回路を内蔵している.
 彼はとんでもない思い込みをしたわけだ.天才の錯覚が,時としてすばらしい物を生み出すという証拠として,QuickDrawはMacの中で燦然と輝いているといえる。
 彼の努力の結果,Macは,68000CPUだけですべての画面処理を行うという負担を背負うことになったともいえる(なにしろ68881コ・プロセッサさえ使わないのだ).しかし見方によっては,QuickDrawがすべての画面処理をユーザーに代わって行うために、ユーザーはMacのVRAMの存在を直接意識する必要がなくなっているというメリットもある(この部分は次回以降で解説する).
 QuickDrawの機能は,点/線/四角/多角形/円などの図形描画にとどまらず,ビットマップの転送/スクロールや描画指令のマクロ処理,リージョンと呼ばれる不定形領域の保存・再生など,ここに書ききれないほど豊富である(図3).また,FontManagerと連動して,字種(HelveticaやNewYorkなど),文字サイズ(4~127ポイント),文字スタイル(Bold,下線付き,斜体,アウトラインなど)の変更といった柔軟な文字表示も可能にしている.
Macには天才がいたが、PC/AT にはいなかった。だからPC/ATにはグラフィックスコントローラーが登場してからそれを利用するプログラムが生まれるといった具合で見栄えの点でPC/ATは遅れていた。34年前ショップでMacのソフトウエアを見てそして触っていたく感動した。私は金が無かったし、英語力(ショップの店員さんにMacは英語が読めなければ辛いですねと言われた)も無かったのでMacは買えなかった。私はアセンブラで80286のコードををゴリゴリ書いて無駄なプログラムを書く、無駄な時間を使った残念なパソコン人生であった。
ASCII1987(02)d02Mac開発環境QuickDraw_図3_W520.jpg


ASCII1987(02)d04Mac開発環境セグメント_W520.jpg
これが32Kbyteのセグメントの解説
68000CPUで
セグメント管理

 前項のOSにSegment Loaderがあるのを,“68000CPUなのに,なぜセグメントローダーが……"と思った方も多いだろう.アドレスが24(32)bitリニアの68000には,たしかにアドレス管理上の制限はなく,オブジェクトコード,データともに64Kbytesなどといった制限はない.しかし,68000のブランチ命令とオフセット付きアドレスレジスタ間接アドレッシングは,両方とも符号付きの16bitという制限が付く(-32768から+32767).通常,リロケータが働くシステムや,動かすごとにいちいちリロケートするものでなければ,32Kbytes以上のオブジェクトコードはリロケータブルにならない.68000といえども,オブジェクトコードをリロケータブルに保つには,32Kbytes以内という制限があるわけだ.
 このためApple社は,Macのオブジェクトコードを,1コードセグメント=32Kbytesにして,複数のコードセグメントによって構成することにした.そして,これを管理する手法として,各コードセグメントの配置アドレスを管理するジャンプテーブルとセグメントローダを導入した.各コードセグメントは,直接アドレスによっては参照されず,ジャンプテーブルのエントリアドレスを呼ぶ形式になっている.未使用のコードセグメントは,ディスクからメモリにロードされていてもいなくても,初めて参照された時点でロードされ,ロードされたアドレスがジャンプテーブルに登録される.このため,コードセグメントがセグメント分けされていても,呼び出し(参照)時には自動的にセグメントロードされるため,ローディングは考慮する必要がない.逆に,不必要になったコードセグメント(初期化用のコードなど)をアンロードして,フリーエリアを拡充するためには,Un Load Segで指定のコードセグメントを退避しなければいけない.通常,ユーザーが注意するのは,1コードセグメントを32Kbytes以内に収めることだけである(図10).
 もうひとつ,これも16bitオフセット付きアドレスレジスタ間接アドレッシングの問題だが,Macは,グローバル変数を16オフセットというA5レジスタへの間接アドレスで指定する設計になっている.このため,グローバル変数がトータルで、やはり32Kbytes以内という大きな制限を持っており,プログラム作成を難しくしている.
 ただし,Macにはメモリマネージャによって管理されているヒープ領域というデータ領域があり,ここへのアクセスには制限がない.データ長も,32Kbytes以上のサイズが許されているから,たいていのデータは,このヒープ領域に生成すればよいことになる.
当時はこの記事を読んでいなかったと思う。Macも持っていた知人から「使って天国、作って地獄」と「32Kbytesセグメントの壁」を聞いていた。34年後の今やっと疑問が氷解した。スクラップ作業をして良かったと思う。
ASCII1987(02)d04Mac開発環境セグメント_図10_W520.jpg
nice!(0)  コメント(0) 
共通テーマ:パソコン・インターネット

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。