GO (じーおー) †
- IA-32用の汎用gcc。gcc-3.2をベースにしていて、IA-32のOSであれば、すぐに移植可能になっている。アセンブラとライブラリアンも含まれる。
- OSASKのサブプロジェクトです。
- 実績：OSASKのmakeに使われています。
- OS依存するのはファイル関係の4関数のみ
- 現在、win32版とOSASK版とstdc版がある
- win32版GOはMinGWと思いっきりかぶりますが、処理系がMinGWよりもコンパクトで、出力されるバイナリもMinGWよりも若干コンパクト＆若干高速です。
- ついでにGOのsjisconvを併用すればSJISでも細工なしでコンパイルできます。
- stdc(gcc)版は、<stdio.h>、<stdlib.h>しか利用しないバージョンです。主にLinux版GOを作る場合に使われています。gcc-3.2でないとコンパイルできないので注意が必要です（そもそもGOはGO自身でコンパイルすることしか想定していなかったので）。
- stdc版で利用している関数：fopen, fclose, fread, fwrite, fseek, ftell, malloc, exitのみ
- projectsのみなさんからのご要望があればそれぞれのOSの対応版を作って差し上げられると思います
- GOは以下のコンポーネントから構成されている（サイズはそのコンパクトさの程度の参考のために挙げてある -- win32版のサイズ）
| 名前 | 内容 | サイズ | win32版 | stdc版 | OSASK版 | | cpp0 | プリプロセッサ | 37.5KB | ○ | ○ | × | | cc1 | C言語コンパイラ(含プリプロセッサ) | 851KB | ○ | ○ | ○ | | cc1plus | C++言語コンパイラ(含プリプロセッサ) | 1025KB | ○ | ○ | × | | gas2nask | cc1などが出力するソースをNASM形式に変換する | 7.00KB | ○ | ○ | ○ | | nask | NASM風文法のアセンブラ 最適化能力においてNASMを大きく上回る | 27.0KB | ○ | ○ | ○ | | obj2bim | COFF用の汎用リンカ この出力ファイルに各種ヘッダなどを付けて、各OSの実行ファイルなどになる | 7.53KB | △ | △ | ○ | | golib | ライブラリアン （簡易版ではなく、機能は十分です） | 4.50KB | ○ | ○ | × | | sjisconv | ShiftJISやその他の文字コードで書かれたソースをGOでコンパイル可能にするためのプリプリプロセッサ | 2.50KB | ○ | ○ | ○ | | naskconv | ASKAが出力したソースをnask形式に変換する | 3.50KB | ○ | ○ | × |
- ○：対応版あり、×：対応版なし、△：対応版があるがGOのパッケージ外になっている
- cpp0, cc1, cc1plusはGPL、そのほかはKL-01でライセンスされている
- win32版はMinGWのライブラリやgcc.exeなどと組み合わせて使用可能
- naskのやや詳しい説明 → GO/nask
- NASMとnaskの違い：
- NASMの文法のほとんどを採用しつつ、処理系を一から作ったアセンブラがnaskです。しかし完全下位互換ではない部分もあります。
- 今のところ、naskにNASMのマクロ機能は全くありません。NASMのプリプロセッサ機能を使った出力をnaskにかけることで多くの場合では解決できるでしょう。naskはバックエンド用として開発されてきたため、マクロ機能はとりあえず不要と考えたのです。
- naskはNASMと比べるとラベル解決能力や自動で最適なコードを出す能力が大きくまさっています。
- NASMは実に多彩な出力が可能ですが、naskはBINとCOFF（実際はwin32-COFF）の出力しかありません。また残念ながらNASMには自動最適化機能がないので、アセンブラの用途としては最大の、バックエンド用途にはほとんど使い物になりません。
- まとめるとNASMは多機能（特にマクロの強さはアセンブラ界では最高のものだと思います）で、naskは高性能（最適化性能は並みの水準ですが、それを27.0KBにしたという意味ではやはり高性能でしょう）なのです。
- 註：naskのサイズがNASMより格段に小さいことは事実ですが、それを理由にnaskが高性能だというのではなく、IA-32用のアセンブラとしてnaskより小さいものが他に見当たらないという意味で高性能だとしています（naskが出るまでCOFF対応IA-32アセンブラとして世界最小の座にあったFASMでさえ54.5KBだそうです）。
ダウンロード †
IA-32用のOSに依存しないライブラリ †
| float.h | | | limits.h | | | sin() (math.h) | | | cos() (math.h) | | | sqrt() (math.h) | | | ldexp() (math.h) | | | frexp() (math.h) | | | setjmp() (setjmp.h) | (マクロ) | | longjmp() (setjmp.h) | 1しか返せない (マクロ) | | va_start() (stdarg.h) | (マクロ) | | va_end (stdarg.h) | | | va_arg (stdarg.h) | | | va_copy() (stdarg.h) | (マクロ) | | va_list (stdarg.h) | | | stddef.h | size_tの宣言しかない | | sprintf() (stdio.h) | %dと%sしかできない | | vsprintf() (stdio.h) | %dと%sしかできない | | abs() (stdlib.h) | | | atoi() (stdlib.h) | | | qsort() (stdlib.h) | | | rand() (stdlib.h) | | | strtol() (stdlib.h) | | | strtoul() (stdlib.h) | | | string.h | これは一通りある |
こめんと欄 †
- 将来的にはASKAもGOに含ませたいと考えています。 -- K 2003-06-27 (金) 20:15:48
- とりあえずこのページをGOのホームページにしてしまおうと画策中。 -- K 2003-07-04 (金) 13:15:56
- ASKAもGOにとは楽しみです。ところでNASKは, 非互換な部分もあって ([global ], [extern ]ディレクティブとか) NASMの高性能版と言うのはどうかと思います。 -- I.Tak.? 2003-07-04 (金) 13:33:54
- いえてますね。incbinもできないし、マクロも使えないままだし。・・・ということで直しました。 -- K 2003-07-04 (金) 13:45:54
- でも、NASMで[global ]や[extern ]を書いてもOKじゃありませんでしたっけ？＞I.Tak.さん -- K 2003-07-04 (金) 13:59:53
- いや, 例えば global hoge rage はNASMだとマクロで, [global hoge]がprimitive directiveなんですが, NASKはそうじゃないんですよね。[global hoge]がエラーになって, global hoge にしないといけない。ハタシテNASMと同系列なのだろうかと。そういうつっこみです (同系列で高性能か高機能かというのではなく)。 -- I.Tak.? 2003-07-04 (金) 14:01:43
- なるほど。そう言われるとそうですね。単にソースの文法が近いだけで、naskはNASMの系列ではないですね。・・・ということで直しました。 -- K 2003-07-04 (金) 14:06:53
- 『最適化性能は並みの水準ですが、それを27.0KBにしたという意味ではやはり高性能でしょう』←「最適化が並」なら性能は並では？ NASMの方が多機能でしたらサイズが大きくなるの明らかで。それをサイズが大きいから高性能というのはオカシイかと。。。性能はサイズですか？ -- 名無しさん 2004-10-28 (木) 10:11:30
- 1.NASMの自動最適化能力は標準未満です（NASM以外でこれほどの仕様が見当たらないくらいのひどさです）。 2.言語処理系に対する機能というのは、サポートできる言語仕様の多様さや、「出力される」コードの質をさしていると考えます（最適化能力も含む）。 3.一方、言語処理系に対する性能というのは、コンパイル時間（アセンブル時間）の短さや、「処理系自身が」コンパクトであるかどうかだと思います。 -- K 2004-10-28 (木) 11:37:42
- 世間一般の語の用法としては、機能と性能をごちゃまぜで論じる場合もあり、そのときは多機能であることは高性能であるとしているようです。しかし機能と性能をちゃんと別々に分けて論じる場合は、上記の解釈が一般であると思われます。出力結果を直接左右する要因のすべては機能に分類され、出力結果を直接左右しない要因のすべては性能に分類されると思います。 -- K 2004-10-28 (木) 11:44:04
- 多機能ならサイズが大きくなるのは確かにあたりまえです。しかし単純に機能さえ増えればサイズがどれだけ大きくても許されるというものではないでしょう。これは結局、機能とサイズの比率が重要になると思われます。そういうことをすべて考慮した上で、「高性能」であるとしています。 -- K 2004-10-28 (木) 11:53:56
- 「最適化が並」について。世間一般のアセンブラの最適化能力はアセンブラとしての理論上の最高水準に達しており、これを超える最適化はアセンブラであることをやめない限り不可能です。だからこれが並であることは最高であることも意味します。この点に関しては、NASMがひどいだけです。 -- K 2004-10-28 (木) 11:58:52
- 『サイズが小さいから高性能だぜ！』と読み取れたのですが、出力されるオブジェクトの品質がNASMよりも優れているということですね。 -- 名無しさん 2004-10-28 (木) 14:03:52
- 誤解しているかもしれないので一応補足： （機能の割には）サイズが小さいから高性能なんです。サイズは性能の一つです。自動最適化はnaskの機能に関する話であって性能とは関係ないです。 なお自動最適化については上の説明に最初から書いてあったので、結局何が疑問だったのかも不明です。ただの読み落しだったのでしょうか。 -- K 2004-10-28 (木) 15:01:31
- 単純に今時、同等の機能を有していないモノとの比較で１バイトでも小さいから高性能だという変わった人もいるもんだなと思っただけです。 -- 名無しさん 2004-10-29 (金) 14:57:06
- naskのサイズに関する説明を追記しました。 -- K 2004-10-29 (金) 16:45:17
- cc1 に -I オプションを複数付けると、二つ目以降を無視してしまうようです。直接の原因はappend_include_chain(cppinit.c)内でinoとdevの初期化を#if 0してしまった事だと思います。 -- wq 2006-04-16 (日) 00:01:06
- サイズと性能は、直接結びつかないため疑問が出るわけです。「サイズが小さいけど高性能」ならわかります。性能を示すなら、同じ出力タイプでの処理速度と品質でしょうね。 -- 名無しさん 2006-08-30 (水) 15:59:09
- win32版GOをDLさせてもらったところうちのアンチウィルスソフト(kaspersky)がnask.exeをトロイとして認識したんですが…不安になったので削除しました。 -- 名無しさん 2007-08-27 (月) 02:34:57
- うちもカスペル先生にダメされました。 -- 名無しさん 2007-09-26 (水) 16:15:05
- ↑KasperskyでTrojan-PSW.Win32.Agent.kvとして誤検出されました。自分の経験ではまったく別のexeでもまったく同じ名前で誤検出された記憶があるので、該当ウィルス定義ファイルの実装に問題があるんじゃないかと。許可してかまわないと思います。 -- OK 2007-10-02 (火) 19:41:34
- 管理者さんへ：ダウンロードするファイルへのリンクをクリックすると、ウイルスサイトへ飛ばされますが…。元のリンクに戻していただけますか？ -- takafumi 2007-12-23 (日) 06:01:31
- 直しておきました。 -- Zakky 2007-12-25 (火) 13:21:07
- naskがカスペル先生にダメだしされる問題は、いつの間にかカスペル側が対応した（？）みたいですね。ちょっと前からnaskつかってて、今思い出しました（ｗ -- 名無しさん 2008-02-18 (月) 17:08:30
- obj2bimは、NASMの"-f coff"オプションで吐いたOBJには非対応でしょうか？ -- 名無しさん 2008-02-19 (火) 23:57:00
- すいません、obj2bimの件、自己解決しました。 -- 名無しさん 2008-02-20 (水) 17:54:48
- 近いうちに（まあ数ヶ月以内かな）、GOのアップデートを予定しています（go_0024）。 -- K 2008-12-04 (木) 00:17:40
- goのソースセットが欲いのですが、k.hideyosi.comにアクセスできません。どこかにgo_0020s.lzhは置いてないでしょうか？ -- JsZ 2010-11-12 (金) 22:51:54
- 自作本のCDにおまけで入っていたので、やっぱり必要なくなりました。すみませんでした。 -- JsZ 2010-11-12 (金) 23:40:45
|
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
