†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自身でコンパイルすることしか想定していなかったので)。GO/naskNASMと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だそうです)。ほうが新しいかもしれません。将来的にはASKAもGOに含ませたいと考えています。20:15:48とりあえずこのページをGOのホームページにしてしまおうと画策中。13:15:56ASKAもGOにとは楽しみです。NASMの高性能版と言うのはどうかと思います。13:33:54いえてますね。incbinもできないし、マクロも使えないままだし。・・・ということで直しました。NASKはそうじゃないんですよね。ハタシテNASMと同系列なのだろうかと。(同系列で高性能か高機能かというのではなく)。14:01:43なるほど。言われるとそうですね。ソースの文法が近いだけで、naskはNASMの系列ではないですね。・・・ということで直しました。NASMの方が多機能でしたらサイズが大きくなるの明らかで。それをサイズが大きいから高性能というのはオカシイかと。10:11:301.NASMの自動最適化能力は標準未満です(NASM以外でこれほどの仕様が見当たらないくらいのひどさです)。2.言語処理系に対する機能というのは、サポートできる言語仕様の多様さや、「出力される」コードの質をさしていると考えます(最適化能力も含む)。3.一方、言語処理系に対する性能というのは、コンパイル時間(アセンブル時間)の短さや、「処理系自身が」コンパクトであるかどうかだと思います。11:37:42世間一般の語の用法としては、機能と性能をごちゃまぜで論じる場合もあり、そのときは多機能であることは高性能であるとしているようです。機能と性能をちゃんと別々に分けて論じる場合は、上記の解釈が一般であると思われます。出力結果を直接左右する要因のすべては機能に分類され、出力結果を直接左右しない要因のすべては性能に分類されると思います。11:44:04多機能ならサイズが大きくなるのは確かにあたりまえです。単純に機能さえ増えればサイズがどれだけ大きくても許されるというものではないでしょう。これは結局、機能とサイズの比率が重要になると思われます。いうことをすべて考慮した上で、「高性能」であるとしています。11:53:56「最適化が並」について。世間一般のアセンブラの最適化能力はアセンブラとしての理論上の最高水準に達しており、これを超える最適化はアセンブラであることをやめない限り不可能です。これが並であることは最高であることも意味します。この点に関しては、NASMがひどいだけです。11:58:52『サイズが小さいから高性能だぜ!』と読み取れたのですが、出力されるオブジェクトの品質がNASMよりも優れているということですね。(機能の割には)サイズが小さいから高性能なんです。サイズは性能の一つです。自動最適化はnaskの機能に関する話であって性能とは関係ないです。自動最適化については上の説明に最初から書いてあったので、結局何が疑問だったのかも不明です。ただの読み落しだったのでしょうか。15:01:31単純に今時、同等の機能を有していないモノとの比較で1バイトでも小さいから高性能だという変わった人もいるもんだなと思っただけです。14:57:06naskのサイズに関する説明を追記しました。オプションを複数付けると、二つ目以降を無視してしまうようです。0してしまった事だと思います。00:01:06サイズと性能は、直接結びつかないため疑問が出るわけです。「サイズが小さいけど高性能」ならわかります。性能を示すなら、同じ出力タイプでの処理速度と品質でしょうね。15:59:09win32版GOをDLさせてもらったところうちのアンチウィルスソフト(kaspersky)がnask.exeをトロイとして認識したんですが...不安になったので削除しました。02:34:57うちもカスペル先生にダメされました。16:15:05↑KasperskyでTrojan-PSW.Win32.Agent.kvとして誤検出されました。自分の経験ではまったく別のexeでもまったく同じ名前で誤検出された記憶があるので、該当ウィルス定義ファイルの実装に問題があるんじゃないかと。許可してかまわないと思います。19:41:34管理者さんへ:ダウンロードするファイルへのリンクをクリックすると、ウイルスサイトへ飛ばされますが...。06:01:31直しておきました。13:21:07naskがカスペル先生にダメだしされる問題は、いつの間にかカスペル側が対応した(?)みたいですね。23:57:00すいません、obj2bimの件、自己解決しました。17:54:48近いうちに(まあ数ヶ月以内かな)、GOのアップデートを予定しています(go_0024)。00:17:40goのソースセットが欲いのですが、k.hideyosi.comにアクセスできません。22:51:54自作本のCDにおまけで入っていたので、やっぱり必要なくなりました。