アプリ版:「スタンプのみでお礼する」機能のリリースについて

システムコールはアセンブリプログラムで書いてあるのですか?
というより、システムコールよりコールされたプログラムはアセンブリプログラムで書いてあるのですか?
また、そのアセンブリプログラムを見る事は出来るでしょうか?
そして、仮にそうならば、そのアセンブリプログラム実装する事でシステムコールされた時と同じ働きをしてくれるのでしょうか?
えーと、システムコールを経由しなくてもシステムコールと同等のものを作ってしまえばシステムコールを呼ばなくて良いのかどうかを質問したいです。
例えば、文字を表示するシステムコールを逆アセンブルしてアセンブリプログラムを見る。その後に、そのアセンブリプログラムをそのままコピペして実行することで文字を表示できるのでしょうか?
osはLinuxとします。WindowsではAPIなどがブラックボックスとなっており、いじったりできないためです。
わかりにくいかもしれませんがどうかよろしくお願い致します。

質問者からの補足コメント

  • うーん・・・

    あるいは、システムコールを利用しないで文字を表示したり、ファイル操作を行う事は可能でしょうか?

      補足日時:2018/04/10 16:32

A 回答 (10件)

「osはLinuxとします。

WindowsではAPIなどがブラックボックスとなっており、いじったりできないためです。」ということは, 逆にいえば
Linux なら全部見える
ということだ. つまり, あなただって*その気になれば*調べられるわけだから, 少なくとも「そのアセンブリプログラムを見る事は出来るでしょうか?」については明確に YES と答えられる.
    • good
    • 1
この回答へのお礼

んー。システムコールを経由しないで文字やファイル操作をしたいのですが可能ですか?

お礼日時:2018/04/10 16:52

プログラムを書くのは、今の時代高級言語です。


アセンブリプログラムを見る事は、アセンブラの出力を見ればよいです。

> システムコールを経由しなくてもシステムコールと同等のものを作ってしまえばシステムコールを呼ばなくて良いのかどうかを質問したいです。
⇒ システムコールとは、システム関数を使う(起動する)ことを言い、
その指定方法(手順)ではありません。

逆アセンブルは、可逆性が保証されないので、注意してください。
Print asc(*)で文字表示できると思います。言語記述仕様でご確認ください。

ことば酔い?みたいな感じでしょうか?
    • good
    • 0
この回答へのお礼

そうなのですか。どうもありがとうございます。
私はコールされるシステム自体はプログラムでできていると考えていたため、実行したいプログラムとそのプログラムが呼び出すシステムをコピペして貼り付ければ、システムコールを呼び出して実行ファイルを出力するプログラムと同等なものが作れると思っていました。

お礼日時:2018/04/10 17:28

システムのリソース管理をやってるいまどき普通のOSだったら、システムコールと言うかAPIのコードを丸コピしても動きません。

システムリソースへのアクセスは特権モードで行うので、ユーザープログラムが稼働しているモードから特権モードに移行するわけですが、それを無秩序に許したのではOSが知らないところでリソースが使われていて、いざOSが使おうとしても空いてない…なんてことが起きます。保護違反エラーですね。なのでそんな無茶は許されません。

ユーザーの好き勝手にシステムリソースにアクセスしたければ、OSを使うのをやめることです。DOSならそのへんはぜんぜん管理してないも同然だから、そうしたプログラミングにはぴったりです。
    • good
    • 0
この回答へのお礼

あるいは、既にあるシステムコールを自分なりにアレンジして、あるいはそのまま(2)などと置いて新しいシステムコールとして置く。その自作したシステムコールならば、書き込みが可能なのでしょうか?

お礼日時:2018/04/10 18:21

OSがいる場合はコードだけの問題じゃなく、メモリ管理の問題にも立ち入る必要があります。



特権モードで動作するプログラムは、ユーザープログラムが配置されるのとは別のメモリ空間上にあり、そこに配置される必要があります。しかしそこにはOSの許可なく立ち入ることはできないし、うっかり触ることもできません。つまり丸コピしてユーザープログラムの領域に置いても動作しないし、特権モードの領域に配置することも通常はできません。

先の回答に書いた、「ユーザーの好き勝手にシステムリソースにアクセスしたければ、OSを使うのをやめろ」ってのはそういう意味でもあるのです。OSってがんじがらめに束縛してるんですよね。
    • good
    • 0
この回答へのお礼

どうもありがとうございます。
大人しくシステムコールを利用します。

お礼日時:2018/04/10 20:54

恐らくOSの存在意義とシステムコールの必要性を理解されていません。



OSの唯一絶対のこれを外したら存在意義がなくなってしまうと言う事があります。
それはメモリ保護です。
メモリ保護とは、「自分のプロセス用に割り当てられたメモリを好き勝手にする分には良いけれど、他のプロセスとやり取りしたりハードウェアを使う時は、OSに調停を頼んでね」というルールをすべてのプロセスに強制する事です。
例えば、プロセスAがプロセスBが使っているハードウェアに勝手にアクセスしに行ったらプロセスBは想定外のデータを受け取ることになりますし、プロセスAがプロセスB用に割り当てられたメモリを勝手に書き換えてしまえばプロセスBは暴走する事にあります。
こういったトラブルを防ぐ為にこのようなルールの強制が行われます。

しかし、カメラを使いたかったり、ファイルを使いたかったり、ネットワーク経由でWebページを取得してきたかったり、ディスプレイにウィンドウを表示したかったり…自分のプロセス用に割り当てられたメモリ上だけでは収まらない事が沢山あります。
その時に、OSに調停を依頼する"依頼"の手続きこそがシステムコールです。
ですから、システムコールは勝手な追加や勝手な変更は許されません。
ルール違反をすれば一発でレッドカード強制退場です。

一方でLinuxやFreeBSDなどソースコードが入手可能なOSであればそのソースコードを変更してオリジナルのカーネルをコンパイルする事でオリジナルのシステムコールを持った環境を作ることは可能です。
ただ、システムコールは処理内容があまりに低級で大抵のプログラマにとって理解する事さえ困難な内容になっています。
例えばファイルオープンのうち、パスからファイルIDに変換する前段としてのパーティション情報の取得でさえ、メモリコントローラをを呼び出すために、レジスタに値をセットするから始まります。
その後、メモリコントローラが応答しない、応答はしたが結果が破損している、電圧が足りないと言っている、自己診断の結果がおかしいと言っている等いろいろなエラー処理が行われ、その後メモリモジュール、ATAコントローラ、ディスクコントローラに対しても同じように様々なエラーの処理が行われます。
漸くプラッタに到達したと思ったら、モーターへの入力と実際のプラッタの回転数が一致しない、プラッタが偏心していてトラックを追跡できない、装置したセクタの長さと一致しない、磁器が弱すぎて読み取れないといったデジタルとは程遠い絶賛物理法則エラー祭りに突入します。
挙句の果てに、ヘッダは1セクタが読めたけど、ディスクコントローラが、ATAコントローラが、メモリモジュールが、メモリコントローラが…ともう1回やってCPUが中身を精査できるようになります。

システムコールは内容がコンピュータを使う上で考えたこともない様なトラブルに、リトライを繰り返して、それでもだめならエラーコードに変換する処理を延々繰り返しています。
大抵のプログラマにとって何を想定すれば網羅できているのかさえイメージする事ができない対象ですので、そういうものだと思って使った方が幸せになれます。
    • good
    • 2
この回答へのお礼

すごくわかりやすいです。
勉強になります。それを考えたら下手にシステムコールはいじらない方が良いですね。仮に書き込めたとしても。

お礼日時:2018/04/11 20:48

う~ん、Linuxにしろ、Windowsにしろ、複数のプログラムがリソースをシェア


しながら、安全かつ簡単に動く仕組みを提供してるので、
そういうのを無視したければ、システム全部自作すれば良い。

arduino とか、PICとか、H8とかああいう世界は嫌いですか?

画面にたったひと文字だす為に、四苦八苦しなければ
いけませんが、全て自分で制御出来ます。
    • good
    • 0

まず、システムコールの実装を知りたければLinuxのソースコードを見てください。


Linux kernelは下記から取得できます。
https://www.kernel.org/

また、デバイスに対する直接アクセスは、OSを利用しなければ如何様にも作ることはできます。私も、家庭用パソコンにOSなんてものがない時代には、プリンタを使って封筒に親父の会社の住所を印刷するみたいなゴミみたいなプログラムをアセンブラを使って作っていました。

一番最初に躓くのは、コンピュータにプログラムを読み込ませる部分ですが、IPL(Initial Program Loader)についての知識があればなんとかなります。簡単に言えば、外部記憶デバイスの特定の位置に書き込まれた決まったサイズのデータをメモリの決まった番地に読み込み、決まった番地からプログラムを実行する、たったこれだけの話です。
その他のデバイス制御も、基本はデバイスが接続されたIOポートに値を書き込むだけです。最近のPCやサーバでややこしいのは、いろいろな規格化されたポートに何が接続されるかわからないのでそれを正しく認識する必要があるのですが、ハードウェア構成を完全に固定するならそのハードウェア構成専用のプログラムを作ることはできると思います。もちろん、デバイス(メーカーや型番)によって書き込む値や作法は違います。この情報(データシート)は、各デバイスメーカーから公開されているものは公開されていると思います。ちなみに、この部分を、OSでは「ドライバ」と言って、同種のデバイスには規格化されたインタフェースでアクセスできるように工夫されており、デバイスメーカーはそのデバイスに合ったドライバを提供しています。

これらはわかってしまえばある程度自力でできますが、個人的な意見として、プログラムの実行時間が遅いから自前のプログラムで高速化を図るなどという努力をしている時間の方が無駄だと思います。コンピュータはプログラミングによってCPUを操作しているような錯覚がありますが、実際には接続された機械の操作手順に従った機械制御のかたまりです。逆アセンブルするという発想自体が、システムコールを使うことと何ら変わりがないということを理解してください。
    • good
    • 0
この回答へのお礼

逆アセンブルする発想がシステムコールを使うことと同じとはどのような意味でしょうか?是非理解したいので、もう少しわかりやすく説明して頂けないでしょうか?
お願い致します。

お礼日時:2018/04/11 20:46

> システムコールよりコールされたプログラムはアセンブリプログラムで書いてあるのですか?


たぶん大部分はC言語でしょう。本当にごく一部の低水準のところにはアセンブリ言語も使われるでしょうけれど。
    • good
    • 0

No.7です



まず、当初のご質問の文意を理解していませんでした。失礼しました。

>システムコールを経由しなくてもシステムコールと同等のものを作ってしまえばシステムコールを呼ばなくて良いのかどうかを質問したいです。

これは、OS上でユーザプログラムを動作させる以上、できないと考えてください。

現代のコンピュータは、OSに対してリソース保護機能をサポートするために、プログラムの動作レベル(「リング」と呼ばれるもの)が設定されています。カーネルは特権レベルで動作するようになっていて、ユーザプログラムはOSによってユーザレベルで動作するように作られています。特権レベルではすべてのインストラクションを実行可能ですが、ユーザレベルでは制限があります。デバイスアクセスもその一つです。仮にシステムコールによってなされる処理をユーザプログラム上で実装した場合、システムコールされた先で実行される命令のいくつかはこの制限に抵触することがあるため、ユーザプログラムの中に組み込んでも動作しない場合があります(そもそもシステムコールはそういう操作を行うためのものなので、実質すべて制限に抵触すると考えても差し支えないでしょう)。


以下は、お礼文にあるご質問への回答です。

>逆アセンブルする発想がシステムコールを使うことと同じとはどのような意味でしょうか?

入出力処理を逆アセンブルして、その結果をどのように使いますか?自分のプログラムにその処理を組み込むだけであれば、結局標準関数などを呼ぶことと大差はないですよね?CPUは、一連の機械語で書かれたプログラムに書かれた処理を順に実行する機能を持っているだけなので、自分のプログラムとして作成されようが、ライブラリに収録されているプログラムであろうが、Cで書いたものをコンパイルしようが、コンパイル結果と同等の処理となるようアセンブリ言語で書いたものをアセンブルしようが、同じ処理であれば同じように動作します。
ちなみに、システムコールを実行することは、実際にはユーザプログラム外のプログラム(カーネルのことですが)に処理を依頼する(引き渡す)手順を踏むことになりますので、この処理の流れはもうちょっと複雑になりますが、言わんとしていることはご理解いただけるでしょう。なお、OSを利用せずに自前のプログラムだけでコンピュータを操作するならば、システムコールによる処理引き渡しの手順(これをカーネルオーバヘッドと言います)ぐらいはスキップできるでしょう。

もしくは、ディスアセンブルした結果をさらに最適化しようとしていますか?最近のコンパイラの最適化技術を侮ってはいけません。昔から知られている基本的な小手先技術(0代入はXORを使うだとか、定回数ループはアンローリングするだとか、関数はコールするのではなくインラインに展開してしまうだとか)だけでなく、できるだけメモリアクセスを減らしたり、分岐コスト(特にミスペナルティ)を低減するような局所的コードの再配置をしてくれたり、その他いろいろな技術で高速動作するような最適化がなされます。もちろん、それをも凌駕する知識と技術を持ち合わせているならさらなる最適化は可能かもしれませんが、今や我々凡人の実力では歯が立たないレベルになっています。
    • good
    • 0

>えーと、システムコールを経由しなくてもシステムコールと同等のものを作ってしまえばシステムコールを呼ばなくて良いのかどうかを質問したいです。



 OSの仕事をユーザプログラムが勝手にやっては行けません。昔の文字だけを印刷するプリンタを考えて下さい。
 2箇所から勝手に文字を送ったら、チグハグな印刷に成ってしまいます。
 仕事でも営業とか上司の人を通さずに勝手にやると、管理できません。
 窓口として、システムコールを通さないと行けません。
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!