JPS63177223A - システム生成時におけるアドレス空間編成方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明は、データがそのデータに関する属性情報を有し
、その属性情報をデータを指すポインタデータ側に含め
るようなデータ構造をとるシステムに関し、特にデータ
を指すアドレス表現の一部を属性情報として兼用し、ア
ドレス空間を同一の固定の大きさを持つ複数のセグメン
トに分け、各セグメント内にそのシステムを構成してい
る命令コードも含めた予め定められた種類のデータを定
められた場所へ配置する方式に関する。

〔従来の技術〕

リスト処理システムのリスト表現を扱うような処理方式
において、システムで扱う個々のデータに関する属性情
報（タグ）を、その個々のデータに関連して付与する場
合、そのデータ自身にその属性情報を付加すると、その
データをアクセスするまでは属性を知ることができず処
理速度が低下する。そこで、通常は、上記データのアド
レス空間内の位置を示すポインタデータ内に上記データ
の属性情報を付加し、ポインタデータ取得の段階で上記
データの属性が分かるようにしている。

そして、従来におけるこの種の方式は、ポインタデータ
の全てのビットをアドレスデータとせず、ポインタデー
タの左端の数ビットを残りのビットで表現されるアドレ
スデータが指すデータに関する属性情報を表わすフィー
ルドとして使用するものであった。例えば、ポインタデ
ータが第７図に示すように３２ビツトで構成される場合
、ポインタデータの左端の８ビツト（ｂ２４〜ｂ３１）
を、残りの２４ビツト（ｂｏ〜ｂ２３）のアドレス部Ａ
Ｄで指示されるデータに関する属性情報を格納するフィ
ールドＡＴとするものである。

しかし、上述した従来の方式では、データに関する属性
情報を格納するフィールドＡＴを、そのデータを指示す
るポインタデータ中のアドレス部ＡＤとは別に確保する
ため、アクセスできるアドレス空間の大きさが属性情報
フィールドＡＴの大きさによって制限される０例えば第
７図に示したように、ポインタデータが３２ビツト構造
であり、属性情報フィールドとして８ビツトのフィール
ドＡＴを使用すると、アドレス部ＡＤは２４ビツトにな
るので、アクセス可能なアドレス空間は１６メガバイト
に制限されることになる。

このような問題は、アドレス部ＡＤのビット数を、利用
するアドレス空間の大きさに見合うだけ増加させること
で、一応解消されるであろうが、その分ポインタデータ
のビット数が多くなるので、メモリの利用効率が低下し
、却って好ましくない。

そこで、ポインタデータのビット数を増加させなくても
、そのポインタデータで指示することができるアドレス
空間を拡張し得るようにした方式％式％ この方式は、ポインタデータ自身をアクセスしたとき、
そのポインタデータが指すデータをアクセスすることな
しにそれが指すデータの属性をそのポインタデータ内の
情報によって識別し得るようにする為に、例えば第８図
に示すように、計算機システムのアドレス空間１を、ポ
インタデータ２に含まれるＬビットのアドレスデータ３
の下位Ｎビット中の上位Ｍビットで定まる大きさのセグ
メントＳ０，３１，３２．・・・・・・、に分割し、各
セグメントにおける前記下位Ｎビット中の上位Ｍビット
で定まる２吋個のエリアＥＯ，Ｅｌ、・・・・・・。

のうち、全てのセグメントＳＯ，Ｓｔ、３２．・・・・
・・、において同一位置のエリアには予め定められた同
一の属性を有するデータ（Ａ種データ、８種データ等）
を配置するようにしておき、ポインタデータ２に含まれ
るアドレスデータ３の下位Ｎビット中の上位Ｍビットの
内容と、前記予め定められた配置構成とに基づいてその
ポインタデータ２が指すデータの属性を識別するように
したものである。

例えば第８図において、各ビット数り、　Ｎ、　Ｍをそ
れぞれ３２．１６．　４ビツトとすると、アドレス空間
ｌの各セグメントＳｏ、ＳＬ、３２．・・・・・・。

は、６４キロバイトの大きさとなり、各セグメントの一
つのエリアＥＯ等は４キロバイトとなる。そして、第８
図の例では、各セグメントの先頭から３個のエリアＥＯ
，Ｅ１．　Ｅ２にＡ種のデータが、次の２個のエリアＥ
３．Ｅ４にＢ種のデータが配置される如く、予め各エリ
アに配置されるデータの属性つまり種類が定められてい
る。従って、今、第８図のポインタデータ２をアクセス
して取得し、そのアドレスデータ３の下位Ｎビット中の
上位Ｍビットの内容を識別したところ、セグメントの先
頭から３個のエリアＥＯ，Ｅｌ、　Ｅ２の何れかに該当
していたとすると、前述のようにそのエリアにはＡ種の
データが配置されているので、そのポインタデータ２が
指すデータはＡ種のデータであることが判明する。アド
レスデータ３の下位Ｎビット中の上位Ｍビットはあくま
でもアドレスデータの一部を構成するものである。即ち
、従来のようにポインタデータ内にアドレスデータとは
別に属性情報の格納専用のフィールドを含めるのではな
く、アドレスデータの一部を属性情報の識別用ビットと
して兼用するものであり、従って、アクセスできるアド
レス空間の大きさが属性情報フィールドによって制限さ
れることはなくなり、同一ビット数のポインタデータで
あれば、従来より大きなアドレス空間を利用することが
可能となる。

上記で例示したし＝３２ビットの場合、最大４ギガバイ
トのアドレス空間のアクセスが可能である。

〔発明が解決しようとする問題点〕

ところで、第７図に示したように、アドレス表現として
意味を持たないポインタデータの左端の数ビットをその
ポインタデータが指すデータに関する属性情報を表すフ
ィールドとして使用する従来方式においては、データの
種類に応じて主記憶上の特定の場所にデータを配置する
必要はなく、データの種類を問わず各データが主記憶上
にランダムに配置されていれば良い。

しかしながら、第８図に示したようなアドレス表現方式
を採る場合は、そのシステムが予め所有している各種デ
ータ、命令コードをその属性に応じて定められた場所に
配置することが必要となる。

このような配置を実現する一般的な方法としては、シス
テム起動後の初期化処理として即ちシステムを記述する
ソースプログラムを翻訳して実行可能な形式で主記憶上
にローディングした後の処理として、各データ、命令コ
ードをセグメント内の定められた場所へ移送する方式が
考えられる。

この方式の場合、まず第１に各種データ、命令コードを
目的の場所へ移送し、次にそのデータ、命令コードを指
しているポインタデータを全て新しいアドレス値に更新
するという処理を行なうことになる。ここで、各データ
、命令コードの移送はある程度機械的操作で済むが、そ
のデータを指す全てのポインタデータを更新する作業は
、一般にポインタデータがメモリ中に規則性をもって現
れると規定することができない為、更新すべきポインタ
データが現れる場所をテーブルに登録しておくか、ある
いはチェーンで繋いでお（などの手段が必要となり、こ
の為上述した方式ではデータの移送、ポインタデータの
更新というシステム実行時の処理時間のオーバーヘッド
が実に大きくなってしまい、更に処理も複雑になるとい
う欠点がある。またそのシステムの構造によっては実行
時にデータ、命令コードを移送することは不可能である
場合も考えられる。

本発明はこのような事情に鑑みて為されてものであり、
その目的は、アドレス空間の編成をシステム生成時に行
なうことにより、処理速度の低下を防止することにある
。

〔問題点を解決するための手段〕

本発明は上記目的を達成するために、システムを記述す
るソースプログラムを翻訳し実行可能な形式にして主記
憶上にローディングした際、複数の固定の大きさのセグ
メントで構成されるアドレス空間の各セグメントを構成
する複数個のエリアのうち全てのセグメントにおいて同
一位置のエリアには同一の属性を有するデータ、命令コ
ードが配置されるように、前記ソースプログラム中に、
前記データ、命令コードが配置されるセグメント内のサ
イズに応じた必要な情報を埋込んでおくように構成され
る。

〔作用〕

ソースプログラムの段階で、システムを主記憶上にロー
ディングした際自動的に倉図したセグメント構造に展開
されるような情報をソースプログラムに埋込んでおくこ
とにより、システム生成時に目的とするセグメント構造
を得ることができ、ソースプログラム自体がそのような
構造を持つためポインタデータ中のアドレス値もコンパ
イル時に所望の値に設定される。従って、システム実行
時にデータの配置の為の特別な処理を行なう必要がなく
なる。

〔実施例〕

次に本発明の実施例について図面を参照して説明する。

第１図は本発明の実施例の構成図であり、１ｏはシステ
ムを記述しているソースプログラムを格納する記憶手段
、１１はソースプログラムの人力手段、１２はデータ、
コードサイズの計算手段、１９は計算手段１２で処理さ
れたソースプログラムを格納する記憶手段、１３はソー
スプログラムの編集手段、１４は編集法のソースプログ
ラムを格納する記憶手段、１７はアセンブラ、１８はリ
ンカ、１５はローダ、１６は主記憶装置である。

また、第２図は本発明の実施例で使用するポインタデー
タの構造図である。本実施例は、ポインタデータ２０を
３２ビツトで構成し、その全てのビットをアドレスデー
タ２１として使用し、最大４ギガバイトのアドレス空間
のアクセスを可能としだものである、ポインタデータ２
０が指示するデータの属性がどのようなものかを判定す
る為に使用する属性情報フィールド２２として、本実施
例ではアドレスデータ２１の第１３ビツトから第１５ビ
ツトのｂ１３〜ｂ１５を使用する。

上述のようなポインタデータ構造をとる場合、第３図に
示すようにアドレス空間３０は、大きさが６４キロバイ
ト（２１−バイト）の多数のセグメントに分割する。そ
して、各セグメントは、属性情報フィールド２２のビッ
ト数「３」に応じて８（２’）個のエリアＥＯ〜Ｅ７に
分ける。

今、計算機システムで取り扱うデータ乃至コードの属性
が４種類であり、それがコード（ｌ）、コード（２）、
データ（１）、データ（２）とすると、各セグメントの
同一エリアＥＯ〜Ｅ７にどのような属性のデータ、コー
ドを配置するかは、各属性の量の比率を加味して決定す
る０例えば、その比率が、コード（ｌ）：コード（２）
：データ（ｌ）：データ（２）−３１：２：１ であれば、第３図に示すように各セグメント内のエリア
ＥＯ，Ｅｌ、Ｅ２にコード［１１を、エリアＥ３、Ｅ４
にコード（２）を、エリアＥ５．Ｅ６にデータ＋１１を
、エリアＥ７にデータ（２）を、それぞれ配置するよう
に予め決められる。そして、この場合、例えば第４図に
示すように、アドレスデータ２１中の属性情報フィール
ド２２を構成するピッＩ−ｂ１３゜ｂ１４．　　ｂ１５
が、各セグメントのエリアＥＯ，Ｅｌ。

Ｅ２を指示する（０００，００１，０１０）のときはそ
のポインタデータが指すデータの属性がコード（１１で
ある旨、エリアＥ３．Ｅ４を指示する（０１１．１００
）のときはコード（２）である旨、エリアＥ５．Ｅ６を
指示する（１０１，１１０）のときはそのポインタデー
タが指すデータの属性がデータ（１１である旨、エリア
Ｅ７を指示する（１１１）のときはそのポインタデータ
が指示するデータはデータ（２）である旨を、例えば属
性判定用テーブル等に登録しておく、なお、命令コード
として複数の属性が存在するのは、リスト処理システム
等においては、命令コードの中にはデータの一種として
扱われるものがあるからである。

上述のようにしておけば、例えば第５図に示すように、
主記憶装置５０から読出されデータレジスタ５１に格納
されたデータがポインタデータを含み、そのポインタデ
ータが指すデータの属性を知りたい場合、データ属性判
定手段５２を起動し、このデータ属性判定手段５２によ
って、データレジスタ５１中からポインタデータに含ま
れる属性情報フィールドのビット列（第２図のビットｂ
１３〜ｂ１５）を取出し、この内容と第４図に示すよう
な情報を記憶するテーブル５３の内容とから今回のポイ
ンタデータで指示されたデータの属性を判断することが
できる。そして、今回のポインタデータが指すデータを
読込む必要があるときは、データレジスタ５１に格納さ
れたポインタデータを用いてそのデータをアクセスする
ことができる。

次に、主記憶上に上述のような配置構成になるようシス
テムを記述するデータ、コードを自動的に展開する方式
について説明する。

第１図において、入力手段１１は、記憶手段ｌＯからシ
ステムを記述する例えばアセンブリ言語で書かれたソー
スプログラムを入力し、計算手段１２に渡す。計算手段
１２は、第３図に示したような形式でシステムが展開さ
れるようデータ、コードサイズの計算処理を行ない、そ
の結果を記憶手段１９を介して編集手段１３に渡し、編
集手段１３はソースプログラムの編集処理を行なう。編
集されたソースプログラムは記憶手段１４に格納され、
その後、アセンブラ１７により翻訳され、リンカ１８で
リンクされて実行可能な形式にされ、ローダ１５によっ
て主記憶装置１６にロードされる。

第６図は計算手段１２の処理例の流れ図であり、Ｔ１−
Ｔ１５は各ステップを示す。第６図に示すように、計算
手段１２は、入力したアセンブリ言語の一つの命令がコ
ード（１）、コード（２）、データ（１）、データ（２
）の何れの種類に属するかをチェックしくＴ１−７３）
、対応する処理へ進む。例えば、入力した命令がコード
（１）である場合、これまで入力したコード（１１のサ
イズの合計がコード（ｔ＋領領域サイズ（第３図のエリ
アＥＯ〜Ｅ２の合計サイズ）を越えていないかどうかを
調べ（Ｔ４）、越えていなければ次の命令に処理を移す
が、もし越えていればソースプログラム上のその位置に
１第ｎセグメントコード（１）゛という印を挿入しくＴ
５）、これまで入力したコード（１）のサイズの合計を
クリアする（Ｔ６）、ここで、ｎは１から昇順に使用さ
れる値である。これと全く同じ処理が、ステップＴ７〜
Ｔ９によりコード（２）に対し、ステップＴＩＯ〜Ｔ１
２によりデータ（１）に対し、ステップＴ１３〜Ｔ１５
によりデータ（２）に対し行なわれる。

計算手段１２による第６図に示した処理が入力手段１１
から渡される全ての命令について行なわれ、それが完了
すると、編集手段１３が起動され、編集手段１３は、記
憶手段１９に格納されたソースプログラムに対し計算手
段１２で付けられた印に基づいて、［第１セグメントコ
ード（ｉｌｌ、ｒ第１セグメントコード（２１Ｊ、ｒ第
１セグメントデータ（１１Ｊ’　、　　ｒ第１セグメン
トデーク（２１Ｊ、ｒ第２セグメントコード（ＩＩＪ、
ｒ第２セグメントコード（２１Ｊ、ｒ第２セグメントデ
ータ（ｉｌ」、ｒ第２セグメントデータ（２）Ｊ。

・・・・・・、という順にセグメントが構成されるよう
にソースプログラムの編集を行なう。

この編集方式に関してはアセンブラ（或いはコンパイラ
）、リンカ等が持っている機能を使用しても良く、例え
ば“第１セグメントコード（ｌビという印を、主記憶上
の所定の場所ヘロードされるよう指示するアセンブラの
ＯＲＧ命令に置換えることが考えられる。またそうでな
ければ単純に各データ、コード領域を順番にマージする
こともでき、その場合各データ、コード領域に規定のサ
イズに満たないものがあったときはそのサイズ一部分だ
け空き領域を確保するようにして所定のセグメント構造
を保証する。また、これらの処理を行なう手段としては
マクロ言語を設定したり、処理プログラムを作成する方
法が考えられる。

編集手段１３で編集された情報は記憶手段１４に格納さ
れ、後のシステム生成時に、アセンブラ１７によって翻
訳され、リンカ１８によって実行可能な形式にされた後
、ローダ１５によって主記憶装置１６にロードされる。

このとき、記憶手段１４に格納された各データ、コード
は、ソースプログラムの段階でそれが対応するセグメン
ト内の定められた場所ヘローディングされるよう編集さ
れているものであるから、各データ、コードは第３図に
示した構成で自動的に配置されることになり、且つ、ポ
インタデータが所望のアドレス値に設定される。従って
、システム実行時にデータの配置のための特別な処理を
行なう必要はない。

以上本発明の★施例について説明したが、本発明は以上
の実施例にのみ限定されず、その他各種の付加変更が可
能である。例えば、主記憶上にローディングした際に自
動的に意図したセグメント構造に展開されるようソース
プログラムのコーディング時に予め上述したデータ、コ
ードのサイズの計算を行ない且つ必要な情報を人手によ
り埋込むようにしても良い。また、上記実施例はポイン
タデータとアドレスデータとを同一ビット数としたが、
ポインタデータのビット数よりアドレスデータのビット
数を小さくすることも可能である。

また、システムで使用可能な全てのアドレス空間をセグ
メント化する以外に、必要部分のみをセグメント化する
ようにしても良い。更に、属性情報フィールドを３ビツ
トとし、属性情報の種類を４種類としたが、各々必要に
応じて任意の値とすることができる。

〔発明の効果〕

以上説明したように、本発明は、システムを記述してい
るソースプログラムを入力し、データ。

コードの種類を判定し、そのサイズを計算して各データ
、コードがセグメント内の定められた場所ヘローディン
グされるようソースプログラム中に必要な情報を埋込ん
でおくことにより、予め定められた種類のデータ、コー
ドをセグメント内の定められたアドレスをもつ場所へ配
置しなければならないという特殊な処理をシステム実行
時ではなくシステム生成時に行なうことができるためそ
の処理時間をシステム実行時間に含める必要がなく、そ
のために処理速度の低下を招くことがないという効果が
ある。従って、上記４ｑ上のデータを指すアドレス表現
の一部をそのデータの属性を表す属性情報として使用す
るシステムを有効に実施することができる。

【図面の簡単な説明】

第１図は本発明の実施例の構成図、 第２図は本発明の実施例で使用するポインタデータの構
造図、 第３図は本発明の実施例におけるアドレス空間の使用例
を示す図、 第４図は属性情報フィールドのビット内容とデータ属性
との関係図、 第５図はデータ属性識別動作の説明図、第６図は計算手
段１２の処理例の流れ図、第７図は従来方式のポインタ
データ構造を示す図および、 第８図はアドレス表現の一部を属性情報として使用する
システムの構成図である。 図において、１．３０・・・アドレス空間、２．２０・
・・ポインタデータ、３，２１・・・アドレスデータ、
４゜２２・・・属性情報フィールド、１１・・・ソース
プログラムの入力手段、１２・・・データ、コードサイ
ズの計算手段、１３・・・ソースプログラムのｋＩ集平
手段ＳＯ〜Ｓ２・・・セグメント、ＥＯ〜Ｅ７・・・エ
リア。

Claims (1)

【特許請求の範囲】
1. システムを記述するソースプログラムを翻訳し実行可能
   な形式にして主記憶上にローディングした際、複数の固
   定の大きさのセグメントで構成されるアドレス空間の各
   セグメントを構成する複数個のエリアのうち全てのセグ
   メントにおいて同一位置のエリアには同一の属性を有す
   るデータ、命令コードが配置されるように、前記ソース
   プログラム中に、前記データ、命令コードが配置される
   セグメント内のサイズに応じた必要な情報を埋込んでお
   くようにしたことを特徴とするシステム生成時における
   アドレス空間編成方式。