質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.61%

  • アセンブリ言語

    105questions

    アセンブリ言語とは、機械語を人間にわかりやすい形で記述した低水準言語です。

対応CPUを増やせるアセンブラは無いか

解決済

回答 7

投稿 編集

  • 評価
  • クリップ 2
  • VIEW 713

ikadzuchi

score 200

命令セットの定義を本体と別に持ち、ユーザー側で容易に(再コンパイルなどすることなく)追加・編集できるようなアセンブラがあれば
新しいCPUを使う際覚えることが少なく便利だと思ったのですが、そのようなアセンブラは存在するでしょうか。
(なお高級言語でなくアセンブラを使う理由は単に好きだからです)


どのようなCPUを想定しているのでしょうか?

特に想定はしていません。
というより、どのようなCPUでも追加できるようでなければ意味がありません。
(x86などの複雑な命令セットの定義を作成するのは相応に大変でしょうけれど)


まとめ

求めているものにもっとも近そうなのが「PROASM-II」。
「強力なマクロ命令」「新たなMPUに対応する為にマクロライブラリ作成の方法を公開」とある。
「8/4ビットマイクロプロセッサ用」とあるので高機能なCPUは想定外?
どの程度の自由度があるのかは気になるところ。
9万8千円と趣味で買うには高すぎる値段。

「vasm」も、コンパイルは要るものの、命令セットの追加・編集が考慮されていそう。

他に近いものに、GCCのas、アセンブラのマクロ機能。
また、メタアセンブラという概念あり。

アセンブル後に最適化をするようなアセンブラについては、専用アセンブラ以外でその機能を持つことは困難。
最適化をしないなら問題は見当たらない。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • fuzzball

    2018/05/21 09:18

    どのようなCPUを想定しているのでしょうか?8bit用のものなら見たような気がするのですが。

    キャンセル

  • tmp

    2018/05/21 12:52

    4bit,8bitなら各マイクロプロセッサ用のマクロライブラリで対応してた「PROASM-II」とか.

    キャンセル

  • ikadzuchi

    2018/05/21 23:21

    「強力なマクロ命令」「新たなMPUに対応する為にマクロライブラリ作成の方法を公開」なるほど、これは私の思っているものに近そうですね。気軽に試せない価格なのが残念です。

    キャンセル

回答 7

+2

ほぼC言語だと思います


あとはLLVMも、浅い知識だとそんな感じな気がします。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/05/21 01:30

    どうも意図が上手く伝わっていないようですが、
    私はユーザーがCPU固有のアセンブリ言語を書くためのアセンブラの話をしているのですが。

    キャンセル

  • 2018/05/21 01:44

    あぁ、なるほど
    私と貴方では、面倒くさいと思うところが逆なんですね。
    私は命令セットを覚えるのが面倒くさいのでそっちを隠蔽したくなるものです。

    キャンセル

  • 2018/05/21 01:47

    そうですね、それが普通の考え方だとは思います。
    命令セットを覚えるのは面倒ですがそこが楽しいので…。

    キャンセル

  • 2018/05/21 18:02 編集

    asmさんも指摘するように、LLVM IRは一段階抽象化されたアセンブリのような命令セットを持ちます。高級(?)アセンブリ言語として使うことも出来るかと思いました。

    To: ikadzuchiさん
    興味本位なのですが、これは求めるものとは違うということでしょうか?「ユーザがCPU固有のアセンブリ言語を書く」という前提と、質問にある「対応CPUを増やせる」の具体的な関連性がイメージし辛いと思いました。

    キャンセル

  • 2018/05/21 18:06 編集

    >>yohhoyさん
    インストラクションセットの共通化ではなく、疑似命令/ディレクティブなどアセンブラとしての機能の部分を共通化したい、と私は読みましたが。

    キャンセル

  • 2018/05/21 18:55

    fuzzballさん
    他回答についているコメントも勘案すると、仰るとおりの方向性なのかと納得しました。

    キャンセル

  • 2018/05/21 21:20

    C って高級アセンブラだと思ったのですが、、。
    CPU固有情報と言いますが、アーキテクチャの違いをテーブルレベルで吸収できるのか疑問 (未来のAIなら..) レジスタ数、ビット数、CISC/RISC 古くは、バローズのスタックマシンとか。
    そう言えば、 LISPマシンなんてもあったかと。これは、LISPで動くのですね。(LISPがアセンブラ)
    その違いを吸収するのが、高級言語と思っていました。

    キャンセル

  • 2018/05/21 22:21 編集

    なんとなく考えた結果、それはアセンブラではなくプログラマブルバイナリファイルジェネレータと名付けるべきな気がしてきた。
    ruby + DSL等で作ると面白そうではある。

    キャンセル

  • 2018/05/21 23:04

    > 仰るとおりの方向性なのかと納得しました。
    はい、その通りです。
    > アーキテクチャの違いをテーブルレベルで吸収できるのか疑問
    機械語を生成する分にはアーキテクチャは特に気にする必要はないかなと思います。
    > プログラマブルバイナリファイルジェネレータ
    まあそうですね。一応機械語の出力に特化しているので私はアセンブラと呼びたいですが。

    キャンセル

  • 2018/05/22 01:21

    >機械語を生成する分にはアーキテクチャは特に気にする必要はないかなと思います。
    ここに大きな齟齬があります。アーキテクチャに依存しないと機械語にできません。
    いや、単純にニーモニックを置き換えていくだけならどうにかなりますが、問題は最適化にあります。
    アーキテクチャに強く依存したレベルで最適化しなければアセンブリで書く意味がありません。
    文字通り、CPU の奥深くの(下手すればハードワイヤードな部分の)挙動(プリフェッチから命令キュー、キャッシュメモリの動作からパイプラインに至るまで)に合わせて最適化するのは、専用のアセンブラでなければ無理でしょう(複雑すぎて人の手では無理なレベルになってますが)

    キャンセル

  • 2018/05/22 01:47

    >>tacsheavenさん
    それはコンパイラの話では?
    最適化してくれるアセンブラもありますが、それはアセンブラ本来の仕事ではないと思います。

    キャンセル

  • 2018/05/22 09:21

    私も最適化はコンパイラがアセンブリ言語を出力する段階で行うものだと思いますね。

    キャンセル

  • 2018/05/22 09:41

    メモリ配置の最適化はアセンブラレベルでもやらなきゃまずい。特に SIMD とか使うと配置が面倒ですし、アウトオブオーダーで実行順を入れ替えてパイプラインストールを回避するとか、最後の最後はアセンブリのレベルで調整になります。
    でもって、それらをやらない/やれないなら、アセンブラで書く意味は薄い。それこそコンパイラに任せた方が楽ですしね。
    ということはアセンブリレベルでは手動調整の覚悟が要りますが、それをやるなら専用アセンブラを忌避する理由って何? って話になるわけです。だって専用アセンブラの方が確実に対応してくれるんですから。

    キャンセル

  • 2018/05/22 23:52

    > アセンブラレベル
    > アセンブリのレベルで
    これは機械語のレベルでという認識でよいでしょうか。
    > 手動調整の覚悟が要りますが
    これはアセンブリ言語を書こうとする時点で当然そのつもりという認識ですね。
    むしろ自動で最適化が掛かるアセンブラというものが想像の埒外でした。
    > 手動調整の覚悟が要りますが、それをやるなら専用アセンブラを忌避する理由って何?
    すみません、言っている意味が分かりません。
    手動調整をしたい時に、自動調整される専用アセンブラを使わない理由ですか?

    キャンセル

  • 2018/05/23 09:07

    ものすごく根本的な話なんですが、例えば Intel ニーモニックの ADD では ADD {レジスタ}, {値} はレジスタに値を足す、ですが、これと同様のことをモトローラ MC68000 のニーモニックでは ADD {値}, {レジスタ} と書きます。オペランドの順番が逆転するのです。
    なので、CPUが違えばそもそもコードまるごと違ってきますから、開発環境も異なって当然。となればアセンブラを統一する理由って何? ということになります。
    新しい命令に対応させたい、なら、その新しい命令に対応したアセンブラを使うようにすればよいのであって(どうせ使い勝手がそうそう変わるわけでもない)、そこを忌避しておいて、ソースを手動調整する手間は気にしないのは腑に落ちないのです。
    コストで言えばアセンブラの設定ファイルか何かをいじって新規命令に対応させる手間と、新しい命令に対応したアセンブラにアップデートするのと、どっちが楽ですか? という話。
    これが例えば情報工学などでの論文研究だというならまだ分からなくもないのですが。

    キャンセル

  • 2018/05/23 10:03

    一応、GNU アセンブラは構文を統一していて(だからIntel用のコードであっても AT&T 式(MC68000式)に書く)、それはそれで批判されてたりもしました。結局設定でどっちの順序にでもできる、に変わりましたが。

    キャンセル

  • 2018/05/24 00:39

    > どうせ使い勝手がそうそう変わるわけでもない
    ここですね話が合わないのは。アセンブラごとに(CPUに依存しない部分の)機能が異なり覚えるのが大変だと私は感じています。
    それとインストールの手間もありますね。開発環境と一体化しているようなものだと特に。
    > 設定ファイルか何かをいじって新規命令に対応させる手間
    1つには件のアセンブラが存在したなら設定ファイルは多数公開されるだろうというのと、
    もう1つ機械語を調べて設定を作成するのは(アセンブラの使い方を覚えるのに比べ)苦にならないというのがありますね。

    キャンセル

  • 2018/05/24 09:25

    >アセンブラごとに(CPUに依存しない部分の)機能が異なり覚えるのが大変
    例えば Intel の新しい x86系CPUで、命令セットが増えたとしましょう。その場合 Intel のアセンブラの更新をするわけですが、それで増えるのは命令セットに関する部分だけで、依存しない部分の機能が大幅に変わるようなことはまずありません。
    それを考慮しなくてはならないのはアセンブラの開発元が全然違う場合、つまりはCPUアーキテクチャ自体が異なる場合ですが、その場合ならば依存しない部分以前に依存する部分がごっそり違うので、覚えるのが大変なのはむしろそちらでしょう。

    キャンセル

  • 2018/05/24 09:56

    ですから私はそう感じないんだと言っているでしょう。

    キャンセル

+2

そもそもアセンブラはターゲットとなる CPU と密接に結びついているものですから、対象となる CPU が替わればアセンブラも替わるのが当然です。

意識しているのはおそらく、
・ニーモニックの構文規則と
・対応する機械語の出力を
・定義ファイルの形で別出しできる
アセンブラ「のようなもの」になるかと思います。

通常アセンブラでは命令語とオペランド(レジスタ、レジスタ間接、アドレス直接、直値)との組み合わせですから、オペランドでこう書かれていればそれはレジスタである…といった規則を定義できれば、コンパイラ-コンパイラの要領で作り上げることは可能そうではあります。
ただ、そんなもの作るよりは別のアセンブラ覚えた方が早そうな気もしますが。

まあ、パソコン黎明期にはまるで BASIC のような記述をする「アセンブラ」があったりもしたものですけどね。結局ターゲットが異なれば使えるレジスタも異なるわけで、あまり意味がなかったような。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/05/21 23:10

    > アセンブラ「のようなもの」
    まあ名前は何でもいいですが。
    > 作り上げることは可能そうではあります。
    私もそう思ってひょっとして存在するかなと質問しました。
    > そんなもの作るよりは別のアセンブラ覚えた方が早そうな気もします
    その考えはもっともだと思います。

    キャンセル

checkベストアンサー

+1

vasm

これどうかなー。
残念ながらCPUの追加・編集はソースコードレベルですが。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/05/24 10:10

    あ、すでに回答付けてるの忘れてて新規回答にしてしまった‥。

    キャンセル

  • 2018/05/25 00:32

    なるほど、再コンパイルは必要なもののCPUの追加・編集が考慮されていそうな雰囲気がありますね。これはなかなか良いかもしれません。

    キャンセル

+1

アセンブラのマクロ機能を使えば出来ます。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/05/21 00:09

    と思ったけど、既存の命令の意味変更は出来ないので、文字通りのことは出来ないですね。

    キャンセル

  • 2018/05/21 00:15

    マクロを使って別の命令セット用のアセンブラを作るということでしょうか。
    確かにできはするでしょうけれど、容易ではありませんね。

    キャンセル

  • 2018/05/21 00:16 編集

    おっと、コメントの反映が遅れていたようで返信順が前後しました。
    そうですかやはりできませんか…。

    キャンセル

  • 2018/05/21 00:36

    めんどくさいですけど、技術的な困難さは無いと思います。
    めんどくささは、
    > 命令セットの定義を本体と別に持ち、
    の「命令セット定義」を書くのと同じくらいではないでしょうか?

    キャンセル

  • 2018/05/21 01:43

    アセンブラのマクロ機能は命令セットを定義するために作られたわけではないので、
    命令セット定義用の言語を専用に作ればもっとめんどくさくないものができるのではないでしょうか。
    それとやはりマクロでは限界があると思います。
    例えば mov r0,10[r1++] のような、記号を使った表現をマクロでは作れそうにありません。

    キャンセル

  • 2018/05/21 12:44

    > もっとめんどくさくないものができるのではないでしょうか。
    質問にストレートに答えていませんでしたが、答えると、
    「存在しないだろう」
    ということになります。その上で、似たことが出来ないかというのが、「マクロ機能を使えば出来ます」です。

    > 記号を使った表現をマクロでは作れそうにありません。

    アセンブラの構文は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
    この記述通りの物があれば、質問の回答になると思います。

    キャンセル

  • 2018/05/21 22:54

    > 「存在しないだろう」
    はい、私も多分無いだろうと思っています。
    > アセンブラの構文は1種類に統一するという前提の質問かと思っていました。
    統一してもよいですが、記号を使えないことにかわりはないですよね。
    > メタアセンブラ
    なるほど、思っていた形態とは違いますがこれは私の求めていた動作ですね。

    キャンセル

+1

そういうアセンブラは聞いたことがないですねえ

まあ、それに違いものとしては、GCCのasなんかがあります。
これはCPUごとに別個のアセンブラだけど、だいたい疑似命令やらセクションユニットの記述はあらかた統一されてますね

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/05/21 00:12

    やはりありませんか…。
    GNUのasは確かにやや近いと感じています。
    おそらくソースを取得して書き換えて再コンパイルすれば命令セットの追加・編集は可能なのでしょうね。

    キャンセル

0

かつて、Javaバイトコードがそれに近いものになったことはあるんじゃないでしょうか。ArmプロセッサーはJavaバイトコードを直接実行するJazelleという機能を実装していたことがあります。これはJava言語でソースコードを書いてコンパイルしたものを実行することを企図したものですが、Javaバイトコードのニーモニックをアセンブリ言語の如く直接記述して、Javaバイトコードに「アセンブル」したものを動作させることも、原理的には可能だったのでしょう。まあ、全く流行らなかったんだけど。

今後新たにそれに近いものが生まれる可能性はほぼゼロだと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/05/21 01:30

    どうも意図が上手く伝わっていないようですが、
    私はユーザーがCPU固有のアセンブリ言語を書くためのアセンブラの話をしているのですが。

    キャンセル

  • 2018/05/21 17:30

    Jazelleのような機能を実装したプロセッサーにおいては、バイトコードは他のプロセッサーにおける機械語と同様に、プロセッサーのハードウェアによって解釈されて実行されるものですから、「CPU固有のコードを記述」するに等しいと思うのですが。「ソフトウェアによって実装された仮想マシン上で解釈実行」されるコードの話はしていません。

    もしこれが普及していれば、A社のプロセッサーでもB社のプロセッサーでも、同じコードを「ハードウェアによって」動作させることができるようになったはずですから、主題の「対応CPUを増やせるアセンブラ」的なものになり得る可能性があった例として記したのですが。いずれにしても、普及しなかったものの話をしても仕方ないのですけどね。

    キャンセル

  • 2018/05/21 23:05

    私はCPUに固有でない汎用の機械語の話はしていないのです。

    キャンセル

0

仮にそのようなアセンブラツクールが存在したとして、その独自のスクリプトなりマクロなりを覚えて命令セットを構築するくらいなら、使い慣れた言語で自作した方が早いような気がするのですが。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/05/22 00:51

    アセンブラは書いたことがないのであまり早くできるとは思いません。
    数式の構文解析あたりは未知の領域ですね。
    無ければ書きますが、ツクールがあればそちらの方が楽だと思いまして。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.61%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る

  • アセンブリ言語

    105questions

    アセンブリ言語とは、機械語を人間にわかりやすい形で記述した低水準言語です。