tek​/rjc のバックアップソース(No.1) :: OSASK計画

• 差分^[1] を表示
• 現在との差分^[2] を表示
• tek/rjc^[3] へ行く。

* tek圧縮でよく使われるrjcについて
-(by [[K]], 2008.12.09)
*** (0)
-まずは祝tek普及～！・・・NWSOSの開発が再開されてしかもtek圧縮を採用する予定らしいことをIRCで教えてもらいました。とてもうれしいです。OSASK発祥の圧縮文化は少しずつですが着実に認められて浸透しているようです。
-（2008.12.09時点での）普及リスト：
--旧OSASK、OSASK-HB
--Susieプラグイン
--sarアーカイブ
--「はりぼてOS」およびその発展型OS
--MonaOSでのtek5圧縮のアプリ
--おれんじぺこでのtek1圧縮のアプリ、おれんじぺこでのtek1/tek2/tek5展開APIの採用
--NWSOSでのOS本体のtek5圧縮（予定）
*** (1)
-さてそのtek圧縮ですが、実はOSASK以外のOSではtek圧縮だけを普通に使っているだけです。データファイルは確かにこれで問題ないんです。しかし新旧のOSASKアプリでは当然のようにrjcというフィルタも併用していて、これが圧縮率を高めるのに大いに寄与しています。これじゃあOSASKアプリとサイズ比較するときにOSASKばかりが有利になってしまってずるいと思います。
-またrjcに相当するフィルタは、LZMA(7z)やUPXでも当然のように利用されていて、rjcを使わないtek5とこれらを比較すると場合によっては圧縮率で逆転します。それじゃあtek5の実力が誤解されかねません。それは僕としては不本意です。
-rjcを使わずにtek5した場合と、rjcしてからtek5した場合のサイズの差は、たいてい1割前後です。この差はかなり大きいです。tek5の改良だけで（たいした速度低下もなく）1割も圧縮率を改善するというのはほぼ不可能といっていいレベルだと思います。
-rjcは極めて処理時間が短く、コードもとても小さい簡単なフィルタです。処理内容を簡単に説明するとIA-32のコードは相対ジャンプ命令（near-callも該当）が中心で、同じオフセットへのジャンプであってもそれぞれ違う機械語になっています。つまり同じ場所へのジャンプ命令であるにもかかわらず、それは何度出てきても初出の命令列になり、スライド辞書圧縮がほとんどききません。こういうコードはIA-32の一般的なプログラムでは頻出するので、これをrjcエンコードフィルタによってスライド辞書法が適用しやすい形式に変換してから圧縮してやろうというわけです。また展開時には通常のtek展開の後にrjcのデコードフィルタをかけることで、展開処理を完了します。
*** (2)

* こめんと欄
#comment

• tek/rjc のバックアップ一覧^[5]
• tek/rjc のバックアップソース(No. All)
  • 1: 2008-12-09 (火) 14:24:46
  • 2: 2008-12-09 (火) 14:47:59^[6]
  • 3: 2008-12-09 (火) 18:01:33^[7]
  • 4: 2008-12-09 (火) 18:01:33^[8]
  • 5: 2008-12-09 (火) 18:01:33^[9]
  • 6: 2009-11-17 (火) 12:07:32^[10]
  • 現: 2024-01-08 (月) 12:59:03^[11] k-tan^[12]