a21_hlx002 のバックアップ(No.3)

バックアップ一覧
差分を表示
現在との差分を表示
ソースを表示
a21_hlx002 へ行く。
- 1 (2021-09-06 (月) 15:01:00)
- 2 (2021-09-06 (月) 15:40:17)
- 3 (2021-09-06 (月) 22:01:43)
- 4 (2021-09-06 (月) 22:51:38)
- 5 (2021-09-06 (月) 22:51:38)
- 6 (2021-09-07 (火) 13:27:11)
- 7 (2021-09-07 (火) 20:18:05)
- 8 (2021-09-08 (水) 06:23:22)

HLX-002

(by K, 2021.09.06)

↑

(0)

HLXは、a21_txt01やその続編で作ったHLシリーズ（はりぼて言語）をベースに、Kが望む理想の言語を作るプロジェクトです。
- 中・長期の目標はa21_hlx000に書いてあります。
HLX-002はその2番目のバージョンです。まあHL-24みたいなものです。
- a21_hlx001 : 最初のバージョン

↑

(1) 概要

HLX-001は、HL-9a, HL-16b, HL-22bの3つを統合し、さらに改良を加えたものです。
- ということで「できること」はこれら3つと同じです。
統合されているので、モードを切り替えて使います。
- [codemode 0] HL-9a相当の実行モードで、JITコンパイルせずに中間コードを実行します。x86, x64以外でも（ソースからHLX-001をコンパイルすれば）動くはずです。
- [codemode 1] HL-16b相当の実行モードで、x86の32bitの機械語をJITコンパイラで生成します。
- [codemode 2] HL-22b相当の実行モードで、x64の64bitの機械語をJITコンパイラで生成します（MS-Windows系のABI）。
- [codemode 3] HL-22b相当の実行モードで、x64の64bitの機械語をJITコンパイラで生成します（System V系のABI）。

[Q]そもそもなぜ3つを統合する必要があるの？
- [A]HLシリーズを拡張していくにあたって、それぞれの改造を3つのバージョンに別々に適用していくのは大変なので、まず1つに統合して、それから拡張していきたかったのです。
- さらに統合することで、3つを別々に持つよりもコンパクトにできるのではないかと考えています。
- あと、これ一つであれもこれもできる！っていうのが好きなんです（笑）。

http://k.osask.jp/files/hlx002a.zip (98.2KB) [最新版]
- [内容]
- hlx002_x86_win.exe : 32bit版の実行ファイル(45.5KB)
- hlx002_x64_win.exe : 64bit版の実行ファイル(60.0KB)
- mandel.cなどのサンプルプログラム
- sub_x86_win.obj, sub_x64_win.obj : どちらもアプリをコンパイルして実行ファイルを作る場合のみに必要なオブジェクトファイルです
- hlx002src/
  - hlx002.c (1065行) - ソースコードから共通中間コードに変換
  - esvm.c (864行) - 共通中間コードを最適化する
  - esvm_run.c (200行) - 共通中間コードをインタプリタで実行
  - esvm_x864.c (1289行) - 共通中間コードをx86/x64の機械語に変換

↑

(2) 特徴（なにがすごいのか） →「こんなに小さくても、結構いろいろできる！」

[1]処理系の小ささ
- HL-9a, HL-16b, HL-22bの3つは以下のようになっていました。それらに対し、こんなにコンパクトにまとまっています。
  ソース行数 .exeのサイズ
  HL-9a 772行 20.0KB
  HL-16b 1287行 28.5KB
  HL-22b 1440行 45.5KB
  (合計) (3499行) (94.0KB)
  HLX-001a 2993行 40.0KB アセンブラ出力ができません
  HLX-002a 3418行 45.5KB
- あれ？ソース行数的には、それほどコンパクトでもないな・・・。
- まあでも実行ファイル的には明らかにコンパクトになっています。
- 上記3つは似たような部分が多いため、1つにまとめることで共通な部分が省かれて、このような結果になっています。

アプリケーションのJIT結果の違い（参考）

	(1) x86, 速度優先	(2) x86, サイズ優先	(3) x64_win, 速度優先	(4) x64_win, サイズ優先
grd.c	116	120	169	174
mandel.c	602	408	628	485
maze.c	1383	957	1438	1161
kcube.c	3360	2020	3735	2715
invader.c	1845	1324	1926	1520

これらの結果は「codemode 1」にすれば簡単に確認できます。言語処理系がx86版でもx64版でも同じ結果になります。
(1) → codemode 1; optmode 0;
(2) → codemode 1; optmode 1;
(3) → codemode 2; optmode 0;
(4) → codemode 2; optmode 1;
(註) grd.cではサイズ優先のほうがむしろ大きくなってしまっていますが、これは書き間違いではなく、grd.cのような極端に小さなプログラムでは、最適化方針の違いがうまく結果と連動していないというだけです。

↑

(3) 普通のコンパイラとしての使い方（JITコンパイラではなく）

例としてgrd.cから.exeを作るまでの手順はこうです。

prompt>hlx002_x86_win -asm grd.c > grd_x86_win.nas
prompt>nasm -f win32 -o grd_x86_win.obj grd_x86_win.nas
prompt>gcc -Wl,-s -o grd_x86_win.exe grd_x86_win.obj sub_x86_win.obj -lgdi32
これで「grd_x86_win.exe」ができあがります！

上記のx86をx64にことごとく読み替えて、nasmにも「-f win64」すれば、x64版ができます。

また、hlx002_x86_winやhlx002_x64_winは、設定を変えるだけでクロスコンパイラとしても機能します。

prompt>hlx002_x64_win -asm "-cmd:codemode 1" grd.c > grd_x86_win.nas
prompt>hlx002_x86_win -asm "-cmd:codemode 2" grd.c > grd_x64_win.nas

おまけのメモ
- 上記で使うsub_x86_win.objやsub_x64_win.objは次の方法で作りました（すでに作ったものがアーカイブに含まれています）。
- 真似をすれば他の環境用にも作れるのではないかと思います。
- 以下の2つのgccはそれぞれx86用とx64用のMinGWを使っているので、同じものではありません（gccはHLX-002のように1つのコンパイラで複数のアーキテクチャに対応したりはしないので）。
```
prompt>gcc -m32 -Wno-unused-function -O3 -I (acl-winへのパス) -c -DAARCH_X86 -o sub_x86_win.obj sub.c

prompt>gcc -m64 -Wno-unused-function -O3 -I (acl-winへのパス) -c -DAARCH_X64 -o sub_x64_win.obj sub.c
```

↑

こめんと欄

コメント	お名前	NameLink

	ソース行数	.exeのサイズ
HL-9a	772行	20.0KB
HL-16b	1287行	28.5KB
HL-22b	1440行	45.5KB
(合計)	(3499行)	(94.0KB)

HLX-001a	2993行	40.0KB	アセンブラ出力ができません
HLX-002a	3418行	45.5KB