電装工芸日記
- 舞台照明機器の製作とか -
2022年の投稿(時系列順)［394件］（40ページ目）
2022年12月 この範囲を新しい順で読む この範囲をファイルに出力する
Ｃ言語を習得する壁として代表的な機能は、
１）ポインタ
２）構造体、共有体
３）typedef（自分なりの変数の型を定義する）
でしょうか。
ポインタは以前も書きましたが、変数をアドレス値で読み書きする方法です。CPU、メモリ、デバイスというハードウェアの基本要素が頭に入ってないと捉えにくいのですが、わかればシンプルだと思います。
構造体はPythonで言うところのタプルみたいなものです。
共有体は機能はわかっても意味がイマイチピンときませんが、高度なことを書く際に便利なのでしょう。
typedefにはじんわりとオブジェクト指向を感じますが、データベースにアクセスするなど、構造体を多用する際に便利な気がします。
他は計算記述とループコマンドですが、これらは方言のレベルで受け入れればいいようです。配列に対する計算はPythonと少し違うみたいなので整理が必要です。
要所の基本は理解できたっぽいので、とにかく書いて慣れることですね。
呆れる程書いて体に馴染ませたPICのアセンブラ並にＣ言語を書けるようになれたら御の字です。
実習はこれからですが、共有メモリも見えてきました。
名前のままですが、複数のプロセスからアクセス(共有)できるメモリ領域を定義する方法です。
mmap(メモリマップドファイル)とかpipeに似ていますが、mmapはRAMディスク上のファイルを共有するイメージで、pipeは変数の内容をシステムを通じて送受信するイメージです。どれもプロセス間で情報を共有する手段ですが、共有メモリはこの中でもローレベルでシンプルな方法だと思います。ローレベルすなわち速度が期待でき、最初の定義は面倒だけど定義さえ済めば単なる変数として扱えます。
今時のOSは特定のプロセスがアクセスできるメモリ領域を制限することで動作の安定とセキュリティ(セキュア)を担保します。このため、別プロセスの領域にある変数(メモリ)にはポインタを使ってもアクセス出来ないのです。
MS-DOSなどの初期のＯＳではありえなかった制限ですが、利便性とセキュアは矛盾するシステム要件ですから、抜け道として共有メモリが用意されたのしょう。アクセスが許可されたプロセスからはただのメモリ領域ですからポインタで普通に読み書き出来ます。動作速度が通常変数と大差ないのも嬉しい。
共有メモリを定義して得られる情報はID、先頭アドレス、メモリサイズ、パーミッションだけです。OSやコンパイラがマネージしてくれない変数ですから、メモリに展開する構造体を手作業で管理しなければなりません。読み書きもマネージしれくれませんので、プロセス間で動作が衝突して誤動作に繋がる可能性があるので、セマフォを使うなり、データを一方通行にするなりして対策する必要もあります。この辺りはPICのアセンブラと同じですけどね。
学んでて思うのですが、Ｃ言語はアセンブラを抽象化して書きやすくしたものだとするのが私には自然です。アセンブラを補助するマクロ集を膨らませていったらマクロ命令だけでもプログラムソースが書けるようになってしまい、ならばマクロの内容を整理したら更に便利ぢゃね？となったんじゃないかと勝手に想像しています。プログラム言語としてJAVAやPythonと同類に位置付けされますが、性根のところでは別分野の代物なんですよ。学ぶ側にとっては、俗に言う高級言語に分類するから逆に理解し難いんだと思うのです。ハードウェアが直に読むマシンコードを便利マクロだけで書くと思えばポインタなどは超お気楽な便利機能に見えてきます。
つーて、アセンブラとかマシンコードって何？って聞かれてしまうと困ります。色彩をカラーフィルターの番号と光源のレベルで例えてしまう照明屋の言葉が一般には通じないことと同じです。
#Ｃ言語
１）ポインタ
２）構造体、共有体
３）typedef（自分なりの変数の型を定義する）
でしょうか。
ポインタは以前も書きましたが、変数をアドレス値で読み書きする方法です。CPU、メモリ、デバイスというハードウェアの基本要素が頭に入ってないと捉えにくいのですが、わかればシンプルだと思います。
構造体はPythonで言うところのタプルみたいなものです。
共有体は機能はわかっても意味がイマイチピンときませんが、高度なことを書く際に便利なのでしょう。
typedefにはじんわりとオブジェクト指向を感じますが、データベースにアクセスするなど、構造体を多用する際に便利な気がします。
他は計算記述とループコマンドですが、これらは方言のレベルで受け入れればいいようです。配列に対する計算はPythonと少し違うみたいなので整理が必要です。
要所の基本は理解できたっぽいので、とにかく書いて慣れることですね。
呆れる程書いて体に馴染ませたPICのアセンブラ並にＣ言語を書けるようになれたら御の字です。
実習はこれからですが、共有メモリも見えてきました。
名前のままですが、複数のプロセスからアクセス(共有)できるメモリ領域を定義する方法です。
mmap(メモリマップドファイル)とかpipeに似ていますが、mmapはRAMディスク上のファイルを共有するイメージで、pipeは変数の内容をシステムを通じて送受信するイメージです。どれもプロセス間で情報を共有する手段ですが、共有メモリはこの中でもローレベルでシンプルな方法だと思います。ローレベルすなわち速度が期待でき、最初の定義は面倒だけど定義さえ済めば単なる変数として扱えます。
今時のOSは特定のプロセスがアクセスできるメモリ領域を制限することで動作の安定とセキュリティ(セキュア)を担保します。このため、別プロセスの領域にある変数(メモリ)にはポインタを使ってもアクセス出来ないのです。
MS-DOSなどの初期のＯＳではありえなかった制限ですが、利便性とセキュアは矛盾するシステム要件ですから、抜け道として共有メモリが用意されたのしょう。アクセスが許可されたプロセスからはただのメモリ領域ですからポインタで普通に読み書き出来ます。動作速度が通常変数と大差ないのも嬉しい。
共有メモリを定義して得られる情報はID、先頭アドレス、メモリサイズ、パーミッションだけです。OSやコンパイラがマネージしてくれない変数ですから、メモリに展開する構造体を手作業で管理しなければなりません。読み書きもマネージしれくれませんので、プロセス間で動作が衝突して誤動作に繋がる可能性があるので、セマフォを使うなり、データを一方通行にするなりして対策する必要もあります。この辺りはPICのアセンブラと同じですけどね。
学んでて思うのですが、Ｃ言語はアセンブラを抽象化して書きやすくしたものだとするのが私には自然です。アセンブラを補助するマクロ集を膨らませていったらマクロ命令だけでもプログラムソースが書けるようになってしまい、ならばマクロの内容を整理したら更に便利ぢゃね？となったんじゃないかと勝手に想像しています。プログラム言語としてJAVAやPythonと同類に位置付けされますが、性根のところでは別分野の代物なんですよ。学ぶ側にとっては、俗に言う高級言語に分類するから逆に理解し難いんだと思うのです。ハードウェアが直に読むマシンコードを便利マクロだけで書くと思えばポインタなどは超お気楽な便利機能に見えてきます。
つーて、アセンブラとかマシンコードって何？って聞かれてしまうと困ります。色彩をカラーフィルターの番号と光源のレベルで例えてしまう照明屋の言葉が一般には通じないことと同じです。
#Ｃ言語
マルチプロセスについて調べていました。
fork()、exec()、共有メモリをセットで使えば良いようです。
Linuxプロセスの生成と実行 fork／exec
fork()は現プロセスを別プロセスに完全コピーします。実行状態も含めてです。同じプログラムが別々のプロセスでfork()を実行する直前のコンディションで並列実行されますが、自身がコピーされた子プロセスなら別プロセスで実行したいプログラムをexec()で起動するというもの。exec()で別プログラムを起動すると呼び出したプログラムは終了しますので、結果として別プロセスで別プログラムが起動したことになります。共有メモリなどの設定を済ませてからfork()を実行すれば、共有メモリの情報を別プロセスの別プログラムに簡単に渡せるのでスマートです。
以下、いささか愚痴ですし、教えを頂いている立場が言うことではないのですが、fork()、exec()、共有メモリがセットであることに触れずにfork()だけを切り取った情報が多いこと多いこと。ゴッタ煮説明が理解しにくいのは事実ですが、fork()だけではfork()の意味すらわからないと思うのです。私と同じことを調べている方がいたら、exec()に触れずにfork()だけを力説している情報は読み飛ばした方がいいと思います。もちろん、瞬間的に計算能力を増やすのにサブルーチン的な別プロセスを使う方法あるのでexec()を用いずfork()と共有メモリで組むこともあるとは思いますけど。
マルチプロセスというとfork()単独の話ばかりが目につきますが、共有メモリをキーに掘り下げたところfork()、exec()、共有メモリの３点セットが理解出来たところです。
話を戻しますが、共有メモリの情報を別プロセスに渡す方法も含め、具体的に解決した感じです。
これなら、複数ある機能のどれかから別機能のプロセスを起動するより、必要な機能の全プロセスを起動するだけのメインプログラムを書いた方が管理しやすいような気がします。共有メモリなどを設定し、機能ごとのプロセスを起動していく最初に起動するプログラムです。一種のランチャーですね。
うーん、やっぱりＣ言語は高級言語というよりアセンブラ風味だなぁ。
#Ｃ言語
fork()、exec()、共有メモリをセットで使えば良いようです。
Linuxプロセスの生成と実行 fork／exec
fork()は現プロセスを別プロセスに完全コピーします。実行状態も含めてです。同じプログラムが別々のプロセスでfork()を実行する直前のコンディションで並列実行されますが、自身がコピーされた子プロセスなら別プロセスで実行したいプログラムをexec()で起動するというもの。exec()で別プログラムを起動すると呼び出したプログラムは終了しますので、結果として別プロセスで別プログラムが起動したことになります。共有メモリなどの設定を済ませてからfork()を実行すれば、共有メモリの情報を別プロセスの別プログラムに簡単に渡せるのでスマートです。
以下、いささか愚痴ですし、教えを頂いている立場が言うことではないのですが、fork()、exec()、共有メモリがセットであることに触れずにfork()だけを切り取った情報が多いこと多いこと。ゴッタ煮説明が理解しにくいのは事実ですが、fork()だけではfork()の意味すらわからないと思うのです。私と同じことを調べている方がいたら、exec()に触れずにfork()だけを力説している情報は読み飛ばした方がいいと思います。もちろん、瞬間的に計算能力を増やすのにサブルーチン的な別プロセスを使う方法あるのでexec()を用いずfork()と共有メモリで組むこともあるとは思いますけど。
マルチプロセスというとfork()単独の話ばかりが目につきますが、共有メモリをキーに掘り下げたところfork()、exec()、共有メモリの３点セットが理解出来たところです。
話を戻しますが、共有メモリの情報を別プロセスに渡す方法も含め、具体的に解決した感じです。
これなら、複数ある機能のどれかから別機能のプロセスを起動するより、必要な機能の全プロセスを起動するだけのメインプログラムを書いた方が管理しやすいような気がします。共有メモリなどを設定し、機能ごとのプロセスを起動していく最初に起動するプログラムです。一種のランチャーですね。
うーん、やっぱりＣ言語は高級言語というよりアセンブラ風味だなぁ。
#Ｃ言語
書き方を考えています。
PICマイコンを書く場合は、表面の機能からではなく、全体の構造からまとめていくからです。
表面的な機能だけで装置は動きません。これらを後回しにすることを推奨するのではありませんが、機能と機能を能動的に結びつけなければ結果に至らないからです。
DMXのディマーも、DMXを受信するだけでなく、アドレスを設定したり、ACの波長とゼロクロスポイントを取得したり、得た情報を結びつけて適切なタイミングでSCRをON/OFFしなければなりません。
PICにおいてはハードウェアモジュールの割り込みフラグを用いるのは当然としても、１個のタイマーで複数の実行タイミングを生成出来なければなりません。タイマーはほんの数個しかありませんので、実行モジュール毎にタイマーを割り付けてタイムアップを取るのは不可能だからです。細かい構造は割愛しますが、環境に合わせた工夫を仕込んでおかないと動くモノも動かないのです。
PICとは事情が違いますが、RaspberryPiを開発するなら複数のCPUスレッドに仕事を分散させて処理能力を出来るだけ引き出さないといけません。
PythonでもＣ言語でも、プログラムをマルチスレッド化するだけならプロセスは一つでありCPUスレッドは１つしか使われません。CPUスレッドを振り分けるのはOSの仕事でプログラムの記述で指定することは出来ないようですが、CPUスレッドを最大限利用するにはマルチプロセスで書くことが最低条件となるようです。
マルチプロセス化する方法はいくつかありますが、プロセスとプロセスの間に継承と共有をする情報があるならば工夫が必要です。これらを都度の例外とするのは開発においてもメンテナンスにおいても効率が良くありませんので、継承と共有の仕組みを最初から作っておくのが良いと思います。
これから取り組もうとしている工夫は正にコレです。この仕組みがまとまればＣ言語での開発が飛躍的に発展します。
#Ｃ言語
PICマイコンを書く場合は、表面の機能からではなく、全体の構造からまとめていくからです。
表面的な機能だけで装置は動きません。これらを後回しにすることを推奨するのではありませんが、機能と機能を能動的に結びつけなければ結果に至らないからです。
DMXのディマーも、DMXを受信するだけでなく、アドレスを設定したり、ACの波長とゼロクロスポイントを取得したり、得た情報を結びつけて適切なタイミングでSCRをON/OFFしなければなりません。
PICにおいてはハードウェアモジュールの割り込みフラグを用いるのは当然としても、１個のタイマーで複数の実行タイミングを生成出来なければなりません。タイマーはほんの数個しかありませんので、実行モジュール毎にタイマーを割り付けてタイムアップを取るのは不可能だからです。細かい構造は割愛しますが、環境に合わせた工夫を仕込んでおかないと動くモノも動かないのです。
PICとは事情が違いますが、RaspberryPiを開発するなら複数のCPUスレッドに仕事を分散させて処理能力を出来るだけ引き出さないといけません。
PythonでもＣ言語でも、プログラムをマルチスレッド化するだけならプロセスは一つでありCPUスレッドは１つしか使われません。CPUスレッドを振り分けるのはOSの仕事でプログラムの記述で指定することは出来ないようですが、CPUスレッドを最大限利用するにはマルチプロセスで書くことが最低条件となるようです。
マルチプロセス化する方法はいくつかありますが、プロセスとプロセスの間に継承と共有をする情報があるならば工夫が必要です。これらを都度の例外とするのは開発においてもメンテナンスにおいても効率が良くありませんので、継承と共有の仕組みを最初から作っておくのが良いと思います。
これから取り組もうとしている工夫は正にコレです。この仕組みがまとまればＣ言語での開発が飛躍的に発展します。
#Ｃ言語
2022年の大晦日です。
コロナの感染拡大は完全に収まりはしなかったものの、仕事ではその影響も和らぎ忙しくさせて頂いた一年でした。
ご協力を頂いた各方面の方々に改めて感謝申し上げます。
ただ、体力的には過負荷が続いたもので、年末休暇に入ってからの２日間は完全にシャットダウン。大晦日の今日になってようやく普通に戻ってきた感じです。
年末にやるべきことの大半が出来ませんが、少しはこなして実家にも顔を出しましょう。
Ｃ言語の書き方は妄想だけなので合間に少し進めます。
#雑談
コロナの感染拡大は完全に収まりはしなかったものの、仕事ではその影響も和らぎ忙しくさせて頂いた一年でした。
ご協力を頂いた各方面の方々に改めて感謝申し上げます。
ただ、体力的には過負荷が続いたもので、年末休暇に入ってからの２日間は完全にシャットダウン。大晦日の今日になってようやく普通に戻ってきた感じです。
年末にやるべきことの大半が出来ませんが、少しはこなして実家にも顔を出しましょう。
Ｃ言語の書き方は妄想だけなので合間に少し進めます。
#雑談