Q&A
どのようなCPUを想定しているのでしょうか？8bit用のものなら見たような気がするのですが。
命令セットの定義を本体と別に持ち、ユーザー側で容易に(再コンパイルなどすることなく)追加・編集できるようなアセンブラがあれば
新しいCPUを使う際覚えることが少なく便利だと思ったのですが、そのようなアセンブラは存在するでしょうか。
(なお高級言語でなくアセンブラを使う理由は単に好きだからです)
どのようなCPUを想定しているのでしょうか？
特に想定はしていません。
というより、どのようなCPUでも追加できるようでなければ意味がありません。
(x86などの複雑な命令セットの定義を作成するのは相応に大変でしょうけれど)
#まとめ
求めているものにもっとも近そうなのが「PROASM-II」。
「強力なマクロ命令」「新たなMPUに対応する為にマクロライブラリ作成の方法を公開」とある。
「8/4ビットマイクロプロセッサ用」とあるので高機能なCPUは想定外?
どの程度の自由度があるのかは気になるところ。
9万8千円と趣味で買うには高すぎる値段。
「vasm」も、コンパイルは要るものの、命令セットの追加・編集が考慮されていそう。
他に近いものに、GCCのas、アセンブラのマクロ機能。
また、メタアセンブラという概念あり。
アセンブル後に最適化をするようなアセンブラについては、専用アセンブラ以外でその機能を持つことは困難。
最適化をしないなら問題は見当たらない。
4bit,8bitなら各マイクロプロセッサ用のマクロライブラリで対応してた「PROASM-II」とか.
「強力なマクロ命令」「新たなMPUに対応する為にマクロライブラリ作成の方法を公開」なるほど、これは私の思っているものに近そうですね。気軽に試せない価格なのが残念です。
回答7件
0
そもそもアセンブラはターゲットとなる CPU と密接に結びついているものですから、対象となる CPU が替わればアセンブラも替わるのが当然です。
意識しているのはおそらく、
・ニーモニックの構文規則と
・対応する機械語の出力を
・定義ファイルの形で別出しできる
アセンブラ「のようなもの」になるかと思います。
通常アセンブラでは命令語とオペランド（レジスタ、レジスタ間接、アドレス直接、直値）との組み合わせですから、オペランドでこう書かれていればそれはレジスタである…といった規則を定義できれば、コンパイラ-コンパイラの要領で作り上げることは可能そうではあります。
ただ、そんなもの作るよりは別のアセンブラ覚えた方が早そうな気もしますが。
まあ、パソコン黎明期にはまるで BASIC のような記述をする「アセンブラ」があったりもしたものですけどね。結局ターゲットが異なれば使えるレジスタも異なるわけで、あまり意味がなかったような。
投稿2018/05/21 04:31
総合スコア13703
> アセンブラ「のようなもの」
まあ名前は何でもいいですが。
> 作り上げることは可能そうではあります。
私もそう思ってひょっとして存在するかなと質問しました。
> そんなもの作るよりは別のアセンブラ覚えた方が早そうな気もします
その考えはもっともだと思います。
0
ほぼC言語だと思います
あとはLLVMも、浅い知識だとそんな感じな気がします。
投稿2018/05/20 15:38
編集2018/05/20 15:42
総合スコア15147
どうも意図が上手く伝わっていないようですが、
私はユーザーがCPU固有のアセンブリ言語を書くためのアセンブラの話をしているのですが。
あぁ、なるほど
私と貴方では、面倒くさいと思うところが逆なんですね。
私は命令セットを覚えるのが面倒くさいのでそっちを隠蔽したくなるものです。
そうですね、それが普通の考え方だとは思います。
命令セットを覚えるのは面倒ですがそこが楽しいので…。
asmさんも指摘するように、LLVM IRは一段階抽象化されたアセンブリのような命令セットを持ちます。高級(?)アセンブリ言語として使うことも出来るかと思いました。
To: ikadzuchiさん
興味本位なのですが、これは求めるものとは違うということでしょうか？「ユーザがCPU固有のアセンブリ言語を書く」という前提と、質問にある「対応CPUを増やせる」の具体的な関連性がイメージし辛いと思いました。
>>yohhoyさん
インストラクションセットの共通化ではなく、疑似命令/ディレクティブなどアセンブラとしての機能の部分を共通化したい、と私は読みましたが。
fuzzballさん
他回答についているコメントも勘案すると、仰るとおりの方向性なのかと納得しました。
C って高級アセンブラだと思ったのですが、、。
CPU固有情報と言いますが、アーキテクチャの違いをテーブルレベルで吸収できるのか疑問 (未来のAIなら..) レジスタ数、ビット数、CISC/RISC 古くは、バローズのスタックマシンとか。
そう言えば、 LISPマシンなんてもあったかと。これは、LISPで動くのですね。(LISPがアセンブラ)
その違いを吸収するのが、高級言語と思っていました。
なんとなく考えた結果、それはアセンブラではなくプログラマブルバイナリファイルジェネレータと名付けるべきな気がしてきた。
ruby + DSL等で作ると面白そうではある。
> 仰るとおりの方向性なのかと納得しました。
はい、その通りです。
> アーキテクチャの違いをテーブルレベルで吸収できるのか疑問
機械語を生成する分にはアーキテクチャは特に気にする必要はないかなと思います。
> プログラマブルバイナリファイルジェネレータ
まあそうですね。一応機械語の出力に特化しているので私はアセンブラと呼びたいですが。
>機械語を生成する分にはアーキテクチャは特に気にする必要はないかなと思います。
ここに大きな齟齬があります。アーキテクチャに依存しないと機械語にできません。
いや、単純にニーモニックを置き換えていくだけならどうにかなりますが、問題は最適化にあります。
アーキテクチャに強く依存したレベルで最適化しなければアセンブリで書く意味がありません。
文字通り、CPU の奥深くの（下手すればハードワイヤードな部分の）挙動（プリフェッチから命令キュー、キャッシュメモリの動作からパイプラインに至るまで）に合わせて最適化するのは、専用のアセンブラでなければ無理でしょう（複雑すぎて人の手では無理なレベルになってますが）
>>tacsheavenさん
それはコンパイラの話では？
最適化してくれるアセンブラもありますが、それはアセンブラ本来の仕事ではないと思います。
私も最適化はコンパイラがアセンブリ言語を出力する段階で行うものだと思いますね。
メモリ配置の最適化はアセンブラレベルでもやらなきゃまずい。特に SIMD とか使うと配置が面倒ですし、アウトオブオーダーで実行順を入れ替えてパイプラインストールを回避するとか、最後の最後はアセンブリのレベルで調整になります。
でもって、それらをやらない／やれないなら、アセンブラで書く意味は薄い。それこそコンパイラに任せた方が楽ですしね。
ということはアセンブリレベルでは手動調整の覚悟が要りますが、それをやるなら専用アセンブラを忌避する理由って何？ って話になるわけです。だって専用アセンブラの方が確実に対応してくれるんですから。
> アセンブラレベル
> アセンブリのレベルで
これは機械語のレベルでという認識でよいでしょうか。
> 手動調整の覚悟が要りますが
これはアセンブリ言語を書こうとする時点で当然そのつもりという認識ですね。
むしろ自動で最適化が掛かるアセンブラというものが想像の埒外でした。
> 手動調整の覚悟が要りますが、それをやるなら専用アセンブラを忌避する理由って何？
すみません、言っている意味が分かりません。
手動調整をしたい時に、自動調整される専用アセンブラを使わない理由ですか?
ものすごく根本的な話なんですが、例えば Intel ニーモニックの ADD では ADD {レジスタ}, {値} はレジスタに値を足す、ですが、これと同様のことをモトローラ MC68000 のニーモニックでは ADD {値}, {レジスタ} と書きます。オペランドの順番が逆転するのです。
なので、CPUが違えばそもそもコードまるごと違ってきますから、開発環境も異なって当然。となればアセンブラを統一する理由って何？ ということになります。
新しい命令に対応させたい、なら、その新しい命令に対応したアセンブラを使うようにすればよいのであって（どうせ使い勝手がそうそう変わるわけでもない）、そこを忌避しておいて、ソースを手動調整する手間は気にしないのは腑に落ちないのです。
コストで言えばアセンブラの設定ファイルか何かをいじって新規命令に対応させる手間と、新しい命令に対応したアセンブラにアップデートするのと、どっちが楽ですか？ という話。
これが例えば情報工学などでの論文研究だというならまだ分からなくもないのですが。
一応、GNU アセンブラは構文を統一していて（だからIntel用のコードであっても AT&T 式（MC68000式）に書く）、それはそれで批判されてたりもしました。結局設定でどっちの順序にでもできる、に変わりましたが。
> どうせ使い勝手がそうそう変わるわけでもない
ここですね話が合わないのは。アセンブラごとに(CPUに依存しない部分の)機能が異なり覚えるのが大変だと私は感じています。
それとインストールの手間もありますね。開発環境と一体化しているようなものだと特に。
> 設定ファイルか何かをいじって新規命令に対応させる手間
1つには件のアセンブラが存在したなら設定ファイルは多数公開されるだろうというのと、
もう1つ機械語を調べて設定を作成するのは(アセンブラの使い方を覚えるのに比べ)苦にならないというのがありますね。
>アセンブラごとに(CPUに依存しない部分の)機能が異なり覚えるのが大変
例えば Intel の新しい x86系CPUで、命令セットが増えたとしましょう。その場合 Intel のアセンブラの更新をするわけですが、それで増えるのは命令セットに関する部分だけで、依存しない部分の機能が大幅に変わるようなことはまずありません。
それを考慮しなくてはならないのはアセンブラの開発元が全然違う場合、つまりはCPUアーキテクチャ自体が異なる場合ですが、その場合ならば依存しない部分以前に依存する部分がごっそり違うので、覚えるのが大変なのはむしろそちらでしょう。
ですから私はそう感じないんだと言っているでしょう。
ベストアンサー
0
アセンブラのマクロ機能を使えば出来ます。
投稿2018/05/20 14:57
総合スコア84555
と思ったけど、既存の命令の意味変更は出来ないので、文字通りのことは出来ないですね。
マクロを使って別の命令セット用のアセンブラを作るということでしょうか。
確かにできはするでしょうけれど、容易ではありませんね。
おっと、コメントの反映が遅れていたようで返信順が前後しました。
そうですかやはりできませんか…。
めんどくさいですけど、技術的な困難さは無いと思います。
めんどくささは、
> 命令セットの定義を本体と別に持ち、
の「命令セット定義」を書くのと同じくらいではないでしょうか？
アセンブラのマクロ機能は命令セットを定義するために作られたわけではないので、
命令セット定義用の言語を専用に作ればもっとめんどくさくないものができるのではないでしょうか。
それとやはりマクロでは限界があると思います。
例えば mov r0,10[r1++] のような、記号を使った表現をマクロでは作れそうにありません。
> もっとめんどくさくないものができるのではないでしょうか。
質問にストレートに答えていませんでしたが、答えると、
「存在しないだろう」
ということになります。その上で、似たことが出来ないかというのが、「マクロ機能を使えば出来ます」です。
> 記号を使った表現をマクロでは作れそうにありません。
アセンブラの構文は1種類に統一するという前提の質問かと思っていました。
> 新しいCPUを使う際覚えることが少なく
と言うことだったので、同じ構文で複数CPUに対応したいのかと思っていました。
CPU毎に構文を変える（そのCPUのオリジナルのアセンブラに合わせる）のであれば、そのCPUのオリジナルのアセンブラを使えばいいかと思います。
なお、コンパイルをしていいのであれば、アセンブラジェネレーターのような物（定義文をコンパイルするとアセンブラが出来る）を聞いたことがありましたが、検索すると、こういうのも引っかかりました。何についての記述か不明ですが、テーブル駆動のアセンブラがあるようです。ただ、これもおそらく構文は1種類だと思います。
https://ejje.weblio.jp/content/%E3%83%A1%E3%82%BF%E3%82%A2%E3%82%BB%E3%83%B3%E3%83%96%E3%83%A9
この記述通りの物があれば、質問の回答になると思います。
> 「存在しないだろう」
はい、私も多分無いだろうと思っています。
> アセンブラの構文は1種類に統一するという前提の質問かと思っていました。
統一してもよいですが、記号を使えないことにかわりはないですよね。
> メタアセンブラ
なるほど、思っていた形態とは違いますがこれは私の求めていた動作ですね。
0
かつて、Javaバイトコードがそれに近いものになったことはあるんじゃないでしょうか。ArmプロセッサーはJavaバイトコードを直接実行するJazelleという機能を実装していたことがあります。これはJava言語でソースコードを書いてコンパイルしたものを実行することを企図したものですが、Javaバイトコードのニーモニックをアセンブリ言語の如く直接記述して、Javaバイトコードに「アセンブル」したものを動作させることも、原理的には可能だったのでしょう。まあ、全く流行らなかったんだけど。
今後新たにそれに近いものが生まれる可能性はほぼゼロだと思います。
投稿2018/05/20 16:06
総合スコア6768
どうも意図が上手く伝わっていないようですが、
私はユーザーがCPU固有のアセンブリ言語を書くためのアセンブラの話をしているのですが。
Jazelleのような機能を実装したプロセッサーにおいては、バイトコードは他のプロセッサーにおける機械語と同様に、プロセッサーのハードウェアによって解釈されて実行されるものですから、「CPU固有のコードを記述」するに等しいと思うのですが。「ソフトウェアによって実装された仮想マシン上で解釈実行」されるコードの話はしていません。
もしこれが普及していれば、A社のプロセッサーでもB社のプロセッサーでも、同じコードを「ハードウェアによって」動作させることができるようになったはずですから、主題の「対応CPUを増やせるアセンブラ」的なものになり得る可能性があった例として記したのですが。いずれにしても、普及しなかったものの話をしても仕方ないのですけどね。
私はCPUに固有でない汎用の機械語の話はしていないのです。
あなたの回答
tips
プレビュー
