Q&A
ここでも「また」と、VRAMに書き込む過程の話と、printf()の話と、発散しちゃう苦笑
題名に書かせていただいた通りPCのVRAMにアセンブリ言語でデータを書き込むことを考えた場合、
windowsの場合はwin32APIによって直接書き込むことは出来ないため、win32よ呼び出してVRAMに書き込みたいデータを渡して、win32がVRAMにデータを書き込むことで画面に文字や色が表示されると思います。
しかし、Linuxの場合はOS自体がオープンソースであるため、VRAMにデータを書き込む過程をアセンブリプログラムで見れるのでしょうか？
「書き込む」部分アセンブリプログラムで見れるかをお尋ねしたいです。
printfに関しては文字を表示する際に関係しているため質問をわかりやすくしようとしたつもりがかえってわかりにくい内容になってしまいました。すいませんでした。
どうかよろしくお願いいたします。
//編集内容//
VRAMにアクセスする上で壁が多くあることはよくわかりました。（多分）
そこで、過去にした質問を少し変えて改めて質問したいのですが、CPUからGPUを経由してVRAMにデータを書き込むPCであるという仮定で「CPUからGPUを経由してVRAMにデータを書き込みをするⅭプログラムをコンパイルに成功して実際に文字が表示できたとします。そのC言語プログラムをアセンブリプログラムに変換したとします。そのアセンブリプログラムはハードウェアに依存したものであるため、GCCでアセンブリプログラムとして実行してもCプログラム同じような結果が出ると思います。
得られたアセンブリプログラムをVRAMにデータを書き込むひな形のプログラムとして、そのひな形のアセンブリプログラムを参照に改造して別の文字を表すようにアセンブリプログラムで書いてGCCなどでアセンブリ言語としてコンパイルできれば、アセンブリプログラムでVRAMにアクセスでき文字を表せると思うのですが、（OSも関与してくると思いますが。）私の考えは間違っているでしょうか？
完全に一からアセンブリプログラムを組んでVRAMにアクセスするのは難しいですが、以上のようにできるならばVRAMにアクセスするのは難しくないと思います。
完全に一から使っているCPU、GPUの情報からアセンブリプログラムを組んでVRAMにアクセスするのは難しいですが、コンパイラによって出力されたアセンブリプログラムをそのまま使えばVRAMにアクセスするのは難しくないと思います。
文章をもう少し推敲した方がよいですよ。 ・表題で「書き込む。」という話が、質問本文中では「見れるか」と言う話になっている。 ・「オープンソースであるため書き込むところが見える」と言う話が、「アセンブリプログラムで見れる」という話になっている。 ・途中からOSではなく、C言語のprintfの話になっているがテキストVRAMやBIOSの話を聞きたかったのだろうか？
わかりにくい質問になってしまい申し訳ありません。編集させていただきました。
そもそも、printf()は文字を表示する関数ではないですよ。printf()は文字を標準出力に出力する関数です。
TaroToyotomiさんに質問したいのですが、printf()などの関数ではなく、VRAMに文字データを送ってくれるC言語あるいはC++言語の関数を使ったほうが良いのではないでしょうか？
再度伺いたいにですが？ OSありきでVRAMにアクセスしたいのでしょうか? それとも、なしの状態（BIOSのみ）でもいいのでしょうか？ 前提条件がまるで見てきませんが・・・
ごちゃごちゃしてしまいすいません。両方知りたいです。
既に解答者の方々が上げて頂きましたが、再度言わせて頂きます。osありきのVRAM、osなしでのVRAM、osとBIOSなしでのVRAMへのアクセスただ、osとBIOSなしでのVRAMへアクセスの3つです。
質問の意味がよく分かりません。printf()関数は何故存在しているかという話ですか？話が発散して収拾がついていないです。
あの、printf関数は文字などを表示する関数だと昔通っていた学校で教わりました。しかし、そうではないようです。もし、printf関数が文字などを表示する関数ならばVRAMへアクセスして文字を表すのとあまり変わりはないのではないかと思いこんだだけですよ。不快な思いをさせてしまい申し訳ありません。
回答8件
0
ベストアンサー
Linuxの場合はOS自体がオープンソースであるためVRAMに書き込むまでの過程を見ることができる
できるでしょうね。
この分野もｗ私は門外漢なので外してるかもしれないが、LinuxのウィンドウシステムはX Window Systemだと思うので、今ならX.OrgServer辺りから調べればVRAMに書き込む部分（ドライバ）まで辿り着けるかもしれない。ただグラフィックボード（ハードウェア）はいくつもあるので、物理ドライバも複数あるはずで、あなたのパソコンで動いているドライバがどれか、なんて知らないよ。
VRAMにデータを書き込む過程をアセンブリプログラムで見れる
見ることはできるでしょうが、上記ドライバはCで書いてるはずだから、動きを知るにはCのコードを読まない限り時間の無駄、実際はアセンブリコードを見ても何もわからないでしょう、これは請け合いだ（笑）。はっきり言って、VRAM操作のアセンブリコードを見ること自体にあまり意味は無いと思う。
GPUを操作しているのなら、GPUの仕様がわからないとCのコードを見てもちんぷんかんぷん、ましてアセンブリコードを見ても（Ry
それよりも、あなた自身が普通に書いたCプログラムをコンパイルしたアセンブリコードを見る、Cのコードのどこがどうなったか、大雑把でよいから掴めるようになる事が大事。
printf関数がもしOSに依存しているとしたら
全く依存しない、とは言いきれませんが、標準ライブラリなんだから、少なくともあまり依存しないように、移植性を考えて書くわけです。
アセンブリ変換すればVRAMに文字や色を表すためのデータを受け渡す部分が見れたり…
しません。printf()は絶対そんなことをしません。
なぜそう言えるか。処理には階層というものがあるから。
フォーマット文字列に従って、渡された引数を、表示すべき文字列に変換する、のがprintf()の本体であり、役目です。表示すべき文字列を作ったら、別の関数として用意された、文字列全体を表示する関数（或いはそろそろシステムコールかな？）のような物を呼び出して表示を行います。階層は２段階以上ある。
さらに、main() { printf("hello world!\n"); } をコンパイルして出来た実行ファイル（例えばhello.exe）は、そのままビットマップディスプレイにも、ssh等で繋がった別のパソコン画面にも、シリアルケーブルで繋いだ端末にも表示する…ばかりか
$ hello.exe > message.txt
とすれば、ファイルに出力することもできます。このように、実行時に入出力先を切り替えることをIOリダイレクトと呼びます。もしprintf()の段階でビットマップに出力していたら、ファイルに出力したデータはビットマップになってしまう（笑）。
即ち、IOリダイレクトができるということは、ビットマップディスプレイに文字フォントを描き出す機能と、printf() は、実行時に連携して動作するのであって、遠く離れた・全く別の場所にあるコードだということを意味します。
念の為：処理には階層がある・・・階層を作る基礎がサブルーチンや関数ですよ。
投稿2018/03/10 02:17
編集2018/03/10 02:42総合スコア1380
いつもいつもどうもありがとうございます。
こちらの情報は2008年と15年前で古いですが、以下のものを見つけました。
http://d.hatena.ne.jp/rudeboyjet/touch/20080108/p1
これは、BIOSのシステムコール・・・PC/AT互換機なら、皆同じですがLinuxが使っているかどうかは不明。Kunihiro_Naritaさんが書かれている参考先と同じ事をやってるだけです。「文字出力はBIOSに任せている」ので実際にどうやって描画しているかはBIOSのソースが無いとわかりません。この辺は、MS-DOSやCP/Mの世界ですねd＾＾ 8ビット機/16ビット機でも有ればBIOSーROM吸い上げて逆アセンブラかければ分かるでしょうが＾＾； 今のBIOSはでかすぎる；；
参考：https://en.wikipedia.org/wiki/INT_10H
2008年は１０年前ですね。
int 0x10はBIOSのビデオサービスですか。。。
Linuxは、起動にはBIOS使う（そうするしかない）けれども、一旦立ち上がってしまえばBIOSを一切使わず、自前のデバイスドライバで動作すると理解してます。もちろん呼び出しもできないと思います。
それはWindowsも、事情はとっくに同じだと思います。つまり、昔ならともかく、今はちょっと試せないコードだと思います。
そうなんですか。残念です。
度々、申し訳ありません。
「VRAMにデータを書き込む過程をアセンブリプログラムで見れる」に関してはわかりました。
ちなみに、見る事が出来るならば、それを実装して直接VRAMに「書き込む事」は出来るのではないでしょうか？
コピペするなどして。
ましてや、構造がわからないにしても、Ｃ言語プログラムで書き込みがうまくいった場合、それをアセンブリプログラムにすれば、VRAMとGPUの構造を知らなくても、
すなわち、構造を知らないVRAMとGPUにＣ言語プログラムを実行して成功した場合、そのＣ言語プログラムをアセンブリプログラムに変換できれば、VRAMとGPUの構造がわかり、そのアセンブリプログラムがVRAMとGPUに直接働くような雛形のアセンブリプログラムになると思うのですが。
もちろん、規制などがあると思うので何もかもがうまく行くとは思いません。
> そのＣ言語プログラムをアセンブリプログラムに変換できれば...VRAMとGPUに直接働くような雛形のアセンブリプログラムになると思う
そもそも、アセンブリコードでやろうとする・アセンブリコードにこだわる意図・理由は何ですか？
普通、動作実績のあるＣ言語プログラムがあれば、わざわざアセンブリコードで扱うことはせず、Ｃ言語のままで利用するものです。
もしかして、アセンブリコードで作業すると、Ｃ言語ではできない、何か特殊な＜能力＞が得られる・在る・備わると思ってますか？
まずは、rubato6909さんの言われた通り、簡単なＣ言語プログラムから中級のＣ言語プログラムをアセンブリ変換してアルゴリズムやレジスタの動き、動作などを勉強してみます。
そうすれば自ずとアセンブリプログラムが理解できて、組めたり、Ｃ言語に変換できるかもしれません。
あの、余談でお聞きしたいのですが、なぜサムネイルがウルトラマンなのでしょうか？
特殊とは思っておりません、ただ、アセンブリ言語で書くとハードを考慮して書くため満足感が得られるのです。
たいへん阿呆らしいかもしれませんが。Ｃ言語を書いてもハードを意識するかもしれませんが、バリバリにハードを意識してプログラムを書きたいという願望があるためアセンブリ言語に固執しています。
あまり理解されないかもしれませんが、所詮は自己満足です。
馬鹿だと思うなら遠慮なく罵ってくれて構いません。
ハードを考慮しながらアセンブリ言語を書ければ馬鹿呼ばわりされても僕は満足です。
アセンブラに興味があるということなら、ARM(Atmel) かPIC(microchip)のCPUでもつかって簡単なプログラム作ってみたらどうでしょう。内蔵タイマー使って時刻表示するだけでも動いたら結構うれしいですよd＾＾；（ハンダ付けとマニュアル解読技術はいりますが） 部品は秋月電子（http://akizukidenshi.com/catalog/default.aspx 都内でなければ通販も有ります）でも探せばほとんど揃います。Amazonでもいろんなキット売ってるみたいです・・・
自己満足とわかっているなら何をしても貴方の趣味で構わないが、やろうとしていることに比べて貴方から窺える基礎的な知識、技術程度はかなり不十分です。
> 簡単なＣ言語プログラムから中級のＣ言語プログラムをアセンブリ変換して
Cとアセンブリ言語の仕組みを修行するだけでかなりの期間を要するはず。C、アセンブラ、OSなど一般論はパソコンをターゲットにした勉強で構わないが、
VRAMアクセスには貴方が気づいていない「壁」がいくつかあるはずで、ハードウェアもソフトウェアも複雑になってしまったパソコンは余計に壁が高く不向き。VRAMで試すターゲット機はマイコン（含ARM、AVR,PIC）にしたほうが良い、と私も思う。
そうですか...。
では、「簡単なＣ言語プログラムから中級のＣ言語プログラムをアセンブリ変換してアルゴリズムやレジスタの動き、動作などを勉強してみます。」に関してもあまり意味はないのですかね？
考えが甘いというか浅はかでした。本当に残念です。
そうですね。僕の技量と知能では「VRAMアクセスに関しての「壁」がいくつかあることを理解できていないし、理解出来たところで解決しようとしても全然違うことをしてしまったりで、本当に悔しいし、プログラマー以前に失格です。
ただのpcのVRAMでさえ、扱えないなんて笑い者ですよ。
>ただのpcのVRAMでさえ、扱えない
ここに来るプログラマ諸氏で、現在のPCのVRAMにアクセスする方法が分かる人がどれくらいいるでしょうか？・・・私には分かりません・・・；；
自分はアタマがいいつもりなんだろうなあ。。
ラスパイでも買ってきて、OSなしで直接VRAMいじってみては？
Cだろうがアセンブラだろうが自分の自由にできますぜ
ここでいくら机上の空論ぶっこいても、どーにもならないでしょ
http://d.hatena.ne.jp/rudeboyjet/touch/20080108/p1のint10hは
qemu -fdaで起動していることからわかるようにフロッピーを用いた起動です。
OSさえなければVRAMへの書き込みはさほど難しいことじゃないです。
> 「簡単なＣ言語プログラムから中級のＣ言語プログラムを・・・勉強してみます」に関してもあまり意味はないのですかね？
C、アセンブラ、OSなど一般論はパソコンをターゲットにした勉強で構わない、と書きました。＜ソフトウェア全般＞を勉強する環境として、パソコンは良いツールです。
しかし、＜ハードウェア絡みの実験＞をするターゲットとしてのパソコンは、どんどん敷居が高くなっているから、向いていないのです。向いてるのはハダカ（OS無し）でも動かせるマイコンです。でも、マイコンを動かすにもパソコンが無いと何もできません。
> 現在のPCのVRAMにアクセスする方法が分かる人がどれくらいいるでしょうか
そうそう、私にも分かりません。「GPU」というモノに関心を持たずにいた位で、今回良い勉強ができたかな笑。
アセンブラでVRAMアクセスって、たどり着いてしまえば割と単純な事だからやってみたいと思ったんだろうけど、そこにたどり着くまでが大変だと思う。ソフトウェアの構成（OS、ドライバetc.）も、アーキテクチャもハードウェアの諸々も、関与する事項が様々あるはずです。
そう考えれば、質問者がパソコンのVRAMにアクセスできる日がきたら、それは膨大な勉強と経験を積み重ねた証しになるでしょう。まさしく「バリバリにハードを意識してプログラムを書きたい」にふさわしいテーマかもしれない。今は視野を広げながら足元を固める時期で、Cでもアセンブラでもバリバリ読み書きできる位でないとお話にならないと思います。
>膨大な勉強と経験
もう無理かも＾＾； 元々組み込み系の仕事が主体だったので、Cとアセンブラを使う機会が多かったのですが最近のCやC++の改変には付いていけてません。（Cは30年ぐらいやってますかね・・・実務は離れてしまっているので“もうどうでもいいか”・・・状態ですw） 最近ではAVR+TTL＋８SEGなどで回路組んであそんでます。今度はeZ80あたりでCP/Mでも動かせればいいなぁ…とか思ってます。
VGAを直接叩くようなことをしたいのであれば、「仮想マシン＋DOS」というのがいいかなと、個人的には考えます。
OSがハードウェアを握ってしまわない＆Cコンパイラなどの開発ツールも使えるということで、ちょうどいい気がします。今では、FreeDOSというオープンソースのもあります。
なお、以前からコメントしているように、特にnvidiaのGPUについては直接制御するための技術的詳細が公開されておらず、「nvidiaのデバイスドライバや、既知のBIOS割り込みなどを使わずに自分で書いたコードで制御する」ようなことはほぼ不可能です。
うちにはCompaqの16ビット機が1つ転がってwいる（FreeDOSが入ってる）のでVRAMいじりは出来るかもしれませんがいまいち触手が動きません＾＾； （そうとう）昔、漢字ロム（知ってる人がいるのかw）からビットマップを読み出して、その拡大を画面に（1ドットを１キャラで）書き出す・・・なんてやってましたね。モノクロだから楽だったw
なるほど、仮想マシン＋DOSなら、そのビデオサービスBIOSを呼び出すコードを試すことも可能でしょうね。
健闘を祈るｗ＞carnage0216さん
そうですね。
ソフトウェアの構成（OS、ドライバetc.）も、アーキテクチャもハードウェアの諸々なども勉強してアセンブリプログラムを書いてVRAMにアクセスするのはハードルが高いなんてレベルじゃないですね。
あの、rubato6809さんに聞きたいことがあるのですが、
私の持っている本のアセンブラ画像処理プログラミング（SIMDによる処理の高速化）では画像に線を書いたりするアセンブリプログラムがあるのですが、GPUを使っているとかは書いていませんでした。
出版された年が2005年なのでGPUを使わずにCPUのみを駆使してVARMに書き込んでいたんですかね？
今現在はCPUとGPUの二つを駆使しながらVRAMに書き込んでいるみたいですが。
VRAMにアクセスする上で壁が多くあることはよくわかりました。（多分）
そこで、過去に質問を少し変えて改めて質問したいのですが「CPUからGPUを経由してVRAMにデータを書き込みをするⅭプログラムをコンパイルに成功して実際に文字が表示できたとします。そのC言語プログラムをアセンブリプログラムに変換したとします。そのアセンブリプログラムはハードウェアに依存したものであるため、GCCでアセンブリプログラムとして実行してもCプログラム同じような結果が出ると思います。
得られたアセンブリプログラムをVRAMにデータを書き込むひな形のプログラムとして、そのひな形のアセンブリプログラムを参照に改造して別の文字を表すようにアセンブリプログラムで書いてGCCなどでアセンブリ言語としてコンパイルできれば、アセンブリプログラムでVRAMにアクセスでき文字を表せると思うのですが、私の考えは間違っているでしょうか？
完全に一からアセンブリプログラムを組んでVRAMにアクセスするのは難しいですが、以上のようにできるならばVRAMにアクセスするのは難しくないと思います。
アセンブリプログラムに固執している理由は偏見かもしれませんが、単純に低級言語が大好きなだけです。いつかはC、C++と連携させて高速化を行ってみたいと思います。
y_waiwaiさん、僕は自分が頭がいいや頭、いいつもりとも思っていませんよ。
どちらかというと悪いと思っています。
ラズパイの情報ありがとうございます。
> 私の持っている本…では画像に線を書いたりするアセンブリプログラム
な〜んだ、参考書があるなら、ぞれを試してみればよいだけじゃ？？？
今もメインメモリの一部をVRAMにしてるらしく、GPUがあってもCPUはVRAMにアクセスしてるらしい、、、そうは言っても私はVRAMを読み書きする術を知らない。知らない人間に聞いてる暇があるなら、参考書通りにさっさとやればよいだけ、参考書がありながらグズグズしてるのは不思議ですらある呆
おっしゃる通りですが、何しろ2005年と古かったため。
そうですね。線書いたりしてるならVRAMへアクセスしてるかもしれないし、アクセスできるならば、そのコード自体が私の求めていたコードです。
コンパイルエラーがあったら、地道に改良してみます。
そうですね。
まずは、gccでアセンブリプログラムの実行のコマンドを調べます。
こんな私に最後まで回答していただきどうもありがとうございます。
プロテクトモードでは
(最近のOSはしらないけど)
リング3のタスクがディスクリプタを参照しVRAM領域へアクセスすることはできないですよね？
同じ権限のセグメントでもアクセス拒否されるはずですし
なので、用意されたBIOS命令またはシステムコールを使って間接的にアクセスするものだと思っていましたが
できるもんなんですか？
> リング3のタスクが・・・VRAM領域へアクセスすることはできないですよね？
リング３はユーザタスクですよね？それなら VRAM にアクセスできないでしょう。
アクセスできるのはたぶん（確かリング０で動作する）デバイスドライバだと思います。
デバイスドライバもソフトウェアです。そいつならアクセスが可能かもしれない、というつもりで回答しました。少なくとも大昔のＰＣはＶＲＡＭをアクセスできました。今はＧＰＵ（のようなもの？）を経由して間接的に描画するかもしれず、結局ＶＲＡＭを直接操作することは出来ない場合もあるかもしれない・・・実際のハードウェアもソフトウェアも、私はこの分野に疎いので責任ある回答はできませんが。
> 用意されたBIOS命令またはシステムコールを使って間接的にアクセスする
少なくとも Linux が BIOS を利用するのは起動時の僅かな部分だけで、Linuxが立ち上がってしまえばＢＩＯＳを使わない、と聞いています。
ユーザプログラムはシステムコール経由で表示・描画する、それはそういうものだと私も漠然と理解はしています。
そのシステムコールを利用できるのはＯＳとデバイスドライバ、Ｘ-Windowシステムなど、＜ソフトウェア＞を書いた人たちがいるからです。そうした人達の中に、＜ＶＲＡＭにアクセスする＞レベルのコードを書いた人もいるはず、だって表示するんだから。そのコードは「ＶＲＡＭにアクセス」するコードじゃないの？そして、そのレベルのコードがあるはずだから、それを調べたら？と大虐殺carnage君に返答してみたわけ。できっこないと思うけど（私もできないけどｗ）、単純に門前払いするのもなんだから。
わかりました。ありがとうございます
0
PCのVRAMを簡単に触る方法はないのか？というと、ないこともないです。
「UEFIアプリケーション」は中身は単なるWindowsと同じPEなのですがUEFI(BIOS)によって起動され
BIOSの力を借りますが、VRAMに書き込みができます。
利点
- ドキュメントが公開されている(らしいですよ
- フォーマットとしては、ほぼ単なるDLLなのでWindows用にDLLを作れる環境ならば作成可能(MSVCですら可能だとか)
- 実機で起動する際にブートレコードが云々などを気にせず単純にFAT32にフォーマットしたUSBストレージの指定パスに置くだけでよい
参考
https://orumin.blogspot.com/2014/12/uefi.html
https://github.com/tenpoku1000/UEFI_FreeType_MSVC
http://wiki.phoenix.com/wiki/index.php/EFI_GRAPHICS_OUTPUT_PROTOCOL
http://wiki.phoenix.com/wiki/index.php/EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE
→FrameBufferBaseがVRAMの先頭アドレスになります。
以上の方法でUEFIアプリケーションからVRAMにほぼ直接書き込めるC言語のプログラムが作れます。
そしてそれを逆汗なりアセンブリ出力なりで出したものを雛形にしたものをアセンブラに通せばアセンブリでVRAMへ書き込めます。
デバイスを直接いじってる感はありますが、グラフィックドライバをアンインストールしたWindowsと同じ状態なので
低速(というかCPUに速度が依存する)であり、デバイスを使いこなしているかというと疑問です。
投稿2018/03/12 03:42
総合スコア15147
本当にどうもありがとうございます。
あの、自分も調べたのですが、BIOSを使わないでVRAMへアクセスしているみたいです。驚く事に2016年の資料なので、今現在のpcでも実装できるかもしれません。
ただ、nasmというgccとは違うようなものを使っているので下調べが必要です。
https://qiita.com/Wanwannodao/items/1d999aeb365397d08493
「BIOSを使う」の定義によるんじゃないですか？
レガシーBIOSが起動時に割当および初期設定をしたものです。
あ、そうだったのですか。
後は、os自作でＣ言語プログラムとアセンブリでVRAMにアクセスする方法ですね。
http://osjisaku30.g.hatena.ne.jp/bluespear/20060728/1154057603
どちらも「MBRを用いたレガシーBIOS環境でのVRAM書き込み」です。
アセンブラのみで作成できるというメリットはありますが、MBRへの書き込みが厄介なのが難点でしょう。
2020年頃にはレガシーBIOS廃止したいとIntelが言ってるのも問題ですね。
0
とても大雑把ですが一般的な汎用計算機の話から・・・
PCのVRAMにアセンブリ言語でデータを書き込む
これは現代的なOSの元では一般的に「不可能」です。それは例えばWindows/Linuxのカーネル、GPUメーカー提供のドライバー、OpenGLなどの全ての関連ソースプログラムを理解したとしても同じです。問題は「どのように描画しているかの処理の仕様がわかるかどうか」というレベルの話ではなく、「一般プロセスが計算機のハードウェア資源(I/Oデバイス)に自由にアクセスすることは許されていない」というレベルの話です。
なぜそうなっているかというと「現代的なOSは、一般のプログラムがどのようなバグを持っていても極力OSやハードウェアをダウンさせない」という思想で設計されているからです。
誤解をおそれずに言えば、一般プログラムはOSから「何か致命的なウィルスでも潜んでいるかのように」扱われ「勝手なことができないようガチガチに制限された中でしか動けない」のです。主記憶についても「勝手なアドレスに自由に読み書きすること」さえ許されていません。OSがお膳立てした「仮想的なメモリー空間上をアクセスすることだけ」が許されるような状況でのみ動作します。I/Oポートに直接アクセスすることもできません。その辺りを許してしまうと例えば「プログラミングを学ぼうとして、何かのプログラムをC言語などで書いて動かす」と簡単にOSやハードウェアが壊れる結果になりかねないのです。
まずは「このように安全性が配慮されているのが現代のOSである」という認識からスタートするのがよいでしょう。
さて、Raspberry Piはどうでしょうか？Linuxを動かすならある程度前述のような安全性が考慮されているとは思います。しかしながら、このハードウェアは「組み込み機器を手軽に構築できる」という思想で設計されていると思います。それゆえ一般の汎用計算機よりもハードウェアにもっと近い部分にプログラマーが接近する余地があるだろうと思います。
そういうわけでこの話題について調べるには「Raspberry Piではどうか」という前提条件が必須になると思います。で、Raspberry PiでそもそもVRAMに直接アクセスできるかを「Raspberry Pi VRAM direct access」で調べてみますと、「それが可能であるらしい」ように見えました。あるQ&Aの回答者が提示しているのは以下のプログラムがそのスタート地点だとのことです。
https://github.com/brianwiddas/pi-baremetal/blob/master/framebuffer.c
ただ、このレイヤーではVRAM＝即ちピクセル単位の画素情報の読み書きが前提ですので、「文字をどうピクセルへレンダリングするか」という話題は出てこないだろうと思います。それはもっと抽象レベルに近い高水準機能に属することでその手法についていえば「フォントレンダリング」といったキーワードになるのではないでしょうか。
まぁ、しかしVRAMに何かを書きこみたいというのが質問者さんのやりたいことなのでしょうからそんな高度なフォントレンダリングを調べなくても「もっと素朴なやり方を自前で考えること」が可能だと思います。どんな画素パターンをVRAMに書けばいいかを考えればよいのです。
Text
1...**... 2..*..*.. 3..*..*.. 4..****.. 5.*....*. 6.*....*. 7.*....*. 8........
こんな素朴なパターンでも'A'には見えるんじゃないでしょか。ちなみに色については「VRAMのアクセスを直接やる」ならそのVRAMのフォーマットに全ての秘密があります。例えば3バイトでR,G,Bの順番に256諧調で画素値を指定できるようなフォーマットになっているのであれば、赤のピクセルを書き込むには0xFF 0x00 0x00という3バイトを所定の位置へ書き込めばよいですし、白にしたければ0xFF 0xFF 0xFFにすればいいです。
LinuxでならVRAMにデータを書き込む過程をアセンブリプログラムで見れると考えているのですが、この考えは間違っているでしょうか？
また、printf関数がもしOSに依存しているとしたらLinux同様にアセンブリ変換すればVRAMに文字や色を表すためのデータを受け渡す部分が見れたりするのでしょうか？
多分見ることができても、それを活用できるレベルまで理解するのは「大変困難」と言ってよいと思います。一般のOSによく出てくるTrueTypeフォントですが、その描画メカニズムを調べるだけで相当に難しいと思います。そんなものを調べていたのではいつまでたってもVRAMに書き込むプログラムの完成は見えてこないと思います。（もっと長期的にそのあたりのメカニズム・技術に挑戦するというのはそれはそれで一つの挑戦と思いますし、別に否定するような意見は持ってません）
しかし、'A'という文字コードから前述のビットマップフォントを得るぐらいなら自前でも充分作れるでしょうからそういうアプローチにしたほうがよいでしょう。LinuxやX11のソースコードを調べてconsole/terminalへ出力した文字列がどうレンダリングされるかを読み解こうとはしないほうがよいというのが自分の意見です。
投稿2018/03/10 03:55
総合スコア18394
やはり、大きいものより、
AVRマイコン搭載のアルディーノやラズパイでやりたいことをこなした方が力がつくかもしれません。
規制が緩い分、自分の行いたい事が行えるし、行うまでのＣ言語のソースをアセンブリ言語に変換できれば、アセンブリプログラムで行いたい事が実現できそうです。
pcを自由に扱うなんてのは今の僕には無謀過ぎました。
なんか、自分が回答書いているうちに色々な方がもっとよい回答を書かれているので「ありゃ」と思いました。個人的には質問者さんへのアドバイスとして「rubato6809」さんの回答を支持したいです。
なお、自分が書いたリンクですが、これがRaspberry PiをどのOSで動作する場合の方法なのかといった点、自分は全然わからずに書いてます。もし見当はずれのリンクでしたらご容赦です。
> アルディーノやラズパイでやりたいことをこなした方が力がつく
そうかもですね。普通に文字が書ける環境(OS)は既にあるのでしょうから、文字の描画はそっちへ任してこれぞラズパイ的な応用に目を向ける点は賛成です。いろいろ楽しそうなことができそうですし！
僕はpcに搭載されているcpuやGPUでしか、性能が良く、処理速度が速いという偏見なのか事実なのかよくわからない事がある故に
pcを使いこなしたいと考えるようになり、AVR マイコンやラズパイを性能や処理能力が低いものだと思っていました。ですが、最近のラズパイやAVR などのマイコンなどは性能が良くなってきたためLinuxを入れて学習と実践ようとして使えてpcに搭載されたcpu,GPUよりも性能が良いならばアルディーノやラズパイで文字表示のためのVRAMなどをいじったりドライバーを勉強した方がマシに思えてきました。
皆さんは僕のような未熟な人間の考えはどう思いますか？
まぁ、自由にいじれないのなら、それに似た何かを自由が利くボードなどで行えればと思います。自由にアクセスすることは許されていないならば、そこまでしてアクセスしたいとは思いませんし、似たようなものがラズパイなどで実現できるならばその方が時間を無駄にしなくてすみそうです。
KSwordOfHasteに質問なのですが、以下のようなことは一般プロセスが計算機のハードウェア資源(I/Oデバイス)に自由にアクセスすることは許されていない」というレベルの話であるかもしれないので、できないのでしょうか？
「ドライバーのソースを追っていけばいずれはVRAMに書き込んでいる部分にたどり着くと思います。
当然のことながらGPUによってドライバーは変わるので、お使いのドライバーに応じたソースを入手する必要」
では、「使うドライバー(のソース)を用いてVRAMに書き込む」Ｃ言語プログラムが入手出来れば、アセンブリプログラムに変換してどのようにVRAMに書き込んでいるのか見れるわけですが、周りの方がおっしゃる通りアセンブリプログラムだけ見ても訳が分からなくなるので、Ｃ言語プログラムを読んでからアセンブリプログラムを見ると言った段取りを組みたいです。
ただ、使っているGPUを知るためにとりあえず、GPUで適当にVRAMを扱うＣ言語をアセンブリ言語に直してみてから、得られたアセンブリプログラムを基にいくつものGPUの種類があれどGPU構造やどのようにVRAMにデータを書き込んでいるかなどが推測できて、GPUからVRAMにデータを書き込む雛形のアセンブリプログラムができるのではないかと思います。
もちろん、使っているpcがGPUを使わずにVRAMにデータを書き込むようなものであれば、雛形を作る過程は変わってくると思いますが。
とても楽しそうです！
以上のやり方なら、ソースが公開されてなくても試行錯誤と推測で公開されていないソースと似たようなものが得られるかもしれません。
もしかしたら、アクセス制限
とかやりたい事が出来ない事が多いため、マイコンやラズパイなどの規制の緩いものを使っているのかもしれないですね。
pcはあくまでマイコンやラズパイを開発するためだけの環境として利用しているだけとか。
13:37 のコメントに対してGraphicsに関してコメントします。自分は専門家ではないので正確な情報ではないかも知れないことを最初にお断りします。
今日のGPUのトータル性能はCPUには追い付けないほどのレベルに達してしまっていると自分は考えています。最早アプリケーションプログラマーがどう頑張ってもGPUのドライバーがやっている以上のことは不可能ではないかなぁという感じ。GPUはCPUに比べて馬鹿みたいに早いのでCPUでおいつけない計算をGPUでやってしまえという技術があるくらいです。
今日のGPUが何十何百の内部プロセッサで3D処理を並列して処理しているということを考えると「そんなレベルと対抗したりそのメカニズムを解き明かそう」というのは少なくとも自分レベルでは無理そうです。
> pcを使いこなしたい
これは非常に奥深い意味を持っていると思います。どこまでやれば「使いこなしている」といえるか自分にはわかりませんが、質問者さんがおっしゃっていることはソフトウェアのみならずハードウェアの深い知識をも駆使してハード・ソフト両方を使い倒すということを意味しているのではないでしょうか？
これについては自分はこう思います。「限定された世界でのプログラミング」もそれはそれでありだけど、それに満足せず知識領域を広げようとすればいくらでもマニアックな技術はごろごろ転がっている。Graphicsについては発展しすぎていてかみつこうとしても歯が欠けそうだけど(w;)知ろうとすればある程度の情報は得られるだろうし例え具体的なプログラムに結び付かなくてもそれは一つの知見となって残る。気持ちの持ちようだけど「そういう知見を積み上げていくことに満足を得たり価値を見出すことができるなら」挑戦する価値は充分ある。
特定の成果を目指して邁進するプロの方の感覚と、楽しみでやっているアマチュアの感覚には大きな違いがあると思います。自分が上のように思うのはアマチュアゆえだと思います。
そうですか。
考えが甘かったです。
どうもありがとうございます。
0
**回答が付いた後で編集する場合は元の内容も残しておいてください。**あるいはどこをどう修正したかが判るようにしてください。質問と回答の内容がちぐはぐになってしまっています。
題名に書かせていただいた通りPCのVRAMにアセンブリ言語でデータを書き込むことを考えた場合、
アセンブリ言語でなければならない理由は何かおありなのでしょうか。「VRAMにデータを書き込む」ことと「アセンブリ言語でプログラムを書く」ことは別次元の話なので、分けて考えないと混乱します。
Linuxの場合はOS自体がオープンソースであるため、VRAMにデータを書き込む過程をアセンブリプログラムで見れるのでしょうか？
「書き込む」部分アセンブリプログラムで見れるかをお尋ねしたいです。
オープンソースなのだから、わざわざアセンブリプログラムに変換せずともソースをそのまま読めばよろしいでしょう。ほとんどの部分はCで書かれていると思います。
それと、VRAMにデータを書き込んでいるのはドライバーなので、見るべきなのはドライバーのソースということになります。ドライバーのソースを追っていけばいずれはVRAMに書き込んでいる部分にたどり着くと思います。
当然のことながらGPUによってドライバーは変わるので、お使いのドライバーに応じたソースを入手する必要があります。ただし、ドライバーによってはソースを公開していないかもしれません。
投稿2018/03/10 03:10
総合スコア5938
解答、どうもありがとうございます。
アセンブリ言語にこだわる理由はハードウェアでどのように処理しているかなど、ハードウェアを意識したプログラムを書きたいと考えているためです。
編集前の質問を消してしまい申し訳ありませんでした。
「ドライバーのソースを追っていけばいずれはVRAMに書き込んでいる部分にたどり着くと思います。
当然のことながらGPUによってドライバーは変わるので、お使いのドライバーに応じたソースを入手する必要」
では、「使うドライバー(のソース)を用いてVRAMに書き込む」Ｃ言語プログラムが入手出来れば、アセンブリプログラムに変換してどのようにVRAMに書き込んでいるのか見れるわけですが、周りの方がおっしゃる通りアセンブリプログラムだけ見ても訳が分からなくなるので、Ｃ言語プログラムを読んでからアセンブリプログラムを見ると言った段取りを組みたいです。
ただ、使っているGPUを知るためにとりあえず、GPUで適当にVRAMを扱うＣ言語をアセンブリ言語に直してみてから、得られたアセンブリプログラムを基にいくつものGPUの種類があれどGPU構造やどのようにVRAMにデータを書き込んでいるかなどが推測できて、GPUからVRAMにデータを書き込む雛形のアセンブリプログラムができるのではないかと思います。
もちろん、使っているpcがGPUを使わずにVRAMにデータを書き込むようなものであれば、雛形を作る過程は変わってくると思いますが。
とても楽しそうです！
以上のやり方なら、ソースが公開されてなくても試行錯誤と推測で公開されていないソースと似たようなものが得られるかもしれません。
試行錯誤と推測によって得られたＣ言語、あるいはアセンブリ言語のソースからVRAMに書き込む事ができるかもしれません。
ハードウェアを意識してプログラムを書く、ということ自体は重要なことですが、どの階層のプログラムを書くかによって、せっかくの努力があまり報われない場合もあります。昔と違って、コンパイラの最適化が進化した結果、ソースコードで工夫した点があまり反映されないこともありえると思います。
なので、OSやドライバ周りのプログラミングでないなら、あまりハード制御を意識したプログラムにこだわりすぎず、メモリ利用の効率化とか、ディスクIOの低減等で工夫する方が現実的なのではないでしょうか。
なんか、便利になってくれはるのはありがたいですが、身につけた事が趣味でしか活かせないのは悔しいです。仕方ありませんが。
> Ｃ言語プログラムを読んでからアセンブリプログラムを見ると言った段取りを組みたいです。
いやいや、C言語のプログラムを見ればどのようにVRAMに書き込んでいるのかは判りますから、わざわざ手間をかけて読みにくくする必要はありません。というか、ソースにすべて書かれていますから余計なことはすべきではありません。
> もちろん、使っているpcがGPUを使わずにVRAMにデータを書き込むようなものであれば、雛形を作る過程は変わってくると思いますが。
GPUに接続されたVRAMはCPUでも直接書き込みできます。Linuxは知りませんが、WindowsのグラフィックAPIには、VRAM(API用語としてはサーフェイスメモリと呼んでいる)をCPUのアドレス空間にマッピングして直接アクセスできるようにする機能があります。CPUのアドレス空間にマッピングするので、単純なメモリアクセスになります。ただし、それはcarnage0216さんが思い描くものとは違うかもしれません。今時のPCはかなり複雑化しています。VRAMに何か書けば何か表示される、というような単純なものではありません。
> 試行錯誤と推測によって得られたＣ言語、あるいはアセンブリ言語のソースからVRAMに書き込む事ができるかもしれません。
今の状態では途轍もなく時間を浪費することになると思います。何度も繰り返している気がしますが、ソースを読み解くには前提となる知識が必要です。それ無しには、試行錯誤も推測も単なる当てずっぽうです。
まずはC/C++と画面表示や描画関連のAPIを深いレベルで理解し、使いこなせるようになることが先決です。使えもしないものの仕組みを理解するなどできようはずもありませんから。
当てずっぽうはしたくはないです。言える立場ではありませんが。
そうですね。システムコールがあるLinuxを使って勉強中なので、調べてみます。
ただ、気になったのですが、Linuxを入れたpcにはGPUは搭載されていません。
となるとGPUを使わないでディスプレイに文字を表示させるような別の機能があるのでしょうか？
CPU内蔵のGPUを使っているのでしょうね。PC向けに広く出回っているCPUには、GPUが内蔵されているものが多いです。
0
Linuxならオープンソースなので任意の場所にデバッグ出力などを埋め込むことが出来ますから、挙動を見るのは多少容易になるでしょう。アセンブラレベルで見れればよいという話なら、デバッガを使えばLinuxだろうとWindowsだろうと挙動を見ることは出来ますね。
ただし今時のプログラムでVRAMを直接読み書きするのは極めて希です。通常はGPUに命令を送って指示をだし、GPUがVRAMに対して読み書きを行います。もちろん旧来との互換性のためにVGAモードなどで直接VRAMに対して読み書きすることは可能ですが、このためにはディスプレイドライバをVGA互換などに設定しておかないと挙動を見ることは出来ません。
予備知識が全くない状態で挙動を見るのは無茶でしょうから、下記のURL等を参照して予備知識を得ることをお勧めします。
Wikipedia INT 10H
INT 10H: Video Services
またprintf等の文字列の表示に限るなら、BIOS呼び出しで出力しており、直接テキストVRAMに触っていることはないかと思います。
投稿2018/03/10 01:40
総合スコア472
0
Rasberry PI でも買ってきて、ベアメタル（OSなし）でVRAMをいじってみればどうです？
そうすればいかに自分が思い違いしてるかというのがわかると思いますが。
投稿2018/03/10 16:59
総合スコア87749
え？
ベアメタル でVRAMがいじれるのですか？
多分、取り付けたカラーLCDとかのVRAMをいじるとかですかね？
あるいは古いPCもってきてFreeDOSでも走らせれば、ふつーにVGAのVRAMいじれるやろ
コンパイルされる時は、実行プログラムとos自体がコンパイルされるので、ベアメタルをしなくても、実行プログラムとosのプログラムがコンパイルできて、VRAMをいじれれば大丈夫です。
(Linuxを入れたラズパイ上で)
そうすれば、VRAMへのアクセス、いじる雛形のＣ言語あるいはアセンブリプログラムができると思います。
そう思うなら、机上の空論でぐだぐだするよりさっさと実行しましょう。
いつまでこんな茶番をするつもりですか。
やってみて失敗するのが怖くて、実行できずにいたのです。
はい、実行します。
僕は皆様のように賢い人間ではないので難しいですが、頑張ってみます。
0
無駄にアセンブリにこだわっているようですが、C言語のポインタでハードウェアのI/Oに値を設定するのと、アセンブリのMOV命令で設定するのに本質的な差はないですよ。
また、ソフトウェアを駆使してハードウェアを制御する勉強をするなら他の方々もいっているようにARMやSHなどの組み込み向けマイコンでやった方が得られるものが多いと思います。
MMUやキャッシュ、メモリマップI/OなどPCではブラックボックスになっている部分を直接触ることができます。
ブートローダを作ったりイーサネットのTCP/IPプロトコルスタックを組んだりなど後々にすごく役に立つ経験になるはずです。
投稿2018/03/10 16:41
総合スコア1430
あの、「C言語のポインタでハードウェアのI/Oに値を設定する」はハードを意識してＣ言語を使うのですか？
まぁ、ポインタはそのための道具にも思えますが。
gccはAVRにも対応してますよd＾＾・・・私はアセンブラの方が好きですが・・・
制御対象を意識するのにCもアセンブリも大した違いはありません。
ハードウェア上のあるI/O(例えばLEDのON/OFF)のアドレスが0x54000004だったとすると、
volatile unsigned int *ptrReg = (unsigned int *)0x54000004;
*ptrPeg = 0x00000001; /* LED-ON */
*ptrReg = 0x00000000; /* LED-OFF */
みたいな感じになるでしょう。
これをアセンブリで書いてもMOV命令でI/Oのアドレスを汎用レジスタに設定して、MOV命令の間接アドレッシングでI/Oにライトするといった記述になるはずなので、書き方の違いぐらいでやりたいことに本質的な差はないでしょう。
なるほど。
LEDのON/OFFのアドレスが0x54000004ならば、そのアドレスをポインタで指定する事で、LEDのオンオフがいじれるわけですね。
gccはAVRにも対応してますよとのことですが、gccでコンパイルして得たアセンブリプログラムはAVRでそのまま使えるってことですか？
流石にそんな事はないと思いますが。
いえAVR用のgccがあります。
https://www.clarestudio.org/elec/avr/
C言語が高級アセンブラとも言われるゆえんですね。
もともとgccは、クロス・コンパイラの色が濃いコンパイラですから、m68k,m88k,vax,spark,mips・・・何でもありですねw
0
VARMで検索すればいくらでも情報が得られると思いますが、printf(アプリケーションによる文字出力)とVRAMとは直接結びついているわけでは有りません。大雑把に言うと、アプリ→システムコール（ドライバ？）→GPUに依頼→VRAMに文字の形のビットマップを作成して描画。ちょっと違うかもしれませんが、GPUによってVRAMの位置も違うしDMAの操作も違う。それをうまくやるのがドライバの役目ですd＾＾・・・昔Z80の頃はVRAMに直接描けたんですが；；・・・そもそも特権命令を使うアプリを実行できるのだろうか？？
投稿2018/03/10 00:42
編集2018/03/10 01:13総合スコア6851
あなたの回答
tips
プレビュー
