JP2007234048A - コード圧縮技術の高速プロトタイピングを可能にするプログラムのコード圧縮方法、プログラムのコード圧縮システム - Google Patents

Abstract

【課題】コード圧縮技術の高速プロトタイピングを可能とするプログラムのコード圧縮方法の提供。
【解決手段】プログラムのコード圧縮のための方法であって、当該方法はデータからコードを分離するステップを備える。圧縮空間と非圧縮空間の間でアドレス・マッピングを行うためのソフトウェア変換が、コードに導入される。命令の出現頻度に関する統計が取得され、前記統計には2個の連続する命令の出現頻度も含まれる。命令または命令ペアの出現を識別するために、プログラムが解析される。識別された命令は、圧縮バス語テーブルを示すアドレスと置換される。非圧縮アドレスから圧縮アドレスへのアドレス・マッピングが生成される。
【選択図】図４

Description

本発明は、コード圧縮に関連する技法に関し、特に、コンピュータ・コードの高速プロトタイピングを可能にするハードウェア／ソフトウェア・プラットフォームに関する。

１． 参考文献
以下の各論文は有益な背景情報を提供するものであり、それを理由として引用によりその全体がここに組み込まれ、本明細書の以降の部分では各々に付される括弧で囲んだ参照番号により適宜言及される。

L. Benini, A.Macii, E. Macii, and M. Poncino. Selective Instruction Compression for MemoryEnergy Reduction in Embedded Systems（組み込みシステムにおいてメモリ・エネルギを削減するための、命令の選択的な圧縮）. IEEE／ACM Proc. ofInternational Symposium on Low Power Electronics and Design （ISLPED ‘99）, pages 206-211,1999. IBM. CodePackPowerPC Code Compression Utility User’s Manual Version 3.0（IBM CodePackPowerPCコード圧縮ユーティリティ ユーザーズ・マニュアル バージョン3.0）, 1998. N. Ishiura and M.Yamaguchi. Instruction Code Compression for Application Specific VLIWProcessors Based on Automatic Field Partitioning（特定用途向けVLIWプロセッサのための、自動フィールド分割に基づく命令コード圧縮）. Proceedings ofthe Workshop on Synthesis and System Integration of Mixed Technologies,, pages105-109, 1998. C. Lefurgy, P.Bird, I. Cheng, and T. Mudge. Code Density Using Compression Techniques（圧縮技法を使用したコード密度）. Proceedings ofthe Annual International Symposium on MicroArchitecture, pages 194-203,December 1997. C. Lefurgy and T.Mudge. Code Compression for DSP（DSPのためのコード圧縮）. CSE-TR-380-98, Universityof Michigan, November 1998. C. Lefurgy, E.Piccininni, and T. Mudge. Reducing Code Size with Run-time Decompression（実行時圧縮によるコード・サイズの縮小）. Proceedings ofthe International Symposium of High-Performance Computer Architecture, January2000. S.Y. Liao, S.Devadas, and K. Keutzer. Code Density Optimization for Embedded DSP ProcessorsUsing Data Compression Techniques（組み込みDSPプロセッサのための、データ圧縮技法を使用したコード密度最適化）. Proceedings of theChapel Hill Conference on Advanced Research in VLSI, pages 393-399, 1995. T.Okuma,H.Tomiyama, A.lnoue, E.Fajar, and H.Yasuura. Instruction Encoding Techniquesfor Area Minimization of Instruction ROM（命令ＲＯＭのエリア最小化のための命令符号化技法）. International Symposiumon System Synthesis, pages 125-130, December 1998. A. Wolfe and A.Chanin. Executing Compressed Programs on an Embedded RISC Architecture（組み込みRISCアーキテクチャでの圧縮プログラムの実行）. Proceedings ofthe International Symposium on Microarchitecture, pages 81-91, December 1992. Y. Yoshida, B.-Y.Song, H. Okuhata, and T. Onoye. An Object Code Compression Approach to EmbeddedProcessors（組み込みプロセッサのためのオブジェクト・コード圧縮手法）. Proceedings ofthe International Symposium on Low Power Electronics and Design （ISLPED）, ACM:265-268,August 1997.

２． 序文
特徴サイズが継続的に縮小するというムーアの縮小則がシリコン技術に登場して以来、設計者は常に過酷な制約を課せられてきた。確かに、集積密度を高くすることによってダイ・サイズの縮小が可能になるが、これはあくまで、ダイ1個当たりのトランジスタ数が一定であると想定した場合の話である。現実には、適用業務の複雑化に伴って必要とされる処理電力とメモリ・サイズが増大し、ダイ・サイズそのものも急速に拡大した。また、このダイ・サイズの拡大に伴って、単位面積当たりの電力損失、信号保全性といった面での問題も大幅に増大するという副次的な影響も出ている。こうした問題に対処するため、現在では様々なレベルの抽象化を使用する多様な技法が採用されている。

コード圧縮は古い技術であり、マイクロ・プロセッサ時代の初期から広く使用されてきた。プロセッサの命令コードを大幅に圧縮できれば、メモリ使用量を縮小でき、またチップ面積についても、程度は様々ながら明らかな縮小が期待できる。これによって、上記の問題の少なくとも一部は解決できる。しかし、コード圧縮が顕著な影響をもたらしたというのは、メモリ・サイズの縮小だけに注目した場合でのことである。圧縮解除のためにはハードウェアを追加しなければならず、このオーバヘッドを考慮するとコード圧縮を採用する意味がなくなるケースは決して少なくない。

近年、コード圧縮技術の利点を拡大する方法が数多く研究されてきた。こうした研究では、コード圧縮によって、メモリ使用量の最小化だけでなく、システムのパフォーマンス向上や電力消費量の最小化にどこまで貢献できるかが調査された。コード圧縮の利点拡大の鍵は、圧縮ハードウェアと命令コードが使用される場所（すなわち、プロセッサ）との距離をできるだけ小さくする技法にある。この距離を小さくすると、バス・キャッシュ階層、メイン・メモリなど多数のシステム部品のすべてが、高い帯域幅（バス、メモリ・システム）で命令を圧縮することによる利点を享受できる。

しかし、これらの技法を適用する際には、1つの問題が浮上してくる。それは、命令をオンザフライで圧縮解除するための圧縮解除ハードウェアが大幅に複雑になることである。本明細書で論じるように、これには綿密に設計されたハードウェアを要する。コード圧縮を使用するシステムでは、適切な設計により、パフォーマンスの向上、メモリ使用量の削減、電力消費量の削減という利点をもたらすことができる。

３． 関連の研究
以下では、まず最も関連の深い研究について検討し、続いて本発明の手法の相違点と利点を指摘する。

Wolfe and Chaninは、キャッシュ・ミスを使用して圧縮解除をトリガする最初のシステム、CCRP（Compressed Code
RISC Processor： 圧縮コードRISCプロセッサ）を開発した（非特許文献９参照）。この圧縮解除エンジンは、キャッシュ・リフィル・ハードウェアに内蔵される。

各L1キャッシュ・ブロック内の命令は個別にハフマン符号化されるので、各ブロックの圧縮解除を個別に実行でき、他のブロックを事前に圧縮解除する必要がない。ハフマン・コードは可変長コードなので、復号にはディクショナリを使用する方法よりも時間がかかる。固定長キャッシュ・ブロックは圧縮を経て可変長ブロックになるので、キャッシュ・ミスのネイティブ・アドレスを圧縮コード・アドレスにマップするための索引テーブルが必要とされる。

圧縮解除エンジンがデータを検出するためには、この索引テーブルに対して1レベル分ほど余分に検索を実行しなければならない。Wolfe and Chaninは、MIPSアーキテクチャ上での圧縮率として73%を報告している。

CodePackをIBMの組み込みPowerPCシステムで使用する方法も提案されている（非特許文献２参照）。このスキームはメモリ・システムと一体化されており、この点でCCRPと類似している。CPUは圧縮を認識せず、LATに似たデバイスがネイティブ・アドレス空間と圧縮アドレス空間との間のマッピングを行う。圧縮解除エンジンは、L1キャッシュ・ミス・アドレスを受け取り、メイン・メモリから対応する圧縮バイトを取り出して圧縮解除し、ネイティブのPowerPC命令をL1キャッシュに返す。

CodePackはPowerPC上で60%の圧縮率を達成する。IBMは、圧縮コードを使用した場合のパフォーマンスの変動はネイティブ・プログラムの10%の範囲内であり、場合によっては高速化が実現される、と報告している。この高速化は、CodePackが、その基礎を成すプロセッサにはないプリフェッチ動作を実現することによって可能になる。

ソフトウェアによる圧縮解除も可能である。ソフトウェアで圧縮解除を行うと、ハードウェア設計が簡素化されるほか、圧縮解除を実行時に選択することが可能になるという利点が得られる。ハードウェアが簡素化されるのは、圧縮解除ソフトウェアが、独立した専用の論理構造を備えるのではなく、プロセッサ・コアで算術演算装置を使用するためである。Lefurgy et al.（非特許文献６参照）は、ソフトウェアによる圧縮解除をサポートするための2つのハードウェア・メカニズムを提案した。第1のメカニズムでは、L1キャッシュ・ミスによって、圧縮解除プログラムを実行するキャッシュ・ミス例外がトリガされる。第2のメカニズムでは、圧縮解除が使用する特権命令によって、圧縮解除された命令が命令キャッシュに直接格納される。圧縮解除ソフトウェアは圧縮されず、圧縮解除例外が発生しないメモリ領域に常駐する。純粋にソフトウェアでのみ実行できるもう1つの技法は、Liao et al.（非特許文献７参照）で提唱されたディクショナリを使う手法である。この手法では、小さなサブルーチンが導入され、頻出するコード断片と置き換えられる。

Ishiura and
Yamaguchi（非特許文献３参照）では、VLIWプロセッサのための、自動フィールド分割に基づく圧縮スキームが提唱されている。

このスキームでは、命令の部分フィールドに対してコードを生成することにより、圧縮解除テーブルのサイズ膨張を防止する。Benini et al.（非特許文献１参照）では、命令を選択的に圧縮することにより、ディクショナリのサイズ膨張を防止する。Lefurgy et al.でもやはり、DSP圧縮作業で使用したディクショナリ・スキームが示されている（非特許文献５参照）。Okuma et al.（非特許文献８参照）では、命令内のフィールドについても考慮するという、興味深い符号化技法が提案されている。Yoshida et al.（非特許文献１０参照）では、電力削減効果もある、対数ベースの圧縮スキームが提唱されている。

C． コード圧縮の基本
次に、コード圧縮の基本技法と重要概念について説明する。

１． ランダム・アクセス
コード圧縮の重要概念の1つに、ランダム・アクセスというものがある。コード圧縮では、ファイル全体（画像ファイルなど）を圧縮するのではなく、任意の時点に、コードに含まれる単一のコード・セクションを限定的に圧縮解除できなければならない。すなわち、コード圧縮では、特定のコード・セクションにランダムにアクセスする（すなわち、圧縮解除する）機能が必要とされる。ランダム・アクセスが必要なのは、ソフトウェア・プログラムの制御フローが非順次的な性質をもつからである。コード全体を1度に圧縮解除できても、技術的にはあまり意味がない。コード全体を単一のストリームとして圧縮解除する場合のメモリ使用量は、圧縮されていないプログラムで必要とされるメモリ量と同程度かそれ以上になる。つまり、コード圧縮技法でランダム・アクセスが行われない場合には、システム・メモリの使用量削減の利点が得られないのである。

２． コード圧縮における細分性
上記のランダム・アクセスの特性を実現するためには、コード全体をセクションに分解し、個別に圧縮解除する必要がある。圧縮解除履歴上の理由から、圧縮解除を開始できるのは各セクションの境界の開始点に限られる。このセクションとしては、様々な単位を使用できる。その主な例としては以下のものが挙げられる。

ａ） 基本ブロック
基本ブロックは、常に最初から最後までの全体が順に実行されるコード・シーケンスである。ランダム・アクセスの特性を鑑みて、細分性の単位として最も明白なものはこの基本ブロックである。基本ブロックは、通常、多数のアセンブリ命令で構成される。その意味で、基本ブロックを単位として使用する場合には、十分な圧縮率を得る上で適度なサイズかどうかを考慮する必要がある。基本ブロックの欠点は、サイズのばらつきが大きいことである。このサイズには、アセンブリ命令数が1個から数百個までと、かなりの幅がみられる。圧縮解除メカニズムを実装する際には、このサイズのばらつきは圧縮解除時間のばらつきという技術的な問題に直結する。また、システム実行時間の観点から考えると、非決定性の動作を引き起こすという問題の原因となる。さらに、こうした問題に関連して、圧縮解除に要する絶対時間の問題も浮上してくる。例えば、通常の労力を費やして設計したハードウェアを想定した場合、基本ブロックの通常の平均サイズからすると、（速度が最適化されたシステムにおいて）1回のシステム・クロックサイクルで1つの基本ブロックを圧縮解除することは不可能である。アーキテクチャによっては、数回のクロックサイクル（場合によっては1回のクロックサイクル）で圧縮解除を確実に完了する高速圧縮解除が必要とされることもあるので、絶対時間の問題が重大な障害となる可能性は高い。

ｂ） 命令
コード圧縮が技術的に適用可能な最小のエンティティは、単一命令である。単一命令のサイズは小さいので、圧縮解除を1回のクロックサイクルで完了することは十分に可能である。そのため、単一命令は、ポストキャッシュ・アーキテクチャと呼ばれる環境できわめて有用である。しかし、サイズが小さいと、基本ブロックをベースとする手法に比較して、圧縮率が大幅に低くなるという問題が生じる。また、圧縮解除ハードウェアがどの程度複雑となるかは、命令の形式によって決まる。

これらの部品の細分性については、本明細書の後半で詳細に論じる。「圧縮解除履歴」は、圧縮解除メカニズムの状態と関連付けられる。

（1） 非固定命令サイズ
非固定命令を使用する場合は、圧縮スキームに様々な制約が導入される。ディクショナリ・ベースの圧縮手法では、様々なサイズの記号によってビットが無駄に消費されるという問題や、同じサイズの記号を各々保持する多数のディクショナリがハードウェア・スキームを複雑にするという問題が生じる。圧縮命令ストリームが圧縮解除される際には、様々なサイズの命令が生成される。その後、これらの命令をアセンブルして、プロセッサに送信できるワード（例： 32ビット）を作るのはハードウェアの仕事となる。ワードのアセンブル中に圧縮されていない命令のサイズを認識する作業は、ハードウェア集約的なタスクであり、長いラテンシが発生する。

本発明に示す技法を実装するプラットフォーム例は、TensilicaのXTensaプロセッサをベースとする。このプロセッサの命令ワードのサイズは、幅24ビットと幅16ビットである。

（2） 固定命令サイズ
命令サイズが固定の場合は、上記の問題もハードウェア・オーバヘッドも生じない。

３． 索引付け
コード圧縮における索引付けは、ランダム・アクセスの過程で発生する問題である。この問題とは、索引付けによって圧縮空間内のジャンプ・ターゲットのアドレスを示さなければならない、というものである。これが必要なのは、ジャンプ・ターゲットに先行するコードは圧縮解除されないからである。

よって、ジャンプ・ターゲットのアドレスは未知である。コードの各部の圧縮率は一定であるとは想定できないので、ジャンプ・ターゲットのアドレスも計算できない。Wolfe and Chanin（非特許文献９参照）は、非圧縮ブロックの位置（アドレス）を圧縮ブロックの位置にマップするテーブルの使用を提唱した。この方法の主な欠点は、ブロック・サイズが縮小するにつれて、テーブルを格納するためのオーバヘッドが増大することである。このほかに、圧縮フェーズでは分岐を放置しておき、その後オフセットをパッチして圧縮空間をポイントする手法も提唱されている（非特許文献４参照）。本発明の手法はこれに類似しているが、分岐についても圧縮を行う点が異なる。

４． 基本アーキテクチャ
この節では、コード圧縮解除に伴うアーキテクチャ上の問題について、その基本原理を大まかに説明する。図1は、多数のコード圧縮解除技法で使用される基本原理を示したものである。命令コードは命令メモリ内に配置され、圧縮解除ハードウェアはここから命令コードをフェッチする。圧縮解除されたコードはCPUに渡される。

これに関連した問題と方策としては、次のものが挙げられる。

ａ） メモリ階層
圧縮解除アーキテクチャでは、L1キャッシュ、L2キャッシュなどのメモリ階層を中間位置に置くことができる。パフォーマンスの問題とメモリ・サイズの問題は、圧縮解除装置をアーキテクチャのどこに配置するかによって大きく異なる。

ｂ） バス・システム
バスなどの通信インフラストラクチャも、圧縮コードを転送することによって利点を得ることができる。

その利点とは、有効帯域幅の増大である。この場合も、その効果の大小は、圧縮解除装置をどこに配置するかによって大きく異なる。

ｃ） ポストキャッシュ・アーキテクチャとプリキャッシュ・アーキテクチャ
実装を開始する前に、本発明においてプリキャッシュ・アーキテクチャ、ポストキャッシュ・アーキテクチャと呼ぶアーキテクチャの利点と欠点を評価するためのシミュレーションを実行した。ここでは、有効バス帯域幅に関連する測定基準として、バス上のトグル回数を使用する。

図2に、この2つのアーキテクチャを示す。プリキャッシュ・アーキテクチャでは、圧縮解除エンジンはメイン・メモリと命令キャッシュの間に配置されている。ポストキャッシュ・アーキテクチャでは、圧縮解除エンジンは命令キャッシュとプロセッサの間に配置されている。この図から明らかなように、ポストキャッシュ・アーキテクチャでは、命令はCPUに供給される前にのみ圧縮解除されるので、圧縮命令コードの効果は両方のデータ・バスに及ぶ。一方、プリキャッシュ・アーキテクチャでは、圧縮命令コードの効果はデータ・バス2にしか及ばない。様々な効果を明らかにするために多様な実験を行い、その中からアプリケーション・トリックを選んだ。対象とする両アーキテクチャ上でアプリケーションを実行し、その間のビット・トグル数を計数した。ビット・トグル数は、有効帯域幅（および、電力消費量などのその他の測定基準）に関連付けられる。図3にトリックの結果を示す。図3は3つの図で構成されている。（ａ）の図は、データ・バス1のビット・トグル数である。データ・バス1については、キャッシュ・ヒットを示すビット・トグルのみを示す。

これによって、データ・バス1上のキャッシュ・ヒットに関連するトグル数が、データ・バス2上のトグル数（キャッシュ・ミス）の減少に伴ってどのように増加するかを知ることができる。（ｂ）の図にはデータ・バス2上のトグル数を示し、（ｃ）の図にはデータ・バス1、2の合計を示す。この3つの図において、x軸上のパラメータはキャッシュ・サイズ（単位：バイト）である。

複数層のメモリ階層をもつシステムでコード圧縮用に使用される「プリキャッシュ」と「ポストキャッシュ」のアーキテクチャは、図2に示すとおりである。

図３の各図には、３本のグラフが示されている。一番上のグラフは、命令の圧縮がまったく行われない場合を示す。二番目のグラフはポストキャッシュ・アーキテクチャを使用した場合を示し、三番目のグラフはプリキャッシュ・アーキテクチャを使用した場合を示す。図３の（ａ）の図を見ると、キャッシュ・サイズの増大に伴ってビット・トグル数が増大していることが分かる。これら3種類のアーキテクチャは、最終的には飽和点に到達する。飽和点とは、キャッシュ・ヒット数が上限に達して、ビット・トグル数が増大しなくなった時点のことである。ここでは、次の2点が最も注目される。

ａ） ポストキャッシュ・アーキテクチャが「飽和点」に最も早く到達し（512バイト）、プリキャッシュ・アーキテクチャと圧縮なしアーキテクチャは1024バイトでこれに到達する。「飽和点」に早く到達することは、実質的にはキャッシュ・サイズが大きいのと同じことである。つまり、圧縮解除エンジンをポストキャッシュ・アーキテクチャで使用した位置に置くだけで、パフォーマンスの損失を発生させずに、キャッシュ・サイズを最初のサイズの半分にすることができるのである。あるいは逆に、キャッシュ・サイズをそのまま維持することもできる。この場合は、パフォーマンスが向上する。パフォーマンスの向上が必要ではない場合は、例えば、クロック周波数を下げることにより、パフォーマンスの向上を追求しない代わりにエネルギ／電力を節減する、といった方策が可能になる。

ｂ） サイズが適度な場合、一定の命令キャッシュ・サイズにおけるトグル数は、ポストキャッシュを採用すると最小になる（「適度な」キャッシュ・サイズとは、上記の「飽和点」に到達できるサイズであり、このサイズではキャッシュ・サイズとキャッシュ・ミス数のバランスが良好に保たれる）。したがって、ポスト・キャッシュは、データ・バス1のエネルギ効率が最も高くなるアーキテクチャであると換言することができる。

図３の（ｂ）の図は、データ・バス2上のトグル数を示したものである。データ・バス２では、以前にキャッシュ・ミスが発生したすべての命令が転送される。この図から、次のことが観察される。

ａ） トグル数は、命令キャッシュのサイズにかかわらず、ポストキャッシュ・アーキテクチャの方がプリキャッシュ・アーキテクチャよりも少ない。

ここで、圧縮を行わないアーキテクチャとプリキャッシュ・アーキテクチャの曲線はほぼ重なっており、まるで1つのグラフのように見えることに注目されたい。これは、有効キャッシュ・サイズが大きい（上記参照）とキャッシュ・ミスが少なくなり、ひいてはデータ・バス２上のトラフィックが減少する（これはビット・トグル数に関連する）ためである。

ｂ） プリキャッシュ・アーキテクチャの非圧縮アーキテクチャに対する優位性は、データ・バス1では出現しないが、圧縮命令が転送されるデータ・バス２では出現する。

ここで問題となるのは、データ・バス1上とデータ・バス2上では、命令コードに関連するビット・トグルの総数はどの程度か、ということである。図３の（ｃ）のグラフを見ると、この答えが得られる。妥当な命令キャッシュ構成を使用した場合、ポストキャッシュ・アーキテクチャではビット・トグル数が最小となり、プリキャッシュ・アーキテクチャでは、どのような状況においても非圧縮アーキテクチャよりも良好かほぼ同じ結果となる。ちなみに、128バイトの命令キャッシュ・サイズは、十分なパフォーマンスが得られないため、「適度な」サイズとは言えない。

最近のプロセッサの中には、L1キャッシュが組み込まれているものもある。この場合でも、L1キャッシュとL2キャッシュの間に本発明の圧縮解除エンジンを配置することは可能である。

D． コード圧縮における障害
次に、ポストキャッシュ・アーキテクチャ、もしくはキャッシュを内蔵しないアーキテクチャのいずれかで動作するコード圧縮スキームを設計する際に遭遇される、いくつかの重要な問題を示す。

１． プログラム・カウンタからプログラム・フローを推論できないという問題
パイプライン効果のために、CPUが分岐を実行したかどうかを知ることが不可能な場合がある。例として、次のケースについて考察する。
bnez a5, L1
sub a2, a3,
a4
addi a3,
a3, 1
and a2, a2,
a3
L1: or a1,
a2, a3

CPUから入ってくるプログラム・カウンタ値を観察することで分岐が取られたか否かを判断できないのは、パイプライン効果によってbnez命令以降のすべての命令がとりあえず要求されるからである。外部圧縮解除エンジンは、これらの命令が実際に実行されたかどうかを認識することができない。これが問題となるのは、圧縮解除エンジンがこれらの命令に反応して何らかのアクションを起こす可能性があるからである。例えば、addi命令ではなく呼び出し命令が出現した場合でも、圧縮解除エンジンは呼び出しスタックにアドレスを挿入してしまうことがある。

２． 分岐／ジャンプ命令
コード圧縮において、分岐、ジャンプ、呼び出しなどを処理することは、非常に難しい問題となる。コード圧縮スキームで、非圧縮アドレスから対応する圧縮アドレスへの完全なマッピングが行われない場合には、潜在分岐ターゲットを検出するメカニズムが必要となる。すべての潜在分岐ターゲット（図3 トリック・アプリケーション。（ａ）：データ・バス1上のトグル。（ｂ）：データ・バス2上のトグル。（ｃ）：トグル10の合計）がプログラム内で既知であると想定すると、圧縮されていない分岐ターゲットのアドレスから対応する圧縮アドレスへのマッピングだけを行うスキームを作成することが可能である。

ただし、レジスタへのジャンプやレジスタへの呼び出しが存在する命令セットは多数に上るため、実行可能ファイルのみからすべてのターゲットを導出することは不可能である。多くの場合、レジスタへのジャンプ命令は、ジャンプ・テーブルからレジスタ値をロードする。このジャンプ・テーブルは、実行可能ファイルに配置して、潜在ターゲットを取り出すのに使用できる。ただし、場合によっては、ランタイム中に実行される算術演算によりターゲット・アドレスが生成され、潜在ターゲットの検出が、不可能ではないまでも非常に困難になることがある。我々自身も、実行可能ファイルでの処理中に、ある種のC言語構造体（スイッチ文など）がこのようなコードを生成するケースに遭遇したことがある。このとき、実行可能ファイル内のプログラム・フローを丁寧に調べたが、こうしたケースを解決することはできず、ましてやこれを解決するソフトウェアを記述することは到底不可能であった。この問題は、これまでのコード圧縮の研究で看過されてきたものと思われる。

３． コードの位置合わせ
以下の問題は、事実上すべての命令セット・アーキテクチャで発生する一般的な問題である。この問題は、圧縮空間内でのコードの配置と位置合わせに関連する。まず、この問題が発生する想定条件／状況について説明し、次に問題と考えられる解決策について論じる。未知のジャンプ・ターゲット問題が解決されれば、すべてのジャンプ・ターゲットの位置をワードの境界に合わせることが可能になり、この問題は解決されることに留意されたい。ただし、この一般的なケースにおいては、どの命令も潜在ターゲットである場合には、コード配置問題においてこの制約条件を辿ることはほぼ不可能となる。

想定条件：
ａ） ジャンプが発生する。

ｂ） 圧縮空間内のジャンプ・ターゲットと非圧縮空間内のジャンプ・ターゲットは、ワード内の異なるロケーションをポイントする。CPC（圧縮空間内のプログラム・ポインタ）は圧縮環境下にあるため進行が遅いので、異なるロケーションがポイントされる状況はかなりの高頻度で見られる。また、他の理由により（復号など）、いずれのケースにおいても、PCとCPCはバイト境界に位置合わせされることに留意する必要がある。

ｃ） プロセッサは、フェッチが発生すると、次の有効な命令のアセンブル時に全語のすべてのバイトが使用されない場合も含めて（命令は、ワードのサイズよりも小さいこともありうる）、常に全語をフェッチするものと想定する。

ここで問題が発生する。それは、圧縮空間内ではジャンプが境界のアドレスに到達するため、この境界から開始する圧縮解除は、次のワードにアクセスしなければ全語を引き渡さない、という問題である。換言すれば、全語をプロセッサに引き渡すためには、まず次のワードにアクセスしなければならないのである。そのため、フェッチをさらにもう1回実行する必要がある。この1回のフェッチのために、最低でも1サイクル分が余分に必要になるのだ。CPUを停止することはできないので、こうしたケースを未然に防止するためには別の手段を講じなければならない。このケースの条件は次のように表すことができる。

f（bs（jump
target; n））_word length （1）
ここで、f（y）は、長さyの圧縮されたビット・シーケンスの、非圧縮空間におけるビット数を返す関数である。bs（a；b）は、圧縮空間内の、a_th：位置から開始し、b_th：位置で終了するビット・シーケンスである。jumptarget_th：は、圧縮空間内の、ジャンプがポイントするビット位置である。nは、圧縮ワード内の、ジャンプがターゲットとする最後のビットである。

他の命令に順に続いているが、ジャンプで飛び越されてフェッチされない命令が、圧縮空間内の2ワードにまたがる場合には、この問題は発生しないことに注意する必要がある。この場合は、圧縮履歴によって、必ず全語が引き渡される。これは、全語に命令の一部しか含まれない場合も同様である。このケースは従来の実行と何ら異なるものではなく、典型的にはプロセッサ・ハードウェアによって処理される。

（発明の目的）
本発明は、上記の問題のいくつかを解決するための、プログラムのコード圧縮方法を提供することを目的とする。

この方法は、データからコードを分離するステップで構成される。圧縮空間と非圧縮空間の間でアドレス・マッピングを行うためのソフトウェア変換が、コードに導入される。命令の出現頻度に関する統計が取得され、前記統計には２個の連続する命令の出現頻度も含まれる。命令または命令ペアの出現が識別するために、プログラムが解析される。識別された命令または命令ペアは、前後して出現する命令を出現頻度に基づいて並べ替えて格納した圧縮バス・ワードテーブルを示すアドレスと置換される。非圧縮アドレスから圧縮アドレスへのアドレス・マッピングが生成される。

命令ではなくワードをベースとする上記と類似した技法も、本発明の範囲に含まれる。

本発明を実装するためのシステムも本発明の範囲に含まれる。

本発明によれば、以下に述べるような効果が得られる。

第１に、圧縮解除は、オンザフライで、プロセッサに近い位置で実行される。これにより、メモリとバス帯域幅が増大するので、コード圧縮の効果がシステム全体に及ぶ。

第２に、本発明で述べるプラットフォーム例はアプリケーション非依存であり、2番目の解決策はISA（命令セット・アーキテクチャ）非依存である。

これにより、実質的な変更を加えることなく、多数の用途向けに適用することが可能である。

第３に、圧縮解除ハードウェアは、CPUの内部に侵入することなく、CPUにインタフェースする。そのため、この技術はあらゆるCPUに適応できる。これは、本発明の技術を他のハードウェア・プラットフォームに移植する場合、プロセッサと圧縮解除エンジンをつなぐインタフェース・モジュールを変更するだけでよいことを意味する。

第４に、前述のハードウェア／ソフトウェア・プラットフォームは、特定の圧縮に固定されない。そのため、様々なテーブル・ベースのスキームを調べることが可能である。本発明の技術では、様々な圧縮形式に対応できる十分なメモリ空間が提供される。

これは、ハードウェアを変更することなく異なる圧縮スキームをテストできることを意味する。テスト対象の圧縮スキームは、テーブル・ルックアップをベースとするものでなければならない（ディクショナリ圧縮技法）。

第５に、ソフトウェア・フローは、改変を加えることなく、標準的なコンパイル・フローに適用できるように設計されている。特に、すでにコンパイルされたコードはそのまま使用でき、すぐにコード圧縮を実行することができる。したがって、レガシー・コードにも本発明の技術を適用することができる。

第６に、本発明の技術では、未知の分岐ターゲットの問題が解決されたので、レジスタに格納されている値をターゲットアドレスとするジャンプ命令の使用が制限されるといったソフトウェア上の制限が解消された。この問題は、参考文献では十分に取り組まれていない。本発明の技術では、あらゆる適用業務に適用できる汎用ソリューションが提供される。

第７に、本発明のソフトウェア・フローでは、圧縮にとって最も重要な領域（ワーキング・セット）を特定し、パフォーマンスにおける圧縮効果を最大化できる領域に作業を集中させることができる。

A． 概要
上記の問題に対して考えられる解決策を、ここに開示する。

ａ） ソフトウェアによるケースの防止とは、このケースが発生しないようにすることを意味する。これには、様々な困難が伴う。ジャンプ・ターゲットが動的に計算される場合は、ジャンプ命令が原因となって、ジャンプ・ターゲットを静的に認識することは不可能である。この意味では、圧縮空間における命令境界は、潜在的なジャンプ・ターゲットということができる。上記ジャンプ発生による問題を防止するために、コード変換による技法を適用する場合、コード変換技法によって結果的にはコード・サイズが増大するので、オーバヘッドのペナルティが高くなりすぎる。

ただし、この方法は、ジャンプ・ターゲットが既知であるケースにはすべて適用可能である。他のすべてのケースは、実行中に（ハードウェアによって）解決されると想定される。

ｂ） ターゲットが既知のジャンプに対しては上記の方法が有効であるが、ターゲットが未知のジャンプに対しては、その問題をハードウェアの方法によって解決する必要がある。本発明で使用した他の技法は、アプリケーションのシミュレーションを実行し、コードを丁寧に調べることによって未知のターゲットを発見する、というものである。

コードを丁寧に調べることによって、これらのケースのほとんどは解決できる。我々が遭遇した問題ケースは、スイッチ文のケースである。このケースでは、シミュレーションによってターゲットを明らかにできる可能性がある。

本発明の手法の利点
本発明の2つの解決策の利点と特徴は、以下のとおりである。相違点と、その結果得られる利点の詳細な説明については、以降の節で述べる。

ａ） 圧縮解除は、オンザフライで、プロセッサに近い位置で実行される。これにより、メモリとバス帯域幅が増大するので、コード圧縮の効果がシステム全体に及ぶ。

ｂ） 本発明で述べるプラットフォーム例はアプリケーション非依存であり、2番目の解決策はISA（命令セット・アーキテクチャ）非依存である。

これにより、実質的な変更を加えることなく、多数の用途向けに適用することが可能である。

ｃ） 圧縮解除ハードウェアは、CPUの内部に侵入することなく、CPUにインタフェースする。そのため、この技術はあらゆるCPUに適応できる。これは、本発明の技術を他のハードウェア・プラットフォームに移植する場合、プロセッサと圧縮解除エンジンをつなぐインタフェース・モジュールを変更するだけでよいことを意味する。

ｄ） 前述のハードウェア／ソフトウェア・プラットフォームは、特定の圧縮に固定されない。そのため、様々なテーブル・ベースのスキームを調べることが可能である。本発明の技術では、様々な圧縮形式に対応できる十分なメモリ空間が提供される。

これは、ハードウェアを変更することなく異なる圧縮スキームをテストできることを意味する。テスト対象の圧縮スキームは、テーブル・ルックアップをベースとするものでなければならない（ディクショナリ圧縮技法）。

ｅ） ソフトウェア・フローは、改変を加えることなく、標準的なコンパイル・フローに適用できるように設計されている。特に、すでにコンパイルされたコードはそのまま使用でき、すぐにコード圧縮を実行することができる。したがって、レガシー・コードにも本発明の技術を適用することができる。

ｆ） 本発明の技術では、未知の分岐ターゲットの問題が解決されたので、レジスタに格納されている値をターゲットアドレスとするジャンプ命令の使用が制限されるといったソフトウェア上の制限が解消された。この問題は、参考文献では十分に取り組まれていない。本発明の技術では、あらゆる適用業務に適用できる汎用ソリューションが提供される。

ｇ） 本発明のソフトウェア・フローでは、圧縮にとって最も重要な領域（ワーキング・セット）を特定し、パフォーマンスにおける圧縮効果を最大化できる領域に作業を集中させることができる。

B． 圧縮アーキテクチャ
この節では、2つの方法について説明する。これらの方法は、前節で説明した障害の解決策として提案されるものである。ここでは、命令セットの命令は固定長ではないと想定する。一方、CPUは、CPU停止が発生しない限り、各サイクルにおいてメモリから固定量のビットをフェッチする。いずれの技法においても、以下の基本定義を使用する。

実行中、（下記で説明する分岐／呼び出し／ジャンプのターゲットでない限り）、CPUは非圧縮空間をポイントするアドレスを与える。これらのアドレスを、「UC」とする。UCは、メモリの正しいロケーションにアクセスできるように、圧縮アドレスにマップする必要がある。後に紹介する手法では、UCをまず特定のメモリ・ブロックにマップし、その後圧縮メモリのアドレスにマップすることとした。これは、メモリ・ブロック・テーブル（MBT）を使用することによって実現できる。

UCを対応するメモリ・ブロックに変換するだけでは十分ではない。これに加えて、そのブロック内でのUCのロケーションを特定する必要がある。このロケーションはどのバイト境界にも常駐する可能性がある。これは、オフセット・テーブル（OT）によって実行される。

UCをグループに分割する。このグループを、「UCブロック」とする。UCブロックは、連続するUCの集まりである。UCのグループ化は、アドレス変換テーブルのアドレス指定を容易にすることを目的とする。

１． 単純な手法
問題を非圧縮空間から圧縮空間に簡単にマッピングする方法として最も単純なものは、各非圧縮アドレス（ＵＣ）の圧縮アドレスを示す完全なテーブルを格納することだろう。ここで、圧縮が２５６Ｋの空間を占めるアプリケーションを例に取ろう。非圧縮アドレスが任意のバイト境界をポイントできると想定すると（Ｘｔｅｎｓａプロセッサではこれが可能である）、この空間内の各非圧縮アドレスについて、アドレスを表現するための１８ビットと、２の１８乗のロケーションから成るテーブルが必要となる。完全なテーブルであればマッピング問題を解決できるが、ほとんどの場合、これはコード圧縮の解決策としては非現実的である。

完全なテーブルを使用したマッピングは、過去に使用されたことがある。その一例は、Wolfe and Chanin（非特許文献９参照）が提唱したLAT（Line Address
Table： 表示行指示テーブル）である。このテーブルでは、非圧縮キャッシュ・ブロックのアドレスが圧縮キャッシュ・ブロックのアドレスにマッピングされる。LATスキームでは使用領域が小さく抑えられているが（32ビットのキャッシュ行の場合、約3.25%）、これは主にキャッシュ・ブロック境界でのマッピングしか行わないことによる。さらに、LATスキームは巧妙な圧縮技法を用いてそのサイズをさらに縮小する。本発明のケースでは、圧縮解除を1サイクルで行うため、非圧縮アドレスから対応する圧縮アドレスへのマッピングをすべて保持する必要がある。そのため、LATベースの手法はこのケースでは有効ではない。

以下では、精巧な変換技法とマッピング・テーブル圧縮技法を使用して、非圧縮アドレスから圧縮アドレスへのマッピングに必要なテーブルのスペースの問題を克服する方法について説明する。

２． プログラム・フロー法
ここで本発明の方法を示すにあたって、最初に、圧縮実行可能ファイルと関連のテーブルの生成過程を示すソフトウェア・フローについて説明し、次に、圧縮解除エンジンを備えるハードウェア・アーキテクチャを示すハードウェア・フローについて説明する。

ａ） ソフトウェア・フロー
プログラム・フロー法は、コード圧縮アルゴリズムの新規な手法である。その新規性は、巧妙なソフトウェア変換を用いることによって、圧縮解除エンジン内に完全なオフセット・テーブルを格納する必要性を回避するという点にある。図4は、オリジナルのアプリケーションから、圧縮実行可能ファイルとアドレス変換テーブルを生成するために使用したツール・フローを示したものである。圧縮ソフトウェアは、以下のステップを実行する。

１． データからコードを分離するステップ。このステップでは、実行可能ファイルを解析し、データ・セクションを識別し、さらに、予期しないデータ圧縮を回避するためのマーク付けを行う。

２． 膨張のステップ。このステップでは、非圧縮空間と圧縮空間の間のアドレス・マッピングを可能にするためのソフトウェア変換をコードに導入する。この変換については、下記で詳述する。

３． 統計収集のステップ。このステップでは、プログラム内での命令の出現頻度を取得するための統計収集を行う。この統計には、2個の連続する命令（すなわち、前後して出現する2個の24ビットの命令）の出現頻度も含まれる。

４． 圧縮のステップ。このステップでは、2度目のプログラム解析が実行され、ステップ3のデータ構造に含まれる命令または命令ペアの出現を検出する。出現が検出された場合は、その命令または命令ペアが圧縮バス・ワード・テーブルへの索引と置換される。可能な圧縮率は24〜16ビット（2つの連続する命令を圧縮する場合は、48〜16ビット）の範囲である。

５． 変換テーブルのステップ。このステップでは、オリジナルのプログラムと圧縮プログラムが同時解析され、非圧縮アドレスから圧縮アドレスへのアドレス・マッピングが生成される。

圧縮解除エンジンは、UCアドレスをメモリ内の圧縮キャッシュ・ブロックにマップするMBTテーブルを備える。

本発明では、キャッシュ・ブロック内でのアドレスの正確なバイト位置を「オフセット」とする。オフセットは、ソフトウェアから導出するか、jxおよびcallx命令（ジャンプ、およびレジスタ値への呼び出し）の場合は、メイン・メモリから導出する。オフセットを取り出すためのソフトウェア変換は、以下のように行われる。

１． 順次コードOffsetsは、圧縮解除履歴から導出する。圧縮解除履歴は、圧縮解除エンジンが圧縮命令サイズを追跡し、圧縮空間内の次の圧縮アドレスを計算するために使用するメカニズムである。このメカニズムは順次コードの場合は有効であるが、分岐や呼び出しを含むコードは解決できない。

以下に、コンパイル時にターゲットが既知の分岐と、コンパイル時にターゲットが未知の分岐の参考例を示す。
（１）コンパイル時にターゲットが既知の分岐の参考例
OLD CODE:
call target
NEW CODE:
.byte xx
.byte xx #
these bytes store the offset for the target
14
call target

（１）の例で、
OLD
CODE: call target
の“OLD CODE”はタイトルであり、“圧縮されていないオリジナルなコードの場合“を意味します。命令は：以下です。
call target
の意味はプロセッサに”target“アドレスから命令を実行するよう命令する、というものです。この”target”アドレスがサブルーチン実行の開始となります。このサブルーチン実行が終了すると、call命令の次命令に処理が戻ります。
EW CODE:
.byte xx
の“NEW CODE”はタイトルであり、”圧縮されたコードの場合”を意味します。
命令は：以下です。
.byte
xx
は１バイトの空のスロットを意味します。このスロットは意味のある命令を有しません。プログラムの実行中、便宜上データをおくことに使われます。
.byte xx #
these bytes store the offset for the target 14”
とあるのは.byte XXについての注釈行であり、空のスロットにターゲットのオフセットをストアすることを説明しています。ここで“14“は一例として挙げたターゲットのラベルであり、他の値であっても構いません。このようにしてオフセットをストアした後、call targetを実行することによって命令を実行させます。

（２）コンパイル時にターゲットが未知の分岐の参考例
jxやcallxなどの、コンパイル時にターゲットが未知のジャンプ命令はすべて、以下のように変換する必要がある。
OLD CODE:
jx a5
NEW CODE:
neg a5, a5
132i a5,
a5, 0
jx a5

For calls:

OLD CODE:
callx a5
NEW CODE:
neg a5, a5
132i a5,
a5, 0
.byte xx
.byte xx #
2 bytes to signal the callx and
callx a5 #
store the offset of the following instruction

（２）の例では、コンパイル時にターゲットが未知の分岐についてジャンプ、呼び出しに関して説明しています。
OLD CODE: jx a5
は上記と同様、：以下が命令です。圧縮されていないオリジナルなコードの場合、
jx a5
により、まず、レジスタa5にジャンプします。この命令によりレジスタa5に格納された値を、分岐先のアドレスとして、そのアドレスから継続して命令を実行します。
NEW CODE:
neg a5,a5
圧縮されたコードの場合、a5レジスタの値の２の補数をとり、a5を無効なターゲットアドレスとします。次に
132i
a5,a5,0
で、メモリから命令のターゲットアドレスをロードします。具体的には下記のように行います。
3番目のオペランド（この場合”0”）を２ビット左にシフトし、２番目のオペランド（この場合”a5”）のコンテンツに対する結果をロードし、これをアドレスとします。 生じた結果を第１のオペランド（この場合“a5”）に格納します。このようにして、a5は、a5におけるアドレスでポイントされたデータをうけとることができます。しかる後、
jx a5
でa5にジャンプし、目標とする正しいアドレスへのジャンプが実現します。
ターゲットが未知のサブルーチン実行命令に関しては以下のように実行します。
圧縮されていないコードの場合、
callx a5
により、レジスタa5のコンテンツを取ります。
ここでcallxはcallとほとんど同義ですが、サブルーチンが固定されたアドレスに位置づけられておらず、サブルーチンを位置づける場合、レジスタa5のコンテンツを検索することになる点が、直接サブルーチンの実行開始アドレスが明示されたcall命令とは異なります。
圧縮されたコードの場合、
neg
a5,a5
によりｊｘの場合と同様に、レジスタa5の補数をとり、
132i
a5,a5,0
によりｊｘの場合と同様に、メモリから命令のターゲットアドレスをロードします。
.byte xx
を2回実行することにより空のスロットにターゲットのオフセットをストアし、
callx a5
により、レジスタa5のコンテンツを取ります。

２．コンパイル時にターゲットが既知の分岐
変換後のコードを使用して実行可能ファイルにオフセットを格納する。
対応する命令をもたない変換後のコードは、圧縮エンジンによって検出され、ＣＰＵに送られる前にＮＯＰ（Ｎｏ Ｏｐｅｒａｔｉｏｎ）に置換される。
３．コンパイル時にターゲットが未知の分岐
ターゲットが未知のケースは、これより少し複雑である。すなわち、オフセットはメイン・メモリに格納され、ロード命令によって導出される。また、ロードの前に、ジャンプ・レジスタの値の補数をとるｎｅｇ命令を挿入して、この格納されたオフセットを無効なターゲット・アドレスにする。圧縮解除エンジンはこの無効なアドレスをトラップし（これによって、ｊｘ命令かｃａｌｌｘ命令が送られてくることが事前に分かる）、所定値をこの無効なアドレスに加算して有効なデータ・アドレス領域に移動させ、ロードの結果がバス上に出現するのを待機する。この有効なデータ・アドレスは、必要なオフセットを格納するアドレスである。圧縮解除エンジンは、オフセットを受け取ると、データ値を最初の値にする。

これにより、圧縮解除エンジンにとってオフセットが既知の状態で、正しいアドレスへのジャンプが実行される。

本発明の技術には、圧縮解除エンジンに戻りアドレスを格納するための呼び出しスタックが実装されているので、戻り命令に対して特別な処理を行う必要はない。どのケースについても、オフセットの配列は対応するアドレスと共にCPUに保持される。この配列は、ラウンド・ロビン方式で更新される。配列が満杯になると、先頭のロケーションが上書きされ、以後同様に繰り返される。

各サイクルでは、着信したucがこれらの配列にあるすべてのucと対照され、対応するオフセットが取り出される。複数のucが一致した場合、オフセットは両方のケースで同じであることを意味するので、一致したucのどちらから結果を取り出してもよい。

前節で説明したコードの位置合わせについては、本発明では以下の方式を採用する。既知のターゲットをもつジャンプや分岐ついては、対応する圧縮ターゲットの位置合わせは、CPUが常に実行を継続するのに十分な量のデータ（32ビット）を受け取ることを目標に行う。ターゲット・アドレスが未知のケース（例えば、jx命令のターゲットを追跡できない場合など）では、本発明のソリューションは、RTLシミュレーションによって実行時にそれらの位置を特定し、これをソフトウェア生成ソフトウェアに供給して、圧縮実行可能ファイルを生成させる。生成された実行可能ファイルは、実行時にのみ既知となる、新たに検出されたターゲットでの位置合わせを考慮に入れる。シミュレーションですべての潜在ターゲットが検出されないケースもあるが、ターゲットを検出できないコードについて以下に述べる手法で解決できることが実証された。実際の使用では、実行時間の前にターゲットを検出できなかったCコードは、スイッチ文のみであった。スイッチ文については、シミュレーションを実行し、入力を変更してスイッチにすべての分岐を強制実行させることによって、アセンブリ・コード内のターゲットを発見して実行可能ファイルを圧縮することが可能になる。これまでのところ、実行可能ファイル内でターゲットを追跡できないコードを生成するCコードは、上記以外には見つかっていない。

ｂ） 本発明による圧縮法を実装したハードウェアの例
図5はアーキテクチャを示し、図6は圧縮解除エンジンおよびインタフェースのUCアドレス・マッピングのためのハードウェア構成を示すブロック図を示す。図5では、PIF（プロセッサ・インタフェース）、キャッシュ、またはタグから送られてくる信号が、DCE（圧縮解除エンジン）によって傍受され、CPUが圧縮コードの存在を認識しないように変更される。このインタフェースは、圧縮解除コアから分離できること、そして、異なるプラットフォーム上で動作できるように変更できること、の2点を念頭に設計されている。

次に、図6に示すアドレス・マッピングについて詳細に説明する。本発明の実装には、以下の制約条件が伴う。

拡張ワーキング・セット（EWS）：プラットフォームは、どんなサイズのアプリケーションでも処理できる。ただし、圧縮領域は、256KB以下の、連続する空間でなければならない。この空間では、圧縮が望ましくない領域については圧縮しないままにしておくことができる。本発明では、この256Kの空間を「拡張ワーキング・セット」とする。

UCブロック・サイズ：本発明におけるUCブロックは、長さ256バイトである。

キャッシュ・ブロックサイズ：本発明で使用するキャッシュラインは、32バイトである。ただし、アーキテクチャには、上記以外のキャッシュ・ブロック・サイズでも処理できる柔軟性がある。

拡張ワーキング・セットEWSとキャッシュ・ブロック・サイズから、メモリ・ブロック番号には13ビットが必要であると判断できる。また、8個のセパレータが必要であると判断できる。したがって、メモリのサイズが1K×18の場合には、各々2個のセパレータを保持する4個のメモリが必要となる。UCブロック・サイズは256バイトなので、セパレータ1個につき8ビットが必要である。図6は、このアーキテクチャのブロック図を示したものである。本発明では、2個のレジスタも導入している。これらは、圧縮メモリ内の圧縮コードの開始点となる圧縮メモリ開始点（CMB）と、非圧縮メモリ内の圧縮コードの開始点となる非圧縮メモリ開始点（UMB）を格納するレジスタである。UMBは、UCが圧縮メモリ空間内に存在するかどうか（すなわち、アドレス変換を実行すべきかどうか）をチェックするために使用される。CMBは、アドレス変換論理の13ビット出力と結合させる最終アドレスを形成するために使用される。この機能を実行するのは、図の最上部にあるコンパレータである。コンパレータは、UCがUMB内に存在するかどうかをチェックし、存在する場合は、CMBから適切な埋め込みビットを出力する。存在しない場合は、単に元のUC値を出力する。True／Falseラインは、アドレス埋め込み装置に対して、元のUCを使用すべきか、あるいはCMBビットにアドレス変換の出力を埋め込むべきか（結合が必要かどうか）を知らせるために使用される。

アドレスを示したテーブルから送られてくる１３ビットには、メモリ内の圧縮コードのロケーションに応じた適切なビットを埋め込んで、完全な３２ビット・アドレスを形成しなければならない。さらに、圧縮解除履歴オフセットがＬＳＢ部に連結される。そのため、キャッシュ／メモリ用の完全な３２ビット・アドレスを形成するためには、ＭＳＢ側に埋め込むための１５ビットと、ＬＳＢ側に埋め込むための５ビットが必要である。

この手法の主な利点は、アーキテクチャ上のキャッシュ・サイズから完全に独立していることである。以下に示すいくつかのレジスタを使用して、システムの汎用性を最大限に高めることもできる。

メモリ・ブロック・テーブル内のビット数を保持するレジスタ。上記の例では、このビット数の値は１２である。

テーブルのエントリ当たり最大２８ビットのセパレータを格納する、セパレータ・マスク・レジスタ。

セパレータ・テーブル内のセパレータ数を格納するレジスタ。

Ｘｔｅｎｓａプロセッサを使用した実装では、ＦＰＧＡボード上のゲート数は９０，０００個であり、３０Ｍｈｚで動作する。

以前の実験では、1.2倍の向上が可能なことが実証されている。

３． ワード・ベースの圧縮
これは、前節で提示した問題のすべてを、圧縮率を犠牲にして解決する解決策である。これは特に、命令サイズが命令バス幅と等しくない場合に有効である。この解決策の主なコンセプトは、バス・ワード全体を、そのバス・ワードに含まれる命令には関係なく圧縮する、というものである。本発明の実装では、2個の連続する32ビット・ワードが1個の32ビット・ワードに圧縮され、可能な場合は常にバス上に2倍の情報が送信される。ここでは、命令そのものは考慮されず、また32ビット・ワードのいずれかのバイト位置に位置合わせされた命令が含まれている可能性がある。そのため、圧縮率はあまり高くないが、圧縮解除ハードウェアは大幅に簡素化される。この方法について、最初にソフトウェア側に焦点を当て、次にハードウェア側に当てて説明する。

ａ） ソフトウェア・フロー
圧縮ソフトウェアは、以下のステップを実行する。

１． データからコードを分離するステップ。このステップでは、実行可能ファイルを解析し、データ・セクションを識別し、さらに、予期しないデータ圧縮を回避するためのマーク付けを行う。

２． 統計収集のステップ。このステップでは、プログラム内での３２ビット・ワードの出現頻度に関する統計を収集する。命令は考慮されず、全語のみを対象とする。全語は複数の命令で構成されることもある（Xtensa ISAの場合は最大2命令）。この統計には、ダブル（すなわち、前後して出現する32ビット・ワード）の出現頻度も含まれる。ダブルの出現頻度は、次の圧縮ステップで使用される。すべてのダブルは出現頻度に基づいて並べ替えられる。上位1024個がデータ構造に格納され、これが圧縮バス・ワード・テーブルになる。

３． 圧縮のステップ。このステップでは、2度目のプログラム解析が実行され、ステップ2のデータ構造に含まれるダブルの出現が検出される。出現が検出された場合は、そのダブルが圧縮バス・ワード・テーブル（３２ビット幅、以下参照）への索引と置換される。これにより、可能な場合は常に、64ビットから32ビットへの圧縮が実現される。

４． マッピング・テーブルのステップ。このステップでは、オリジナルのプログラムと圧縮プログラムが同時解析され、非圧縮アドレスから圧縮アドレスへのアドレス・マッピングが生成される。

プログラム・フロー法とは異なり、ワード・ベースの圧縮では、圧縮前にソフトウェアを変更する必要はない。

そのため、プログラム・フロー法に比較してはるかに単純であり、コンパイル・フローに干渉することなく、実行可能ファイルに対して直接作業することができる。

ｂ） 本発明によるワード・ベースの圧縮法を実装したハードウェアの例
この節では、ワード・ベース圧縮法のハードウェア実装について説明する。この方法では、「単純な手法」の節で説明した方法と同様に、非圧縮アドレスから圧縮アドレスへの完全なマップが使用される。ただし、この方法は、圧縮技法を使用して変換テーブルのサイズを縮小する点において単純な手法とは異なる。また、ＥＷＳサイズに対する制約条件も追加し、現在では６４ＫＢを上限としている。さらに、ＣＰＵのプログラム・カウンタ（ｕｃ）を、圧縮空間内のワードへの索引付けに使用されるｃｐｃに変換するマッピング・テーブルのステップについては、圧縮解除エンジン内にこれら２ポインタ間の完全なマッピングを格納することで対処することとした。このマッピングは、ｕｃを受け取って圧縮メモリ・キャッシュ・ブロックのアドレスを提示する、メモリ・ブロック・テーブルで構成される。正確なオフセットは、「オフセット・ツリー」と呼ばれる構造から取得される。ここで、このマッピング構造について詳細に説明する。ＵＣ空間は、６４バイトのブロックに分割される。各６４バイト・ブロックは、ＵＣブロック内の先頭ＵＣアドレスに対応するキャッシュ・ブロックにマップされる。残りのアドレスは、このキャッシュ・ブロックか、次のキャッシュ・ブロックか、さらにその次のキャッシュ・ブロックのいずれかに属することができる。換言すれば、１個のＵＣブロックには最大３個のキャッシュ・ブロックが存在する、ということになる。ＭＢＴテーブルには、このうち先頭のキャッシュ・ブロックだけが格納される。残り２個のキャッシュ・ブロックに含まれるアドレスは、「セパレータ・テーブル」（ＳＥＰ）と呼ばれる２つのテーブルから導出される。これらのＳＥＰには、２個のキャッシュ・ブロックアドレスを取り出すための、ＭＢＴ内の開始アドレスからのオフセットが格納される。６４バイトのＵＣブロックは、これに加えて最大２個のキャッシュ・ブロックにまたがるので、各々別個のテーブルに格納される２個のセパレータが必要となる。ＭＢＴテーブルとＳＥＰテーブルを使うと、現在のＵＣが位置する正確なキャッシュ・ブロックを取り出すことができる。図７は、ＵＣからメモリ・ブロック番号への変換を示したものである。

キャッシュ・ブロック内の正確なバイト位置は、オフセット・テーブルから取り出される。これらのオフセット・テーブルは、オフセット・ツリーと呼ばれる構造を使ってコンパクト化が図られている。オフセット・ツリーは、各64バイト・ブロックから計算される。各64バイト・ブロックは、2個の17ビット・オフセット・ツリーを必要とする。図8に、ツリー構造を示す。この主なコンセプトは、すべてのワードはそのままの形で維持されるか、あるいは次のワードと結合されて非圧縮／圧縮32ビット・ワードを形成する、という事実を利用したものである。そのため、このツリーから、キャッシュ・ブロックの先頭を開始点とする、UCアドレスとして可能な位置を得ることができる。

圧縮キャッシュ・ブロック内の最初のワードに対応するUCアドレスを例に取る。このUCアドレスは、圧縮キャッシュ・ブロックの開始位置からのみ開始できる。したがって、図8では0-0行となる。図内における各行について示す最後の番号は、各UCの位置の曖昧性を符号化するために必要とされるビット数を示す。2番目のUCワード（図内の第2行を参照）の位置を決定する場合、このワードは、位置2（最初のワード内に圧縮がある場合）、または位置4（最初のワード内に圧縮がない場合）のいずれかに位置する。このように、可能な位置は2個あるので、これらの位置を符号化するためには、ツリーの第2行に示されるように1ビットが必要となる。以後同様にして、図8に示すツリーを作成する。これにより、圧縮キャッシュ・ブロック内におけるUCワード全8個の位置を符号化するための合計サイズとして、17ビットが得られる。

この方法では、UCからCPCアドレスへの完全なマッピングを提供し、さらに、圧縮を命令レベルではなくバス・ワード・レベルで発生させることにより、コード配置の問題が解決されることに留意されたい。

上記の構造は、32ビット命令バスの基本仮定を除けば、命令セットの設計やアーキテクチャの詳細に依存しない。本発明の技法の有効性を実証するため、Xtensaプロセッサ上で命令符号化の実験を行った。図9は、2個の非圧縮32ビット・ワードを圧縮して得た、1個の圧縮32ビット・ワードを示す。ここでは、Xtensa命令では、LSB側の4ビットに対してビット・コンビネーション「1110」は決して使用されない、という事実を利用している。命令はどのバイト境界からでも開始できるので、圧縮ワードを符号化する際には、それが圧縮ワードであることを示すフラグとして、そのワード内のすべてのバイトにビット「1110」を格納するよう選択せざるを得ない。すべてのバイトにビット「1110」を配置せざるを得ないのは、正規のXtensa命令には、LSBの4ビットを除くすべての位置にビット「1110」が含まれからである。図8に示すように、圧縮ディクショナリへの索引付け用として使用可能なビットとして、まだ16ビットが残っている。

この実験により、ワード・ベースの圧縮を行うと、圧縮を行わないシステムに比較して最大１．４倍のパフォーマンス向上が得られることが実証された。パフォーマンス向上の度合いは、アプリケーションと選択するキャッシュ・サイズによって異なると思われる。本発明を実装した圧縮解除エンジンの例では、ＦＰＧＡボード上のゲート数は１５，０００個で、動作速度は３３ＭＨｚである。

C． 結論
本発明は、多様なコード圧縮技法の高速プロトタイピングと評価を可能にするハードウェア／ソフトウェア・プラットフォームを提供する。現代のほとんどの命令セット・アーキテクチャにおいては、1サイクル内でコードの圧縮解除を完了することが要求される。本発明では、こうした要件を満たすため、a）プログラム・フロー法、および、b）ワード・ベース圧縮／圧縮解除、という2つの手法を明確に示した。

どちらの手法が有効かは、（a）命令セット・アーキテクチャ、（b）ゲート数に基づくプロセッサの規模（圧縮解除アーキテクチャの実装に費やされる労力は異なるため、SOCの領域効率を十分に確保するためには、プロセッサの規模を超えないようにする必要がある）、（c）プロセッサ設計のラテンシ（クリティカル・パス。これによって、1サイクル内で圧縮解除を処理できるだけのスラック・タイム（遊び時間）があるかどうかが決まる）、および（d）コード圧縮を使用する主な目的（メモリ・サイズの削減、パフォーマンスの向上など）、という4つの要因によって決まる。さらに、本発明のハードウェア／ソフトウェア・プラットフォームは柔軟性に優れるため、選択した手法に応じて、異なるパラメータを検討することが可能である。

前述の開示および教示から、他の変更および変形が可能なことは当該技術に精通する当業者には明らかであろう。したがって、本書では本発明のごく一部の実施例のみが特に説明されているが、本発明の精神および範囲から逸脱することなく多数の変更が可能であることは明らかである。

オンザフライでのコード圧縮の原理を示す図である。 複数層から成る階層を備えるシステム上でのコード圧縮における、プリキャッシュ・アーキテクチャとポストキャッシュ・アーキテクチャの使用量を示す。 （ａ）はデータ・バス1上のトグル数、（ｂ）はデータ・バス2上のトグル数、（ｃ）は個々のトグル数の合計を示す図である。 本発明の教示における一態様によるコード圧縮をサポートするソフトウェア・プラットフォームのフロー例を示す図である。 本発明の一態様によるシステムの構成例を示すブロック図である。 アドレス・ルックアップの構成例を示すブロック図である。 非圧縮アドレスからメモリ・ブロック番号への変換を示す図である。 テーブルの索引付けを示す図である。 圧縮ワードの構造例を示す図である。

Claims (3)

1. プログラムのコード圧縮のための方法であって、当該方法は下記ステップを備える。
   ａ） データからコードを分離するステップ。
   ｂ） 圧縮空間と非圧縮空間の間でアドレス・マッピングを行うためのソフトウェア変換をコードに導入するステップ。
   ｃ） 命令の出現頻度に関する統計を取得するステップであって、前記統計には2個の連続する命令の出現頻度も含まれる。
   ｄ） ステップ（c）に含まれる命令または命令ペアの出現を識別するために、プログラムを解析する。
   ｅ） ステップ（d）で識別された前記命令または前記命令ペアを、前後して出現する命令を出現頻度に基づいて並べ替えて格納した圧縮バス・ワード・テーブルを示すアドレスと置換する。
   ｆ） 非圧縮アドレスから圧縮アドレスへのアドレス・マッピングを生成する。
2. プログラムのコード圧縮のための方法であって、当該方法は下記ステップを備える。
   ａ） データからコードを分離するステップ。
   ｂ） 圧縮空間と非圧縮空間の間でアドレス・マッピングを行うためのソフトウェア変換をコードに導入するステップ。
   ｃ） ワードの出現頻度に関する統計を取得するステップであって、前記統計には2個の連続するワードの出現頻度も含まれる。
   ｄ） ステップ（c）に含まれるワードまたはワード・ペアの出現を識別するために、プログラムを解析する。
   ｅ） ステップ（d）で識別された前記ワードまたは前記ワード・ペアを、前後して出現するビット・ワードを出現頻度に基づいて並べ替えて格納した圧縮バス・ワード・テーブルを示すアドレスと置換する。
   ｆ） 非圧縮アドレスから圧縮アドレスへのアドレス・マッピングを生成する。
3. プログラムのコード圧縮のためのシステムであって、
   プロセッサ・インタフェースと、キャッシュと、タグと、外部SRAMと、圧縮解除エンジンとを備え、さらに
   データからコードを分離する手段と、
   圧縮空間と非圧縮空間の間でアドレス・マッピングを行うためのソフトウェア変換をコードに導入する手段と、
   2個の連続する命令の出現頻度を含む命令の出現頻度に関する統計を取得する手段と、
   取得された前記統計に含まれる命令または命令ペアの出現を識別するために、プログラムを解析する手段と、
   識別された前記命令または前記命令ペアを、前後して出現する命令を出現頻度に基づいて並べ替えて格納した圧縮バス・ワード・テーブルを示すアドレスと置換する手段と、
   非圧縮アドレスから圧縮アドレスへのアドレス・マッピングを生成する手段を有することを特徴とするコード圧縮システム。

Images