制御系なら俺に聞いてもいいぜ（６）

制御系なら俺に聞いて ..

437:379
05/01/05 14:57:24
>>434
>自分だけの立場でものを考えてはだめだ。
>要するに、顧客の立場でも考えるべきだ。
そんなのは当たり前の話だけどな、別に学校の講義を受けるつもりはないので（ｒｙ
逆に「スタンダードな規格」での不都合な点もいうべきではないかな

>>432　の場合なんか、どうする？
「スタンダードな規格」で納めたが、絶縁などの問題などが発生。
スタンダードだからあきらめろというのか？

>>430で言ったように、どれにもこだわってはいけないと思うが。

438:379
05/01/05 15:11:46
>>432
医療機器なんかの場合、高周波系と混在すると絶縁対策が原因で
暴走の危険性があるが、パソコンベースのシステムで対応できると思えない。

また、>>398のケースで、
強電界下での使用ということに対する暴走対策、
電源の断接でリセットスタートさせるがその応答を２秒以内
こういうことにパソコンベースのシステムで対応できるのか？

439:デフォルトの名無しさん
05/01/05 15:57:35
実験機がなぜダメなのかというと、実験のために関係ない部分まであちこちいじり
倒しているうえに、なんだか変なジャンプ配線ばかりだったり、場合によっては
ユニバーサル基板で作ってあったりして、とにかく信頼性が低い。
関係ある部分だけ抽出して試作品を作り、うまくいったらちゃんとした物をつくる、
ってしないと。

440:379
05/01/05 16:39:05
すくなくとも、
マイコンしかやったことがないからマイコンでとか
パソコンしかやったことがないからパソコンで
ＰＬＣしか（ｒｙ
という技術者にはなりたくない。

441:ライブラリアン
05/01/05 17:04:39
＞４７３

＞そんなのは当たり前の話だけどな、
＞別に学校の講義を受けるつもりはないので（ｒｙ

申し訳ない、偉そうに書いて。（笑

442:ライブラリアン
05/01/05 17:10:01
この話題をこれくらいにしてもっと面白い
テーマはないかな。

443:デフォルトの名無しさん
05/01/05 17:22:12
>>442
なんでお前が仕切ってるんだよ

444:デフォルトの名無しさん
05/01/05 20:14:25
>>434
パソコンだけじゃ制御の役に立たないでしょ？
何か入出力ポートが必要でしょ？
で、結局はその入出力ポートの実現の部分で　スタンダードな規格　が無いんだよね。

だから、パソコンは標準であっても、納品したものは標準じゃないわけだ。

445:デフォルトの名無しさん
05/01/05 20:19:14
ラックマウント → FA というロジックは面白いと思いました。

446:デフォルトの名無しさん
05/01/05 20:48:57
俺が仕切ってやるぜ

447:デフォルトの名無しさん
05/01/05 22:29:51
アルゴリズムとライブラリアンは同一人物？

448:デフォルトの名無しさん
05/01/05 22:37:16
PC使う方に一票
なんかPCのボードが生産中止になったら・・・みたいな話が出てるけど
そういう心配はむしろ自社ハードにこそいえるのでは？

マイコンも周辺チップもどんどん新旧交代して修理しようにも互換品がない、
なんてこと結構ありがちだと思うんだけど。

あとソフトの価値が認められるようになってきているって意見があったが
これはむしろ時代に逆行した意見だろう。
ソフトの貨幣的な価値なんてむしろどんどん下がってきてるでしょ。

449:デフォルトの名無しさん
05/01/05 22:51:57
>>418
> >>415
> そのシステムで書き込み途中に電源落とされたらどうなるわけ？

ＦＡだとそこまで対策してるのは見たことないよ
取説に「書込中は電源を切らないでください」でおしまい
もしそこまで気にするならバックアップメモリやHDDも二重にするしかないんじゃないの？

450:379
05/01/05 23:59:08
>>448
>マイコンも周辺チップもどんどん新旧交代して修理しようにも互換品がない、
>なんてこと結構ありがちだと思うんだけど。
自社物だと、DISCON品がどこかにあってなんとか対応できるが
メーカ物は、電源ユニットひとつでも終わったらホントにおしまい。

451:デフォルトの名無しさん
05/01/06 07:51:16
>>448
PCのボードってI/OとかADC/DACの事だよね？
リスクとしてはこっちの部品がが無くなる事と等価だよ。
それ以上に、他社である分それが起きた時の問題は厄介だ。
ようは対応出来ない。（対応出来ない事を利用に新規にしちゃうワザもあるだろうけどね）

たぶん、PCのボードを勧める人は　今1チップマイコンの内蔵RAM・フラッシュがどれだけ
あるか、そして、どれだけ簡単か知らないんだろうと思う。
URLﾘﾝｸ(akizukidenshi.com)
URLﾘﾝｸ(www.oaks-ele.com)
みたいな所からボード買って勉強してみればいい。

外付けにフォトカプラなり、オペアンプなりをつなぐだけで大抵のシステムは完成だ。
パソコンを使うなら、これをRS232CやLANで接続すればいい

まあFAで使うような場合は、そんなボード使わなくてもシーケンサ＋パソコンで間に合うのも事実だけどね。

452:デフォルトの名無しさん
05/01/06 12:40:32
>>451
あははー　ゆかいゆかい

453:ライブラリアン
05/01/06 12:41:20
＞４５１

ＯＡＫＳは思い出した。ありがとう。
自分もアマチュア精神が旺盛なので、こんなのをみると
結構ワクワクする。ただビジネスで考えると
また違う考えだけどね。
ワンボードマイコンを使う機会は無いことはない。
お客がどうしてもと言えばそうする。
ただＣＰＵの種類が多すぎるので勉強して使う
のにリスクが多い。

＞FAで使うような場合は、そんなボード使わなくても
＞シーケンサ＋パソコンで間に合うのも事実だけどね。

そうなんだ。実はこれは優れたソリュウションなんだ。
シーケンサはイーサネットでパソコンのＩ／Ｏボードの代用だ。
プログラミングはしない。シーケンサーは
ノイズに強いし売れているメーカを使えば、安心。
原子力関係では制限があるようだけど。
さらに仕事の終盤になると安全性の対応でプロテクトをかけたり、
非常停止の問題がでてくる。
それはシーケンサのプログラムだけで簡単に
対応できる。

454:379
05/01/06 14:15:57
>>453
>ただＣＰＵの種類が多すぎるので勉強して使う
>のにリスクが多い。
それほど大変じゃない。
H8で作ったシリアルやタイマーなどのルーチンは
そのままSH1やSH3で使えるほどファミリーは同じようなアーキテクチャーになっている。

ＰＬＣ(シーケンサはミツビシの商標ね)の場合
モデムで発呼とか端末側起動のシリアル通信が面倒じゃないだろうか？
っていうかできるのか？

455:379
05/01/06 14:32:05
引用ばかりですまんが
>>451
>それ以上に、他社である分それが起きた時の問題は厄介だ。
>ようは対応出来ない。（対応出来ない事を利用に新規にしちゃうワザもあるだろうけどね）
実際、そういうことが多い。

むりやり、パソコンでやろうとする姿勢はどうも賛同できない。
部品点数が多いだけでも信頼性に問題があるとおもうし
振動試験や絶縁試験にも合格すると思えない。
それだけ適応が狭くなる。
というか、そもそも　ライブラリアン氏は、そういうケースの仕事はあまり多くない？
どうも、私の世界と違うように感じる。

456:デフォルトの名無しさん
05/01/06 14:49:39
まあ、用途によるってこった

457:デフォルトの名無しさん
05/01/06 15:29:30
>>454
そういうのは一度作っちゃえばパソコン側はそれでOK
自分はパソコン関係はDelphiで作ってるから、通信部分をコンポーネントにしてて
再利用はポトペタ一発だ。

458:379
05/01/06 18:21:38
>>457
いや、端末側起動といったのは、
ＰＬＣからモデムをコントロールしたりということ

459:デフォルトの名無しさん
05/01/06 19:27:05
どこで質問すればよいのか分からなかったのでここで教えてください。

論理回路のことなんですが・・・
2進数どおしの加算は半加算回路・全加算回路で出来ます。
積算はどうやってするのですか？

ＨＥＬＰ　ＭＥ～

460:デフォルトの名無しさん
05/01/06 19:47:41
もっとも簡単な10進カウンタを作る
URLﾘﾝｸ(tamuro.gooside.com)
URLﾘﾝｸ(tamuro.gooside.com)

461:デフォルトの名無しさん
05/01/06 20:01:41
>>459
積算という事は、
　加算した結果を覚えておく手段（ＦＦとか）と加算器で出来るでしょ

462:デフォルトの名無しさん
05/01/06 20:26:21
boothでググれ。

463:デフォルトの名無しさん
05/01/06 21:20:32
>>458
そういう時はBASIC Unit(オムロンでいうASC Unit)なんかを使うんじゃないですかね。

464:デフォルトの名無しさん
05/01/07 05:49:52
誰か知っていたら教えてください。

PC系のボードを使って、PCIバスに制御用のカードをさしています。
カードに載っているデバイスへのアクセスは32bit幅限定。
ByteEnableの信号が無いらしく、byteやwordで書き込みすると、
他のビットが化けてしまいます。

このデバイスのレジスタマップは、
現在、ビットフィールドの構造体で定義されていて、これを流用したのですが、
コンパイラ(GCC)がビット操作をbyte単位で行うように
コンパイルしてくれて、困っています。(アセンブラ展開見て確認)
ビットフィールドってANSIではintでしか使えないはずだから、
当然32bit幅でアクセスするようにコンパイルされると思っていたのですが…。

コードの記述やコンパイルオプションの設定とかで、
何とか32bitでリード/ビット変更/ライトするようにコンパイルできないんでしょうか?
あ、もちろんレジスタのアドレスは4バイト境界になっています。

マクロ使ってビットアクセスを定義しなおすのは
かなりの量のレジスタがあり、コードもかなり変更しなければならなくなるので、
なるべく避けたいです。

同じような経験された方いますか?

465:デフォルトの名無しさん
05/01/07 11:00:51
ダミーのビットフィールドを入れて無理やり32bitにするのは駄目なの？

466:デフォルトの名無しさん
05/01/07 12:11:15
>>464
普通はそういう経験はしない。
理由はメモリマップ式のI./Oはめずらしいし
メモリマップ式でも、PCIバスだと普通のメモリに比べて遅いから普通のI/Oと同じように
読んで書く方式にするから

467:デフォルトの名無しさん
05/01/07 18:53:20
>>464
具体的な情報がないのでなんともいえんが、
bitfieldが本当に32bitサイズの型で宣言されていて、かつvolatile修飾されているのであれば
gccのバグだろう。そうでなければそれは仕様。

468:464
05/01/07 19:33:36
>>465
もちろん、ビットフィールドはダミーも入れて
きっちり32bit単位で全部埋まってます。
int(32bit)変数とのunionにしてあります。

で、たとえば、アドレス0の32bitレジスタのbit8に1をセットするような場合、
コンパイル結果を見ると、
アドレス1をバイトでリード/bit0を変更/ライトするコードが吐き出されているわけです。
アドレス0を32bitでリード/変更/ライトしてほしいのに。

>>464
やっぱりそうですよね。
RAM領域も持っているデバイスなのでメモリにマップされています。
マクロで定義しなおすしかないか・・・

469:デフォルトの名無しさん
05/01/07 20:36:06
ｇｃｃの仕様として有名な話ではないの？
「ｇｃｃ使う場合、日立ＳＨのサンプルソースはそのまま使えない。
理由は日立のサンプルがビットフィールド使ってるから」
みたいなのをインターフェースか何かで読んだことあるぞ

470:464
05/01/07 20:43:16
>>469
そうだったのか。
サンクス。

471:デフォルトの名無しさん
05/01/07 20:48:06
>>470
確か↓の本に書いてあったと思う。今手元に無いんで未確認だが
URLﾘﾝｸ(www.cqpub.co.jp)

472:デフォルトの名無しさん
05/01/07 20:50:51
gccでビット操作するとき、鬱陶しくなるようなマクロをよく使うよね。
移植性を高めた結果、問題の起こりやすいビットフィールドなんか
使ってられるか、ってことなんだろうね。

473:デフォルトの名無しさん
05/01/07 21:31:07
>469
gcc3以降だと大丈夫じゃないか？

474:デフォルトの名無しさん
05/01/07 21:33:56
>>473
ごめん、そこまで詳しくは知らない

475:デフォルトの名無しさん
05/01/07 22:02:31
そういうのはasmを使えば簡単で確実。
GCCのasmはCとのインターフェースも簡単なんだからさ。
(C++ならうまくクラスを作れば、ソースを変えなくてもできるかもしれない。
まったくお薦めしないが)

Cのレベルではアクセス幅なんて決まってないんだから、ビットフィールドの幅を
どうしようとアーキにあわせた最適な幅でやっちゃうんじゃない？
それもI/Oなんかつながって無いつもりで。

で、GCCのその辺の設定は、mdファイルに書いてあるはず。

476:デフォルトの名無しさん
05/01/07 22:08:32
処理系の影響を受けない様にビットフィールドではなく
論理演算を使ったり、展開を読むことも考慮して可読性を高める様
に書く様にしている俺はチキンでしょうか？

極端な話、
　　a++;
ではなく
　　a=a+1;
と書きます。これならコボラーが入ってきても対応できる可能性があるからね。
展開効率を上げるのはコンパイラの仕事だしい・・・・・・

477:デフォルトの名無しさん
05/01/07 22:14:38
>>476
a++も理解できないコボラーに対応させることの方が怖い。
そのレベルだと、strcmp()使わずにポインタ同士を比較しかねないぞ。

478:デフォルトの名無しさん
05/01/07 22:20:45
展開を読むってなに？

ビットフィールドはコンパイラと心中するつもりでないと使わないよな。

479:デフォルトの名無しさん
05/01/07 23:39:08
>>469
> 「ｇｃｃ使う場合、日立ＳＨのサンプルソースはそのまま使えない。
> 理由は日立のサンプルがビットフィールド使ってるから」

？
日立のＨＰからダウンロードできるヘッダファイルのこと？
たしかにビットフィールドばんばん使っている。
でも、これがＨＥＷ以外で困るのは、
ビットフィールドの並びが普通と逆だからじゃなかったっけ？

480:デフォルトの名無しさん
05/01/07 23:45:35
>>479
逆だとしても、468の問題とは別だろ

481:デフォルトの名無しさん
05/01/08 00:40:39
>>479
ビットフィールドをバイトアクセスに展開してしまうｇｃｃの処理を問題にしていたと記憶してます。
本で読んだだけで、自分で試したわけじゃないです。

482:デフォルトの名無しさん
05/01/08 01:05:37
●5月7日
　ん? この割り込みプログラム、これでほんとに動くか?? と、うちのRISCキットを使ってテスト…
なんてしてるから、単行本の編集作業が終わらんのだよ(^^;)　
ん～そうか、日立純正Cコンパイラはビットフィールド演算してももとのレジスタサイズでアクセスされるのか…
それでこのソースうちのぢゃ通らないんだなぁ～などと納得。
URLﾘﾝｸ(www.cqpub.co.jp)

483:379
05/01/08 01:29:43
>>464
1999年8月1発行、Ｉｎｔｅｒｆａｃｅ増刊TECHI
「ＳｕｐｅｒＨプロセッサ(SH-1/SH-2/SH-3/SH-4のハード＆ソフト完璧マスタ)」
P169：コラム１「日立純正Cコンパイラとｇｃｃ」より引用

ｇｃｃは非常によくできたコンパイラです（一時は、日立純正Cコンパイラより断然性能がよいと言われた頃もあった）。
しかし、ｇｃｃをSHシリーズで使用する場合には注意する点があります。それは周辺機能レジスタに対してビット名を使用したアクセスを行わないようにすることです。８ビット以外のレジスタ内容の参照や変更が出来ません。
（以下略）

484:デフォルトの名無しさん
05/01/08 01:53:44
>>483
乙彼
まさにその記事のことですわ

485:464
05/01/08 05:40:40
レス、サンクス。
結局マクロで組みなおすことになりました。

486:デフォルトの名無しさん
05/01/08 07:43:58
しかしそんな有名なバグがなんで直ってないんだろう。

487:デフォルトの名無しさん
05/01/08 07:52:46
>>486
この場合、バグは、I/Oなのにメモリマップにして、しかもバイトアクセスに対応しない自分勝手なボードの方だろう

488:487
05/01/08 07:59:07
さらに言うと、ビットフィールドをI/Oアクセスで利用しようという設計で
コンパイラを変更しようとしている甘えにも問題がある。

ワンチップマイコンでは強力なビット操作命令（I/Oにおいて特に有効な）をCから手軽に
利用出来るようにと、ビットフィールド関係を最適化して使いやすくした　専用Cコンパイラを
提供してくれている場合がある。

その場合、1ビット単位のI/O操作は当然ビットフィールドを使うのだけど、
それの方式が一般だと思ったり、移植可能と思っちゃいけない。

汎用性を考えるなら、ビットフィールドをそこで直接書かずに、マクロで抽象化してしまう事だ

489:デフォルトの名無しさん
05/01/08 08:21:31
>>487
この例は
デバイスがバイトアクセスに対応してないし、
そもそもメモリマップI/Oしか選択肢のないプロセッサの場合の話だと思うが

490:デフォルトの名無しさん
05/01/08 11:05:10
ｇｃｃのバグではない
純正コンパイラが機能拡張させてるだけ

491:デフォルトの名無しさん
05/01/08 11:32:09
>>489
> デバイスがバイトアクセスに対応してないし、

だから、“PCIバスに接続された制御用カード”のバグじゃん

492:379
05/01/08 16:30:19
>>487
>I/Oなのにメモリマップにして
って、モトローラ系はもともとそうだとおもうけど
３２bitでアクセスできないわけじゃなくビットフィールドが対応していないだけでしょ？

493:487
05/01/08 18:24:19
じゃI/O空間が無いCPUは絶対にI/O空間を使うPCIカードが使えないのか？
というとそんな事はないわけで、それぞれ使えるように工夫するものだし、そうじゃなければ逆に困るだろう。

I/OはやはりPCIバスのI/O空間に割り当てるのが正しい作法だろうと思うよ。

わざわざPCIのメモリ空間に割り当てたなら、バイトでアクセスしようが対応しなくちゃダメだろ。
　という話。
VRAMがRGBにわけてバイトでアクセスさせたらダメなんて事になってたら、ムカつかないか？

494:デフォルトの名無しさん
05/01/08 19:11:54
コンパイラは純正使ってれば間違いありませんし、高機能なものは無料
では手に入りません。あなた方の商売道具なのですよ？
　　　　　　　　 _, ,_ ∩
　　　　　　　(　ﾟ∀ﾟ)彡☆　ソレミタコトカー
　　　　　　　　 ⊂彡

495:464
05/01/08 19:12:13
なんか、いろんな論議に発展してるな。

特殊用途の通信チップなのです。
アドレスの前半がレジスタエリアで、
後半数ｋバイトがバッファRAMエリア。
通常は32bit単位でしか使わないような仕様です。
もともと組み込み用途なので、
SHとかに接続するように設計されているチップみたいでした。

496:デフォルトの名無しさん
05/01/08 23:13:31
SHCなら、volatile修飾すればビットフィールドは宣言型サイズ（int b0 : 1;なら4バイト）で参照されるな。
H8Cなら、evenaccess。
gccも何かないの？　最適化をoffにするとか。

497:デフォルトの名無しさん
05/01/09 04:21:19
すまん
HEWも癖があるけど、
これ、やっぱり結局gccのバグなんだよな？

498:379
05/01/09 04:53:50
>>493
SHは、メモリマップドI/Oなんだけどな。
そういうことを話してるのとは違うのか？
PCIカードだろうがなんだろうが、メモリ空間にマッピングされるのが気に入らないのか？
ビッグエンディアンも気に入らない？

499:デフォルトの名無しさん
05/01/09 06:50:22
>>497
> これ、やっぱり結局gccのバグなんだよな？

バグ、バグ、って正直ウザイよ,オマエ。

所詮Cじゃバスアクセスの幅は規定されないから、
処理系依存は当然だ。それを使いこなせないなら
その人間がアホなだけ。

500:487
05/01/09 07:40:38
>>498
それはCPU側から見た話で、PCIカードのI/O空間をCPUのI/O空間にどう割り振るかとは別の問題だろう。

・CPUにI/O空間が無い⇒だったらPCIカード側もI/O空間を使わない方が楽だろ？

みたいな考えじゃないの？
だったら既存のPCIカードでI/O空間を使ってるものを全て使わないつもり？

501:487
05/01/09 07:55:30
そういや、少し前のC++Builderで　バイト(char)でビットフィールド定義してたら
なんか1ビット不連続になってた事があったな。

確かにバイトでビットフィールド使うのはCの規格の範囲じゃないけど
あるコンパイラでバイトで定義するとそこを最適化してくれるものだから、使ってて、
それをC++Builderでデバッグしようとして、どつぼに嵌っちゃった

まあ、ビットフィールドには気をつけろってこった。

502:デフォルトの名無しさん
05/01/09 15:11:02
>>501
問題はビットフィールドでアクセスすると
「バイトアクセス命令に落ちる」ってことなんじゃないのか？

ｇｃｃのバグというより処理系依存で作りこまれたバグとしか思えん
I/Oにビットフィールドきっても、実際にI/Oに設定に行くときはunion
使うなりなんなりしてレジスタサイズ丸々writeするけど。
MemoryMappedI/Oで利きもしないBit操作命令になんかに
落とされちゃたまらん。

503:デフォルトの名無しさん
05/01/09 15:57:55
ビットフィールドってAND　ORもわからんアプリ屋が使うものだとばかり思ってた
・・・・・メリット、デメリットを計りにかけて設計・実装してますか？

504:デフォルトの名無しさん
05/01/09 16:07:02
>>503
出来上がるコードの違いわかってますか？

505:379
05/01/09 16:18:29
>>500
>だったら既存のPCIカードでI/O空間を使ってるものを全て使わないつもり？
PCIカードはいままでどおり勝手にすればいいのと違うか？CPUは、メモリマップするだけのこと。
すまないが、それが、ビットフィールドの不具合とどう関係するのか
漏れの不勉強な部分もあって、わからん。

もともと、ビットフィールドは使わないし。
どうせ、何ビットでアクセスしなきゃいかんのか意識しなきゃならないし
後で見て、どう定義されているか確認するのは避けられないから
直接、AND ORして、わかるようにコメント書いておしまいにしてる。

506:デフォルトの名無しさん
05/01/09 16:19:53
すべては仕様ですから～残念！

507:503
05/01/09 16:21:47
>>出来上がるコードの違いわかってますか？

全部、とは言いませんが、初めて使うコンパイラなんかだと、色々試して
アセンブラの展開を読んでからコーディング規約を作ってるけどね。
int　,　unsigned　intの差とか、charの扱いとか、引数の渡され方とか、auto変数の
レジスタアロケートルールとか。etc　etc

俺は>>476でもあるが、a++;とa=a+1;では、多くのRISCチップ様コンパイラでは同じ
展開になりますよ。

508:デフォルトの名無しさん
05/01/09 20:11:34
あーやっぱり>476は判ってない困ったチャンだったのか。

509:デフォルトの名無しさん
05/01/09 20:21:16
long *a = (long*)0;
long *b = a;
a++;
b=b+1;
if(a != b){
　printf("残念！");
}

510:デフォルトの名無しさん
05/01/09 20:31:12
>>502
バグはおまえの頭。

>>507
a++とa=a+1が同じだったら、a++の方が分かりやすいだろう。

あと、生成コードの癖はちょっと見ただけであたりを付けるとはまるよ。
コンパイラが保証していないことを独自に保証するには、相当の覚悟がいる。

511:476
05/01/09 20:51:31
>>508
御心配頂かなくても、弊社はコンパイラメーカでもあるから勘所はわかりますよ

512:デフォルトの名無しさん
05/01/09 20:58:12
>>511
でもあんたはコンパイラの開発にかかわってないだろ？

513:ライブラリアン
05/01/09 21:11:42
Ｃも大変ですね。その調子ではシステムの開発が
完了するか予測ができませんね。
やはりＬＡＢＶＩＥＷがいいな。

514:デフォルトの名無しさん
05/01/09 21:25:17
ビットフィールドだと、
数ビットあるエリアに値を書く必要がある場合は便利なんだがな…

515:デフォルトの名無しさん
05/01/09 21:27:25
>>511
大丈夫、あんたの事なんか心配してない。
都合のいいことだけレスしてそうでないことはスルーしているのが気に入らないだけ。
あー、もし私の仕事と関わりが出てくるようなら話は別だが。

>>513
中途半端な顧客だとLabViewだと納得してくれなくてね。
#判ってない客は動けばいいと言う。よく判ってる客はLabViewをきちんと評価できる。

516:487
05/01/09 21:35:06
>>505
だからさ、
ビットフィールドの内部操作をバイトで処理する実装をバグだというから、
それよりも、PCIバスボードのくせに、I/Oをメモリマップにして、しかもバイトイネーブルに対応していない
ボードの設計の方がバグだろうと　言ってるだけさ。

ビットフィールドの内部操作をバイトで処理する実装は、メモリが相手である限りはバグではない
正しい実装だろう。

517:487
05/01/09 21:40:00
>>513
パソコンならDelphiでやっつけた方が余程簡単で、しかもやっつけられる範囲が広い上
再利用性が高いよ。

今では
メータ類もポトペタしてプロパティ設定するだけ。
シーケンサとの通信もポトペタしてイベントにコード書くだけだし

目の前でコード作れますよ

518:デフォルトの名無しさん
05/01/10 00:24:47
>>416
はぁ ? 何が言いたいんだ ?
それこそ、ハッキリ書けよ。

> 余計な事を言って手間増やされちゃたまらんよ

君のことか ? (藁

>>418
OS としては全然大丈夫 Compact Flush はリードしかしないし、ファイルシステムは使い捨てだから。
(そのために、メモリー上にファイルシステムを作る。)

もちろん、データを書き込むデバイスは途中で書き込みが中断されることがあるけど、そこはソフトで何とかする。
例えば、ブロック単位で書き込みを行い最後にブロック毎のチェックサムを書き込む。
次回の起動時や別の機器でそのデバイスを読み出す時は、先頭からブロック毎にチェックしていってチェックサムが異常だったらその前までのデータを有効とするとか等。

>>449
> ＦＡだとそこまで対策してるのは見たことないよ

まあ、FA と言っても色々だろうけど、君が見たことないからと言って世間にないわけじゃない。
あと、仮に対策していても取り説には「書込中は電源を切らないでください」とは普通書いておく。
なんかトラぶったときの保険としてね。

519:デフォルトの名無しさん
05/01/10 00:29:19
>>416
はぁ ? 何が言いたいんだ ?
それこそ、ハッキリ書けよ。

> 余計な事を言って手間増やされちゃたまらんよ

君のことか ? (藁

>>418
OS としては全然大丈夫 Compact Flush はリードしかしないし、ファイルシステムは使い捨てだから。
(そのために、メモリー上にファイルシステムを作る。)

もちろん、データを書き込むデバイスは途中で書き込みが中断されることがあるけど、そこはソフトで何とかする。
例えば、ブロック単位で書き込みを行い最後にブロック毎のチェックサムを書き込む。
次回の起動時や別の機器でそのデバイスを読み出す時は、先頭からブロック毎にチェックしていってチェックサムが異常だったらその前までのデータを有効とするとか等。

>>449
> ＦＡだとそこまで対策してるのは見たことないよ

まあ、FA と言っても色々だろうけど、君が見たことないからと言って世間にないわけじゃない。
あと、仮に対策していても取り説には「書込中は電源を切らないでください」とは普通書いておく。
なんかトラぶったときの保険としてね。

520:デフォルトの名無しさん
05/01/10 02:43:48
Flushなんて書いているあふぉはほっとこ。

521:デフォルトの名無しさん
05/01/10 02:59:44
>>516

> ビットフィールドの内部操作をバイトで処理する実装は、メモリが相手である限りはバグではない
> 正しい実装だろう。

だからさ、
メモリを相手にするばかりじゃないわけだからさ、
実際SHなんかだと、そういうケースが多いし、
ビットフィールドで書けたら、そっちの方が便利なわけで
いくら「正しい実装」だろうと、不便だとみんな言ってるんでないのか？？？

522:デフォルトの名無しさん
05/01/10 03:06:04
>>521
メーカーのコンパイラ使えばいいだけだろ？
いつまでも何を言ってんだ。

523:379
05/01/10 05:00:02
>>516
>PCIバスボードのくせに、I/Oをメモリマップにして
H8/SHで、I/Oをメモリマップ以外にできるのかな？

>バイトイネーブルに対応していないボードの設計の方がバグだろうと　言ってるだけさ。
バイトアクセスを保障しない仕様はよくあるけどな、内部レジスタでもなかったかな。
ＰＣＩのボードだけは保障するべきだということかな？

そもそも、ビットフィールドはＡＮＳＩの仕様で、
定義したビット数でアクセスすることを保障しているのだろうか？

524:487
05/01/10 07:46:05
>>521
誰も保障しろとまで書いてないだろ？

ビットフィールドの内部実装でバイト単位にアクセスするコンパイラと
どっちがお馬鹿な実装かって話しをしてるだけさ。

PCIボードの実装で、メモリー空間に割り付けてバイトイネーブルに対応しない事と
メモリ空間しかないCPUで　バイトでアクセス出来ないI/Oとを一緒にしてくれるなよ。
　16ビットのカウンターを８ビット単位に書き出すのは、それは馬鹿だろ？

だから、ビットフィールドの定義なんて読んだって、そんな細かな事は書いてないだろ。
どっちから確保されるかさえ書いてないんだからさ

525:487
05/01/10 08:05:52
面白いので調べてみた
URLﾘﾝｸ(www.asahi-net.or.jp)

＞失望と誤解
＞以下の問題が存在することは残念ではありますが、実際にこれを回避するための方法を私たちは1つも知りません。

ビットフィールドへのアクセスは、たとえアクセスされるビットフィールドがvolatile指定されたオブジェクトの一部であっても、
1バイトや1ワードなど、よりサイズの大きいオブジェクトにアクセスすることによって動作します。
ビットフィールドの読み込みや書き込みを行うために、ある決まったサイズのオブジェクトが
アクセスされるということをあてにすることはできません。同一のビットフィールドであっても、
その用途に依存してアクセスされるサイズが変わってくることもありえます。
アクセスされるメモリのサイズを制御することに関心があるのであれば、
volatileを使い、ビットフィールドは使わないでください。

526:デフォルトの名無しさん
05/01/10 09:13:32
>>521
だったら、自分がそういう実装のコンパイラを作れよ。
GCCを改造すりゃいいだろ？

たぶん、それを要望してもそういう実装をしようという奴は少ないと思うよ。
ビットフィールドそのものが実装は厄介な上、実装時も実行時も非効率。
かつ実際に、めったに使われない機能。
喜んで使うのは小規模組込屋くらいだろ。

実際、他の言語でビットフィールドもどきをサポートしてるのは殆どない。
似た機能としてはpascalの集合型くらいだろうけど、
これは1ビット単位だから、複数ビットのフィールドを定義出来るCのビットフィールド
に比べると簡単だしな

527:ライブラリアン
05/01/10 09:27:49
＞５１５

＞#判ってない客は動けばいいと言う。
＞よく判ってる客はLabViewをきちんと評価できる。

これはいい指摘だ。お客のことが言いたかった。
皆さんのマニアックなレスを読んで何の為に仕事を
しているかの一端が分かった。それはお客に評価されるためだ。
私の喜びはお客に評価して貰うことだ。
「あなたの作ったシステムはとても役に
たつよ」、「上司からいい評価をもらったよ」
「リピートを出すよ」「新しい案件があるので、是非あなたに
やってもらいたい」と言われることだ。

528:デフォルトの名無しさん
05/01/10 09:39:30
>>527
いや、だからあなたが優秀な営業マンである事は判ったけどさ、
しまいにはPCを車載でも平気で採用しそうな勢いだな。
・・まあ、超小ロットの特殊仕様車じゃそういうのもアリかもしれんけど・・・

529:デフォルトの名無しさん
05/01/10 10:14:24
>>520
Typo しか指摘できないということで FA ?

530:デフォルトの名無しさん
05/01/10 10:38:10
わたしゃ519じゃないが、フラッシュメモリの英語表記(?)は
Flushでも間違ってないよ。Flashの方が圧倒的にメジャーではあるが。

むしろこんなことも知らない奴は普段ちゃんと石のデータシート読んでるのかと
問い詰めたくなる。

531:デフォルトの名無しさん
05/01/10 10:39:57
SHでビットフィールド実装するとして　値１を書き込む場合、

バイトreadして即値or　して、バイトwrite　って事になるのが普通じゃない？
だって8ビット以上の測値はpc相対オフセットで読む事になるから
命令も長くなるしさ。

int幅だから32bitでアクセスしろって事？
で、charで指定した場合だけ8ビットでアクセスしろって贅沢言うわけね？
しかしさ、int以外のビットフィールドはANSIじゃないでしょ？

というかさ、ビットフィールドの型は、本来、そのビットを　どう型変換するかって意味じゃないの？
だから　　signed かどうかで　1ビットが1になったり-1になったりするだろ？

532:デフォルトの名無しさん
05/01/10 10:55:15
話は少しそれるが、ISO/ANSIの言語仕様で、

objectの型がvolatileの場合はメモリ参照サイズ = 型のサイズになる
（たとえば struct S { volatile int bit1 : 1; } b; ならb.bit1の参照時には常に4バイトアクセスコードがでる）

という保証はないの？　いままでそういうつもりで使ってたんだけど…

533:デフォルトの名無しさん
05/01/10 11:24:12
>>532
無いでしょ。
それは構造体 S で　1bit　の領域を定義して、そのbit1を int で参照しますという意味じゃないの？
普通はintは符号付だから　結果は　0か-1になる筈だけど
ANSIでは、どっちでもいいとしてるもんだから混乱の元
（コンパイルオプションで変更出来るものも多いようだけど）

534:デフォルトの名無しさん
05/01/10 13:13:02
>>532
ANSIの仕様は忘れたが、うちのコンパイラでは保証してる。
以前、そういう例に対して、最適化して1バイトアクセスコードを出すようにしたら、
顧客からがんがん苦情がきたよ…。

535:デフォルトの名無しさん
05/01/10 14:15:03
>>534
532はISOで保証される（処理系依存ではない）か
聞いているのに、オマエ馬鹿だろ。

コンパイラで保証されるものがあっても当たり前すぎる。

536:デフォルトの名無しさん
05/01/10 15:25:34
バイトアクセスに最適化してくれた方が性能出る場合に、
どっかのバカを救うためにいつもワードアクセスされた方が困るがな。

Cは生成コードが想像つきやすいこともあって、「想像」=「事実」と
勘違いしてしまう人も多いのかな。

537:379
05/01/10 16:31:54
>>534
>ANSIの仕様は忘れたが、うちのコンパイラでは保証してる。
つまり、ANSI準拠というわけではないということですか？
別にそうでも構わないし、ヴァカとは思いませんが。

538:デフォルトの名無しさん
05/01/10 17:06:07
68020なんかのCPUでは、ビットフィールド命令を使用するか否かの
コンパイルオプションがあったので、
アクセス幅設定のオプションもあるかなと思ったわけですが、
無いんですね。

539:デフォルトの名無しさん
05/01/10 17:07:26
該当するbitに対してのみvolatileが保障される

540:デフォルトの名無しさん
05/01/10 17:29:33
>>533
今ANSIの仕様書をみてるんだが、その辺の事情はどの辺を読めばわかる？
volatileの項とかみたけどよくわからん。

541:デフォルトの名無しさん
05/01/10 18:37:40
このスレ、ツール屋も結構混じってるな・・・・・・
CM
　コンパイラ、ICE、評価ボードはお金を払って買いましょう。
　いや、買ってください。m(。。;)m

542:デフォルトの名無しさん
05/01/10 19:11:04
>>540
ビットフィールドとvolatileは無関係。

ビットフィールドの値の符号有無しは規格では決まってない。処理系で規定する
ことが求められているのは、領域の埋めかただけだな。
volatileオブジェクトは処理系の外で変化するかもしれないから毎回アクセスする。

書いてないことは保証されていない。

543:デフォルトの名無しさん
05/01/10 19:39:35
>>542
ありがとう。
volatileがある時にメモリアクセスサイズが保証されるかを調べたかった。

> 書いてないことは保証されていない。
そうだね。
しかし、どこにも書いてないことを確認するのが大変だ…。
直接書いてなくても、あちこちの記述をつなぎあわせると
規定されていることがわかったりするし。
以前、識別子のスコープルール（block scopeの生成条件）を調べるのに一日かかったよ。

544:デフォルトの名無しさん
05/01/11 01:24:34
>>537,379
処理系依存だったら処理系が保証して当然。
保証しなくていいのは不定な動作だけ。
まぁ、馬鹿には分からんかもしれん。

545:379
05/01/11 01:36:12
釣られて言えば、
処理系依存なら処理系の勝手

546:デフォルトの名無しさん
05/01/11 07:19:09
処理系定義（implementation defined）
未規定（unspecified）
未定義（undefined）

を区別しよう。

547:デフォルトの名無しさん
05/01/11 21:09:28
>>464
すごい燃料だな・・・・・まだ燃えてるよ・・・・

548:デフォルトの名無しさん
05/01/11 22:29:57
ビットフィールドは便利なようだが処理系依存なので使わないのが吉。

ビットフィールドは使わずにビット操作。
なおかつアセンブリで8bit/16bit/32bitでread/writeする関数を作成して使っている。
さらにコンパイラ/ターゲット依存を覚悟で、
inlineかつインラインアセンブリな関数にしている。

コンパイラ変更あるいはターゲット変更でも、
read/write関数を直すだけですむので無問題。
ビットフィールドは、あっちこっち直す羽目になるので問題大。

549:デフォルトの名無しさん
05/01/11 23:01:08
途中からコンパイラを変更するなんてあるの？ちょっと信じがたい。
まあソースの再利用はあるかもしれないけど。

550:デフォルトの名無しさん
05/01/12 01:22:07
つか、組み込み屋がIOアクセスするのにビットフィールドを平気で使うこと
自体が折れには到底信じられないんだが・・・・。使わないことが常識だと思ってたよ。

>>519
書き込み可能なデバイスで、書き込み中に電源断しても、デバイスのその後の動作に問題が
発生しないことを保証するものはあまりない。SDカードやCFなんてのも普通は全くの保証外。
壊れても文句言えない。少なくとも、ちゃんとデバイスメーカーに確認してから使えよな。
ま、保証してくれるかはわからないが（ｗ

551:デフォルトの名無しさん
05/01/12 03:20:02
>>550
> つか、組み込み屋がIOアクセスするのにビットフィールドを平気で使うこと
> 自体が折れには到底信じられないんだが・・・・。使わないことが常識だと思ってたよ。

しかし、組込屋が使わないとなると誰が使うんだ？

552:デフォルトの名無しさん
05/01/12 04:50:09
おう、組み込み屋じゃない漏れはよく使うぜ。

553:379
05/01/12 05:26:37
>>551
むしろ組み込み屋じゃないほうが良く使うと思う。

554:デフォルトの名無しさん
05/01/12 06:45:49
俺もビットフィールドは嫌いだが、メーカーの提供しているヘッダファイルの
IO定義がビットフィールドを使ってるしなあ（ SH/H8）。

555:デフォルトの名無しさん
05/01/12 13:03:34
まあ、取り込み作戦なんだろうけど、それを使ってもさらに抽象化しとくべきだろうな

556:デフォルトの名無しさん
05/01/12 13:26:12
>>553
ドライバ屋さんはI/Fは用意してくれるがビットに詰めるのこっち任せだったりするからね。

557:デフォルトの名無しさん
05/01/12 13:32:08
質問です。
デバイスドライバを書くときに、デバイスのどういうことを調べていくのが一般的ですか？

558:デフォルトの名無しさん
05/01/12 19:01:21
デバイスドライバを書くときは、デバイスがどういうものかを調べていくのが一般的です

559:デフォルトの名無しさん
05/01/12 19:26:26
>>558
参考になりました！ありがとうございます！！！

560:デフォルトの名無しさん
05/01/13 00:35:39
なったのかよ！

561:デフォルトの名無しさん
05/01/13 01:22:49
>>560
いいえ、皮肉です。

562:デフォルトの名無しさん
05/01/13 06:33:58
むしろ果肉

563:デフォルトの名無しさん
05/01/13 12:48:41
>>557 マニュアルはたいがい「このレジスタにこれを書くとこう動く」式で書かれてるね。
その中から、「アプリからこう使えれば便利だな」を抽出するように読もうとしてるよ。
機能レベルでそれを把握してから、時間的な条件（割り込み発生のタイミングとか、
許されるディレイ）、制約条件（この使い方のときはこっちがダメとか、書き込みと
割り込みが同時に起きたときどっちが優先、とか）の所と照合すると、間違った使い方
しようとしてないかの検証になる。

564:379
05/01/13 18:07:44
>>557
どう動かすかということはもちろんだけれども、
どう抽象化するかが上手い下手になると思う。
そのために操作の単位がどうなるのかを調べる。
そんな風に、設計してます。

565:デフォルトの名無しさん
05/01/14 21:44:36
はじめまして、一つ伺いたいのですがよろしいでしょうか？

あるRAMエリアに対して0でクリアしたあと本当に0になってるか
チェックする処理を作りたいのですが、とにかく処理時間重視と言われました。

処理能力を気にしないので良いなら悩まなくても良いんですが、
どういうロジックを組めば最も高速にクリア＆チェックできるか私の頭ではわかりませんでした。

言語はCですが、処理能力考えるとアセンブラで組んだほうがいいような気もします。
何かよい知恵がありましたら教えてください。

566:デフォルトの名無しさん
05/01/14 21:45:34
あと、使ってるのはSH-2です。

567:デフォルトの名無しさん
05/01/14 21:51:01
>>565
どうやったらいいのか
どこで差がつくのかわからん

568:デフォルトの名無しさん
05/01/14 22:05:17
クリアした後
本当に0になってるかチェックした後
本当に0になってるかチェックした後
本当に0になってるかチェックした後
本当に0になってるかチェックした後
本当に0になってるかチェックした後
……

569:デフォルトの名無しさん
05/01/14 22:45:21
・・・・・よし、明日の朝はトーストとハムエッグにしよっと。

570:デフォルトの名無しさん
05/01/15 00:44:15
埋める方をDMAのバースト転送を使ってやる。
ただし、転送元は内部レジスタで０になってるとこ。

チェックはソフトで地道に。

これで、全体的には速くなる（ｗ

571:デフォルトの名無しさん
05/01/15 01:39:09
>>570
CPUからメモリへの書き込みパスがチェックできてない。
…ということを考える必要があるかな？

572:デフォルトの名無しさん
05/01/15 02:22:53
私は普通にmemsetで0にクリアして、その後そのRAMエリアを読み込んで
0と比較すれば良いと思ったんだけど、処理能力、処理能力いうんですが
やっぱり大きく変わるんですかね～？

一番大きいバッファでもクリア&チェックする領域は64KBぐらいです。

573:デフォルトの名無しさん
05/01/15 03:35:19
どれくらいの速さが要求されているのかにもよるな

574:379
05/01/15 04:01:11
>>565
なんで？

575:デフォルトの名無しさん
05/01/15 05:20:41
>>565 >>572 memsetでいいよ。それの中はASMで作られているから。ただしその後の
memcmpで64KBのゼロと比較するとしたら、あまりにもサイズのムダなので許せない。
#define CLRTOP 0x100000
#define CLRLEN 65536　　　　　　/* 100000h番地から６４Ｋクリヤするとして */
memset((char*)CLRTOP,0,CLRLEN);
if( 0==memcmp((char*)CLRTOP,(char*)CLRTOP+1,CLRLEN-1) ) で、クリヤされたと判定

576:デフォルトの名無しさん
05/01/15 05:44:56
指示出した奴が評価できるとは思えんので、なにやってもﾖｼ

577:デフォルトの名無しさん
05/01/15 06:44:27
バッファの先頭・終端addressが共に4 byte alignされてるとして、
int is_zeromemory(char *start_address, char *end_address)
{
　　int result = 0, *p;
　　for(p = (int *)start_address; p < (int *)end_address; p++) {
　　　　result |= *p;
　　}
　　return result == 0;
}
あたりが定番か（4 byte alignされてない時は前後に補償コードを追加）。

578:デフォルトの名無しさん
05/01/15 09:34:50
ゼロになってるか判定するコードだね。確かにバイトでやるより速い。
どうせならforの中で、resultが０でなければreturn 0、forが終わったらreturn 1に
してほしかった。　もっと速さを要求されるなら、書き込んで読みそれがゼロか見るループを
書けばいいが、そのとき最適化によって書いたメモリを読まずに書き込んだレジスタのほうを
判定するコードが出されることがよくあるので注意が必要。

579:デフォルトの名無しさん
05/01/15 11:02:18
その程度の処理ならタコな書き方しなければ大差ないだろ。
それより0書いて0読んでテストできた気になってる方が問題　ヽ(´ー｀)ﾉ　

580:デフォルトの名無しさん
05/01/15 11:07:44
>>578
> どうせならforの中で、resultが０でなければreturn 0、forが終わったらreturn 1に
> してほしかった。
せっかくビットORを使ってループ中の分岐を減らしてるのに、それじゃ意味がないと思う。

値が0でないメモリが見つかる（= 書き込みが失敗していた）ケースは
滅多にないはずだし。　

581:デフォルトの名無しさん
05/01/15 11:26:46
>>578
volatile

582:デフォルトの名無しさん
05/01/15 12:10:45
みなさんありがとうございます。

・・・というとCでもアセンブラでも大差はないということでしょうか？
0でクリアした後0でチェックするのは、ちょっと他の所で問題があったらしいのです。

なので私は最初あるバッファに対し0xB6を書いて読んでチェック、0x49を書いて読んでチェック
その後0でクリアして0でチェックという関数を作った矢先、処理能力云々言われ
今に至っているんです。

消すバッファが最初は2つぐらいで良いといってたのに、
最終的には処理の中間に生成するバッファも含めてやばそうなバッファ全部消せ
ということで処理速度をさらに重視した次第・・・らしいです。

583:デフォルトの名無しさん
05/01/15 13:10:09
素朴な疑問。
書き込みに失敗してたらどうするんだろ。

584:デフォルトの名無しさん
05/01/15 13:13:52
マーチングテスト最強

585:デフォルトの名無しさん
05/01/15 14:28:55
582>キャッシュのことは考慮済み？

586:デフォルトの名無しさん
05/01/15 15:15:03
SH2はキャッシュがあったかどうかしらんが
キャッシュがあるＣＰＵだとキャッシュに書き込んでいるだけになることもあるよな

587:デフォルトの名無しさん
05/01/15 16:00:34
そこでランダムリプレースアルゴリズムのキャッシュですよ。

588:379
05/01/15 16:26:19
で、どうして、書いたものが保証されないという事態がおきる？
ＲＡＭに書いたものが保証されたないって、スタックも保証されない？

589:デフォルトの名無しさん
05/01/15 16:33:37
>>582 584の言ってるのは55,AA,FFを書いた後00にする検査のことね。585,586,587はそこまで
問題にならないとおもう。583のギモンに対して特に対処策がないなら、単にmemsetでゼロを
書くだけでいいと思う。B6/49という値に何か意味はあるの？

590:デフォルトの名無しさん
05/01/15 16:36:42
たしかに、書いた物が保証されないって、RAMが別チップでﾁｯﾌﾟｾﾚｸﾄがちゃんと出てないとか、
そんな事態ぐらいしか想像できないね。そんなのハードのアドレスデコード部分のバグだから
よっぽどのことがないとお目にかかれないぞ。

591:デフォルトの名無しさん
05/01/15 16:59:24
PCのBIOSがメモリチェックやるのはあれは何のため？

592:デフォルトの名無しさん
05/01/15 17:54:53
あれは「仕事してま～～す」というデモンストレーション」なだけ

593:デフォルトの名無しさん
05/01/15 17:57:40
>>591
PCのメモリは、
ソケット着脱式だから、
　メモリをユーザが取り替えているかもしれないから、少なくとも容量はチェックしないといけない
　もしかして接触不良があるかもしれない

594:デフォルトの名無しさん
05/01/15 18:23:24
>>590
バグと言うか、製造後の不良品のチェック用に商品に検査モードを搭載してるけどな。
RAMのアドレスバスのショートのテスト、データバスのショートの検査とかも入ってるよ。
55,AA,FF、00もそうだし、0x01,0x02,0x04,0x08,0x10・・・・・の様にデータバスのビット
立てたり、書いた後でアドレスバスがショートしてた場合の該当アドレス参照したり。

595:582
05/01/15 18:53:33
大きなことではいえませんが
昔はそのバッファは消していませんでした。
次の取引で「上書きされるだろう」とのことで・・・（処理時間を気にした結果、消さなかった）

しかし、前回のバッファが上書きされること無く悪さしたため大変なことになりました。
よって今回、いちいちそのバッファに情報を書き込む前に前回情報を消して、
本当に消えてるかチェックするという事態になりました。

次ページ