日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

JavaScriptを有効にし、Cookieを受け入れ、以下のブラウザを使うことで完全なコンテンツが楽しめます。
Mozilla Firefox 3.0(Get Firefox)・Opera 9.6・Safari 3.2・Lunascape 4/5(Gecko)・Lunascape 5(WebKit)
Internet Explorer 7/8とそれを使うIEコンポーネントブラウザ(Lunascape・Sleipnirなど)

<< 過去

ネットワークスペシャリストの要求は高い

今日は情報処理技術者試験の日、というわけでネットワークスペシャリスト試験(NW)を受けてきた。

応用情報技術者試験(AP)(2016年春合格)→エンベデッドスペシャリスト試験(ES)(2017年春合格)を経てのNW試験である。

AP合格でESの午前I試験を免除されたが、今回もES合格でNWの午前I免除を受けている。

というわけで、10時半ごろに会場に着いて、午前II試験からスタート。


午前II試験は25問の4択問題が並んでいるもので、試験時間は40分と短い。

ただ、途中退出もできないので、どうしても最後までいる必要があり、その後は昼休み1時間を挟んで午後の試験になる。

昼休み1時間といっても、20分前には席に戻るようにというから、そんなに余裕はない。

というのは、ES試験のときにも思ったことだが。

そんな試験だが、最大で30分の遅刻まで許容されていて、25分ぐらい遅刻して入ってくる人がいた。

もちろん午前II試験の遅刻ということは、午前I免除者だろうけど、わずか15分ほどで解いたということだろうか。

その気になれば15分でも解ききれそうではあるけど。


午後I試験、午後II試験はともに記述式で選択した問題を回答する。

午後I試験の手応えがあまりよくない。午後II試験は意外と答えられた。

午後の試験を通じて思ったのは、ネットワークと一言でいうけど、いろいろな切り口があるということだ。

OSI参照モデルでネットワークは7層に分けられているけど、レイヤーの違いというのも切り口の違いの1つだ。

ネットワークの実務経験がある人でも、自分があまり関わったことがない分野の問題は難しいだろうなと。

午後I試験は3問中2問選択、午後II試験は2問中1問選択だから、選択制といってもそんなに選べるわけでもない。

そう考えると、問題との相性というのもあるのかもなぁと。

合格ラインが6割だから、取れている可能性もなくはないが、ちょっと厳しいかもねぇ。


NW試験の勉強をして学んだことは多い。

いろいろなタイプのネットワーク構成とそのための技術を学ぶことができた意味は大きい。

ただ、本来は実務経験の豊富な人のための試験ですからね。要求水準は高いなとも思った。

というか、NW試験って受験者多いのもあるけど、合格率13.6%(2017年実績)ですからね。

ES試験は受験者少ないけど合格率17.9%で、高度試験の中では一番高い。どんぐりの背比べかもしれないけど。

ネットワークに関わる技術者を広く対象にしているが、その要求水準は高いってことですね。


というわけで、不合格になったとして再挑戦するかというと微妙。

受験に向けて勉強したことで今の僕にとっての目的はほぼ達成したのでは? と。

今回はES合格で午前I免除になったけど、次回は免除にならないのもある。(次回春の試験まではES合格が有効だが、NWは秋だけの試験)

午前I試験はAP試験相当の範囲だから復習すれば問題なく通るはずだけど。


逆に合格したとして、この先はどうかというと、自分の分野に関わりが深いのがシステムアーキテクト試験だが、

これは午後II試験が小論文で、自分がシステムアーキテクトとしてやってきたことについて解答しなければならない。

僕の目指す道ではあると思うけど、すでにシステムアーキテクトである人のための試験で、これを目指す人の試験ではないなと。

情報処理技術者試験もいろいろあるんですよ。どれも広く言えばIT技術者向けだが、いろんな立場を想定しているので。


Author : hidemaro
Date : 2018/10/21(Sun) 22:59
コンピュータ | Comment | trackback (0)

タブレットがないのは不便だった

引越まで1週間ちょっと、というわけでやや使用頻度の低いものを整理したり、掃除をしたりしている。

順調といってよいと思うが、めんどくさそうな食器類は直前まで梱包できないので。

どこまで先行して着手できるかってことですね。

というか、冷蔵庫の中身も運べるように整理しないといけないんだよなぁ。うまく調整しないと。


この前、関西に行ってたときに、実家にタブレットを忘れてきてしまった。

次回行く予定はあるが3ヶ月後なので、そこまでタブレットなしっていうのもなぁ。

ということで、送ってもらうことにして、今日に無事に届いてやれやれと。

両親には手間をかけてしまったけどね。


タブレットがなかったn5日間だけでも、けっこう不便だった。

従来、タブレットでやっていたことを、スマートフォンでやればよくて、

どちらもAndroidだから機能的な差はあまりないはず。

画面の大きさの差、そしてタブレットとスマートフォンを別々に使えない不便さが目立った。


よく考えてみると、僕にとってはスマートフォンよりもタブレットとの付き合いの方が実質的には長い。

厳密に言えば、Windows Phone、X01Tを2007年から約5年間にわたって使っていたのだが、

この当時、スマートフォンという言葉がやっと出てきたばかりで、通信機能付きPDAぐらいのイメージで、

通信料の問題もあって、あまり通信を使わずに使っていた。PDAと電話がくっついているだけという感じ。

2013年、大学院入学を前にして、EMOBILE(当時)とモバイルルーターを契約し、これと併用するためにNexus 7を購入した。

ここから5年以上、端末は変わりつつも、一貫してAndroidタブレットを使ってきた。

このとき、一旦スマートフォンをやめて、音声端末に移行したのだった。


スマートフォンとタブレットの併用になったのは2017年の正月から。

当時の悩みは2つあって、1つは当時使っていたBB.exciteモバイルLTEの回線品質が良くなかったこと。

もう1つはゲームを遊ぶには安物のタブレットでは厳しかったこと。

この問題を一挙に解決するため、Y!mobileに電話もデータも集約し、新しいスマートフォンを買うことにしたのだ。

Y!mobileを選んだ理由はいくつもあるけど、決め手の1つはテザリングが定価で無料であること。

タブレットと併用するのは必須条件で、タブレットやPCを接続しても料金が高くならないというのは非常に重要な条件だった。


スマートフォンとの併用になって、ゲームは全てスマートフォン側に集約したり、

タブレットを買い換えるときに従来の7インチから8インチにやや大きくしたりという変化はあったが、

タブレットの使用頻度が大きく減るということはなくて、新聞や電子書籍を読む用途ではむしろ活躍が増えている。

ゲーム、音楽、外出時の調べごとを除いては、あまりタブレットの出番は変わっていないよね。

Androidが2台体制になって、スマートフォンでゲームの画面を出しながら、タブレットでWebサイトを見たり、2台同時に使うことも出てきた。


というわけで、スマートフォンだけになると、画面小さいなとか、1台だけじゃ不便だなってなるんだよね。

画面小さいということについては、タブレットとの対比で小さめの端末を選んだというのもある。

5.0インチのスマートフォンというのは、今では小さいんだよね。選択肢が少ないというほどでもないが。

もし1台で済ませるならば、もう少し大きな画面の端末の方が便利なのかも知れないとは思った。

世の中そういう考えが一般的ということなのかな。


安物のタブレットだから、性能が出ないのは悩みなんだけどね。

それでも画面が多少大きい方が役に立つというのはある。実際、ある程度の性能が出れば困らないしね。


Author : hidemaro
Date : 2018/08/11(Sat) 22:32
コンピュータ | Comment | trackback (0)

Androidに画面を転送できる

来週は夏休みなのだが、一方で社宅関係の手続きが動く可能性もなきにしもあらず。

必要な書面は送ってあって、抽選日は夏休み明けなので、一見問題ないのだが調整が必要になる可能性がある。


ただ、在宅勤務のためにリモートアクセスできますからね。

給与明細の確認などのためにリモートアクセスを業務外で使うことがあるけど、便利ですからね。

というわけで夏休みでも社宅関係の連絡を確認することはできる。

しかし、問題があって、それはこの期間の平日はずっと旅行で家にいないということ。


そういえば、リモートアクセスってAndroidでも使えると書いてあった覚えがあるし、

リモートアクセスで使えるアプリにモバイル用のメーラーらしきものがあった。

これがうまくいけば旅行先から会社のメールを確認できるのでは? ということで試してみた。

リモートアクセスの画面転送を受けるためのアプリをインストールして、

Webサイトからログインして、ログイン後に起動するアプリを選ぶと画面が転送されてくる。AndroidでもWindowsとあんまり変わらんな。


それで、モバイル用のメーラーらしきアプリの画面を転送してくると、

おー、スマートフォン向けの画面に最適化されたメーラーが立ち上がった。日本語のフォントがちょっと不格好だけど。

あとメールの入力時に、文節を確定するまで文字が表示されないというところも違和感がある。

Androidの場合は、ローカルで漢字変換までやって、確定させたら漢字の状態で転送されるようになってるみたい。

Windowsからだと、キーボードで打ったものがそのまま転送され、社内のMicrosoft IMEで漢字変換されるんだけどね。

ここら辺はリモートアクセスらしい挙動だが、モバイル用メーラーを使う限りにおいてはAndroidからでも使いやすい。


このリモートアクセスは社内に設置されたWindowsマシンで動いているアプリの画面を転送しているだけなので、

リモートアクセスで使えるどんなアプリの画面でもAndroidに転送することができる。

なので、Microsoft Outlookの画面をAndroidに転送して、メールの送受信を行うことも出来る。

ただ、やってみたけど、すごい操作しにくいんだよね。小さなタッチパネルで操作するには不便だ。

というわけでモバイル用メールアプリの有効性がわかった。

このモバイル用メールアプリもWindows上で動作して、その画面を転送しているだけなんだけどね。


営業の人とかが社外でメールの送受信するときはどうしてるんだろうね。

確かにこの方式でいいんだけど、ログイン手順が煩雑なので、正直めんどくさい。

別にAndroidだからという話ではなくて、Windowsからでもめんどくさい。ちょっと手間のかかる認証手段なので。

調べたところ業務用のスマートフォン・タブレットの場合は、一定のセキュリティ対策をすれば、OSのメーラーで会社のメールが読めるようだ。

だから、もともと出張が多い人はこの方法で対応しているのだろう。

一方で、リモートアクセスの画面転送方式であれば、セキュリティ面の懸念が小さいので、特段の制限はない。私物の端末を使っても問題ない。

業務用のスマートフォン・タブレットを使う場合でも、使用頻度が低い場合はこちらを選ぶ可能性はありそう。(共用の場合など)


というわけで、週の中間ぐらいに一度チェックして、社宅関係の情報があったら確認するようにしようかなと。

仕事の話は無視しとけばいいわけだけどね、(どうせ緊急の連絡なんて入るわけがないし)

こういうことができてしまうのも、在宅勤務制度のおかげなので、ありがたい話ですけどね。

出張や私用(給与明細確認など)のような在宅勤務以外で使うことの方が多いっていうね。

在宅勤務でも使ってるけどさ。今まで1回だけだけど。でも来月またやる予定だし。


Author : hidemaro
Date : 2018/07/04(Wed) 23:27
コンピュータ | Comment | trackback (0)

Unicodeだと使える文字

曲名に「✿」と入った曲があって、そんな文字使うんだと驚いた。

絵文字かなと思ったけど、U+273Fということで、Unicodeでは携帯電話由来の絵文字ではなく装飾記号(Dingbats)に登録されている。

周りを見てみると、丸囲みの数字なども含まれているが、絵文字のようなのも多い。


こんな字あったっけ? と思ったが、やはりJISコードには登録されていない文字だ。

JISの文字コードもいろいろあるが、基本的なのが JIS X 0208にある文字だ。

ここに登録されている文字は昔から無難に使えると言われていた。

JIS X 0208には登録されていないが、Shift_JIS というか CP932 だけで使える文字もあったりして複雑だったんだよね。

ただ、そういうのを含めても「✿」というのは登録されていない。


というわけで、従来では日本のコンピュータでは使えなかった文字ですね。

というか、今までどの文字コードにもなくて、Unicodeで新規で追加された文字のような気がするんだよな。

あと、Dingbatsに登録されている文字には絵文字と併用になっている文字もある。

例えば ☎ は絵文字併用の文字で、Androidで見ると絵文字として表示されるし、絵文字として入力することもできる。

ただ、✿ は絵文字として使われる文字ではないので、なかなか出しにくいよね。


曲名や歌手の名前で「♥」または「♡」が入ることがある。

ハートマークは一般的な記号だが、JIS X 0208 には登録されていないし、CP932 にもなかった。

そんな経緯もあって、ハートマークが収録されていないフォントもある。

EUC-JP, Shift_JIS, ISO-2022-JPといった文字エンコーディングで使えないので、

表記上は▼など他の文字に置き換えて、注釈で「『▼』は黒塗りハートマーク」などと記載することもあった。

もはや UTF-8 のようなUnicodeベースの文字エンコーディングが普及したので、あまり気にせず使われることも増えたが、

コピペすると正しく表記されないなどトラブルを引き起こしかねないのが悩み所である。


それにしても「✿」なんてのが入ってくるのは初めて見たな。

Unicodeで使える文字は増えたが、実際に日本で使うかというとそうとも言えない。

例えばドイツ語の「ß」とか、今は日本でもUnicodeなら使えるけど、そもそもほとんど使わない。

結局は大半は JIS X 0208 や CP392 の範囲で済まされているというのが実情ではないだろうか。

そんな中で特徴的なのがハートマークと絵文字かなぁと。使うところではかなり高頻度に使われる文字種だ。

特に絵文字はE-mailのUnicode化を推し進めるきっかけになったんじゃないかな。

以前はE-mailと言えばISO-2022-JP 一択だったが、最近では絵文字対応なども考慮してE-mailでUTF-8が使われることも増えた。

そもそもISO-2022-JPってどうなんだよと思ってたので、よい方向だと思いますけどね。


Author : hidemaro
Date : 2018/05/23(Wed) 22:23
コンピュータ | Comment | trackback (0)

RAMチェックって何のため?

組み込みシステムではしばしばRAMチェックを行うことがあるよう。

RAMの読み書きが正しく出来ているか確認するんだけど、なんでそんなことするんだ?


というわけでチームリーダーに聞いてみた。

すると、ワンチップマイコンだとそこまで必要性はないかもしれないが、と前置きした上で、

メモリが外付けされている場合、CPU~メモリ間のバスが故障していないかをチェックしたいと。

やり方はいろいろあるのだが、データを書いて、データが正しく読めるか確認する。

アドレス・データのパターンをうまくやると、データバス・アドレスバスの故障を検出することができるわけだ。

記憶素子の健全性を確認するという意味合いもあるのは確かだが、バスの健全性を確認する方が意味合いとしては大きいのでは? とのことだった。


データバスの故障を検出する方法は比較的簡単だ。、

あるアドレスに 0x55555555 と書いて 0x55555555 を読み出す、0xAAAAAAAA を書き込んで 0xAAAAAAAA を読み出すという方法がある。

もし、データバスの0bit目が故障して0固定になっていたら、0x55555555 を書き込んでも 0x55555554 としか読めない。

16bit目が1固定になっていたら 0xAAAAAAAA を書き込んでも 0xAAABAAAA と読めてしまう。

アドレスバスの故障検出はもうちょっと複雑だが、書き込んだアドレス以外のデータが壊されていないか確認するというのが基本的な考え。


RAMチェックもいろいろな方式があるけど、現在のRAMデータを破壊する方式が多い。

システムが動いているときにメモリの中身が壊されたら正しく動くわけはないわけで、

起動時にメモリを使い始める前にRAMチェックを行う必要がある。

稼働中にRAMチェックを行うシステムもあるみたいですけどね。

破壊してもよい領域でRAMチェックを行うか、データを破壊しない方式でRAMチェックを行う必要がある。

いずれにせよ、どういう故障を想定してRAMチェックするのかということは考えるべきですね。

それによってやり方も変わってくるので。バスの心配ならワンチップマイコンなら不要な気はするので。


PCのRAMチェックといえば memtest86 が有名だが、けっこういろいろな故障を想定しているんだね。

MemTest86 Technical Information #Individual Test Descriptions

アドレスバスの故障、データバスの故障、記憶素子の故障 というのもあるし、

キャッシュ回路やバッファ回路の故障をあぶり出せるように、アクセス順序を変えたり、データ幅を変えたりいろいろやっている。

どこまでチェックするかって話ではあるんだけど、それはまさにどういう故障を想定するかという話なんだよね。

そこを考えないと的確なRAMチェックにならないと理解した。


Author : hidemaro
Date : 2018/05/22(Tue) 23:41
コンピュータ | Comment | trackback (0)

アセンブラ時代の工夫?

最近、アセンブラでかかれた昔のプログラムを解読している。

最初はバイナリを解析させられるのかと思ったが、ちゃんとしたソースコードがあったから助かった。

あと設計を書いた資料もそれなりにあって、といっても細かい部分はソースコードを見ないとわからないんだけど。


アセンブラでプログラミングなんてあんまりやったことはないけど、高専時代にちょっとやった。

細かい記法はマイコンのコアによるけど、基本的なところは同じだ。

ニーモニックコードの意味とかはマイコンのマニュアルを見ないとわからないけど、

これがロード命令で、これが足し算でとかいうぐらいは見ればだいたいわかる。


アセンブラで書いているのは、まさにCPUの動作そのものなので、人間にとって理解しやすいかはなんとも言えない。

もともと人間が書いたソースコードなので、人間が理解できる範囲で記述されているのは確かなのだが。

とはいえ、レジスタの値を破壊しながら処理をしていくのは、なかなか読みにくい。

ビットシフトをすると、あふれたビットはキャリーフラグに入る。

これを利用して レジスタBを1ビット右シフト→キャリーフラグで分岐 ということをやるプログラムがけっこうあった。

Cだと普通はこんな書き方をするんじゃないかなぁってのが、

long flg=1, result=0;
for(long i=0;i<8;i++){
  if(((enable & flg) == flg) && judge[i]){
    result |= flg;
  }
  flg <<= 1;
}

こうなるような感じですかね。

for(long i=0;i<8;i++){
  if(((enable & 0x01) == 0x01) && judge[i]){
    result = (result>>1) | 0x80;
  }else{
    result = (result>>1);
  }
  enable >>= 1;
}

結果的に得られるものは一緒のはずだけど、どっちが直感的かっていうと前者だよね。


あと、リソースを節約するためかしらないけど、1つの変数のビットごとに意味を割り付けてあることが多いのも困った話だ。

変数Aの bit0に完了フラグ、bit5~2に動作モード、bit7~6に外部入力の状態とか。

こんなの無理やり1つの変数にまとめるなよって思うんだけどね。

ビット単位に割り付けたせいで、ビットシフト、AND・OR演算、ビット操作命令 を複雑に操る必要があるんだよね。

それをCで書いてあるならまだよいのだが、アセンブラですからね。


さすがにこれからアセンブラでコードを書くと言うことはないのでご安心を。

この解析結果を基に、新しいシステムの仕様を決めて、新しく作るのはCで書くことになる。

こうやってアセンブラのソースコードを読むと、わかりにくいなと思う一方で、人間の理解を超えない範囲で書かれていることに気付く。

Cで書いてコンパイラに機械語を作らせると、人間が理解できない機械語でもよいから、性能をもっとも引き出せる機械語を生成できる可能性が高い。

昔はマイコンのリソースも限られていたから、リソースの割り付けを人間がうまく工夫して高速化することもできたのだろう。

でもそんなのはきっと過去の話。今はコンパイラにお任せが最善策だろう。

Cで書かれていればアセンブラよりははるかに理解しやすいですから。それで十分かはさておき。


Author : hidemaro
Date : 2018/04/09(Mon) 22:42
コンピュータ | Comment | trackback (0)

プリレンダリングでなくてもスマホは燃えない

今どきのスマートフォン向けゲームはリッチなものが多いんだけど。

『アイドルマスター ミリオンライブ! シアターデイズ』の“13人ライブ”ってどんなもの? 田中琴葉の到着を記念したプチ特集も【先出し週刊ファミ通】

これは2月のニュースだが「アイドルマスター ミリオンライブ! シアターデイズ」に 13人ライブ という新モードが追加されるという話が出ている。

この話を聞いて「スマホ爆発しそう」とか性能面での不安を言う人もいたが、

この時点ではそうでもないのでは? という話もあった。


このゲームではコミュ画面、ライブ画面ともにリアルタイム3Dレンダリングでキャラクタを描いている。

それなりに性能面での要求はあって、といっても今どきのスマートフォンなら問題はないが。

でも電力消費は相当ですね。けっこう熱くなる。

従来、同時に描画するキャラクタはせいぜい5人ぐらいだから、

それが13人になると性能的には大変なのでは? という心配があったと。

でも、そこまで人数が多いのならば、あらかじめ作成した動画を再生するという プリレンダリング という手もあるのでは? という話もあった。

実際、過去にアイドルマスターシリーズではPS3で13人ライブがあったが、これはプリレンダリングだったそうだ。


ただし、プリレンダリングにするには条件があって、キャラクタの配置・衣装が固定できることだ。

好きなキャラクタを選んで、好きな順に並べて、持っている衣装から好きな衣装を選んで、とできるのはリアルタイムレンダリングだからこそ。

この13人ライブのコンセプトからして、並べられるキャラクタは13人固定でよい。並び順も固定というのなら、それはやむを得ないだろう。

でも、衣装は固定ってわけにはいかないんだよね。

なぜならば、この時点で公開されていた映像では「FairyTaleじゃいられない」の専用衣装を使っていたが、これは有料で販売予定となっている。

ということはこの衣装で固定にしてしまうと、衣装を購入した人以外は13人ライブは使えないことになる。

全員が持っている衣装「シャイニートリニティ」の映像と2種類用意しておけば、買わないとプレイできないということは避けられるが、他にもいろいろ衣装ありますからね。


そんな13人ライブの続報が先週に出た。

開発中のものを実際にプレイして見せてくれたのだが、なんとキャラクタの並び順は変えられるわ、衣装は変えられるわ。

すなわち、リアルタイムレンダリングだったのだ。

全員個別の衣装を選べるようで、理論上は全員をSSR固有衣装に交換することもできそうな感じだった。

これは予想外だったのだが、リアルタイムレンダリングならあえて制限する理由もないのは確か。

これを見て「スマホ爆発しそう」とか言う人が続出したのは相変わらずなのだが。


PS3でプリレンダリングでやったのに、スマートフォンでリアルタイムレンダリング? という話もあったが、

今どきのスマートフォンの性能はよいというのと、あと画面も小さいので妥協できるというのもあったのかなと言われている。

大画面で見る前提ではないってのは確かにありそうだなと思った。


決まり切っているものを描画するならプリレンダリングってのはよい方法ではあるんですよね。

その昔、ゲームボーイアドバンスの頃にプリレンダリングの3Dが取り入れられたゲームがあるという話があった。

ゲームボーイアドバンスは3Dを描画するエンジンを持っていない。けどあらかじめ作成した映像を表示するならやりようはあった。

そんなのあえて言うほどのこと? って感じはするけど、当時はまだまだドット絵が多かったってことなんでしょうね。

そんな中で、リアリティのある空間表現が取り入れられたというのは画期的だと言うことで話題になったんだろう。

さすがに3D描画機能自体を持たないからプリレンダリングってのは今はないだろうけど、今でも使い所はあると思いますよ。


Author : hidemaro
Date : 2018/04/07(Sat) 23:49
コンピュータ | Comment | trackback (0)

リモートデスクトップと画面転送

職場で来月に在宅勤務キャンペーンをやるそうだ。

在宅勤務なら午前だけ勤務もできる?

このときに書いたけど、このキャンペーンに合わせて新人の定義が変わり、僕も在宅勤務の対象者になるという話。

その結果として、僕もキャンペーン対象者になると。


さて、今月。在宅勤務でやることが想定される仕事として、論理シミュレーションがある。

うちの職場では論理シミュレーションをワークステーションで行うので、

リモートデスクトップを使ってワークステーションにアクセスして論理シミュレーションを行う。

これを在宅勤務でも出来るのかと思って、いろいろ調べていたらできることがわかった。

もともとリモートでやってるので、リモートでやりやすい仕事なのは確かで理にかなった話ではある。


ところで、在宅勤務で使うリモートアクセスの方式にはいくつかある。

リモートアクセスのどれを選ぶか

想定しているのはここでいうところの画面転送方式だ。

リモートデスクトップ+画面転送ということは、なんと画面転送→画面転送 ってなるんだよね。

なんてアホらしい。


でも意外にも性能は悪くない。事前調査の結果、わりと社内でいるのと同じように仕事が出来る。

画面転送ってオーバーヘッドが大きそうなのだけど、いろいろ効率化されているようで。

だから一見非効率だけど、意外といけるみたいで。


というわけで今の仕事なら在宅勤務は全く問題ないなと思っている。

ちょうどよかったなと。

ハードウェアが必要な仕事だとなかなか在宅勤務に向かないからね。


Author : hidemaro
Date : 2018/01/31(Wed) 22:59
コンピュータ | Comment | trackback (0)

静的解析は考え物

プログラムでも論理回路でもそうだけど、ソースコードの静的解析を行って、

静的解析で出てきた指摘事項に対して対応するようにとなっている。

その指摘事項がバグにつながっている場合もあるけど、大半の指摘事項はバグではないのが実情だ。


今は論理回路の設計をしているので、HDLの記述に対する指摘を例に示す。
always @(posedge CLK) begin
  if(SET) begin
    CNT <= 8'd0;
  end
  if(INC) begin
    CNT <= CNT+1;
  end
end

これに対して2つの指摘があった。

1つ目は、1つのalways文の中に2つのif文があるということ。

2つ目は、非同期リセット信号は入っていないこと。


1つ目の指摘は、2つのif文が同時に成立した場合に問題になる。

SET==1 かつ INC==1 の場合、後ろのif文のCNT<=CNT+1 だけが有効で、前の CNT<=8’d0; は無視されるはず。

それが想定通りならよいのだが、普通はこういうのってこう書くよね。

if(SET) begin
  CNT <= 8'd0;
end
else if(INC) begin
  CNT <= CNT+1;
end

こうすると、複数の条件に当てはまるときの優先順位がわかりやすい。

この指摘に対応する中で、本当は SET==1 を優先させないといけなかったとか気づけたという場合もあるだろう。


2つ目の指摘は、通電時のリセットをやらなくて大丈夫? ということ。

通電時のフリップフロップの値は不定とされている。

そこで、通電時にリセット信号を入れて、フリップフロップの値を初期化するということがよく行われる。

このリセット信号は非同期リセットが使われることが通常だ。だから、非同期リセットがない=通電時にリセットしなくていいの という意味だと。

なるほど、確かに非同期リセットしないと、値が不定になって問題だと気づいて修正するとこうなる。

always @(posedge CLK or negedge RSTX) begin
  if(!RSTX) begin
    CNT <= 8'd0;
  end
  else begin
    if(SET) begin //以下略

確かにこれが問題となるケースもあるのだが、常に問題があるわけではない。

SET信号を入力→CNT信号を使う という順序が確立されていれば、通電時のリセットは必須ではない。


指摘事項にはいくつかのランクがあるが、「重要」とか「必須」とかなっているのは、必ず対応するようにというルールになっている。

でも、本当に「重要」とか「必須」の指摘事項って全部対応しないといけないの? とチームリーダーに聞くと、こういう返答だった。

  • 好ましい記述ではないので、バグではないと分かっていても、可能なら修正した方がよい
  • 修正できない・修正しにくい場合、問題ない理由を明確にすればそのままでもよい
  • 既存のソースコードについては、指摘事項が膨大にあるのが実情だが、そこはあえて修正する必要はないだろう

「重要」とか「必須」って言ってる割には、必ず修正するとは限らないんだよね。

特に既存のソースコードは、静的解析結果への対応が十分ではないこともある。

明らかにまずいソースコードもあるのだが、問題を引き起こさないことが明らかなら、あえて修正しないでよいだろうと。


本当にバグにつながる指摘事項というのはさほど多くないのだが、

静的解析がきっかけで、通常のテスト・デバッグでは気づかないような特殊な条件で発生するバグを見つけて直したことがある。

バグではなくても、記述がまずいので、修正しようとなるものはけっこうある。

ただ、これは修正しなくていいだろ、ってなるような指摘事項も少なくはないんだよね。

そういう指摘事項に対して、修正すべきか、理由を示して修正せずに終わらせるのか。

そこら辺の処理がめんどくさいんだよなぁ。静的解析が無意味ではないことは実感しているが、それに伴う手間がなかなか。


Author : hidemaro
Date : 2018/01/25(Thu) 22:54
コンピュータ | Comment | trackback (0)

MOD関数で余りを取るだけでOK

16ビットのカウンタレジスタがあって、

これを定期的に読みに行って、進んだカウント数が妥当かというのを調べていた。

取得したデータをMicrosoft Excelのワークシートに貼り付けて、カウント数の差分を計算してみた。

約100カウント進むので、98, 103… と並んでいるのだが、その中に –65435 というような巨大なマイナスの数が並んでいた。


理由は明確だ。16ビットカウンターなので、0xFFFFの次は0x0000 となるからだ。

なので0xFFFF→0x0000を挟んでカウントが進むと、単純に前後の差分を計算すると、カウント数が巻き戻ったように見える。

-65435というのは、巻き戻った分を考慮すると -65435+65536=101 となるので妥当だ。

と、起きている事象自体は至極当たり前のことである。


というわけで、Excelのワークシートでこれを補正する数式を作ろうと思った。

カウント数の差分がマイナスなら65536を足すとすればよいのだが、

プラスだろうがマイナスだろうが65536を足して、65536で割った余りを計算すればよいのではと思って、次のような数式を書いた。

=MOD(HEX2DEC(C6)-HEX2DEC(C5)+65536,65536)

レジスタをダンプしたデータが16進表記だから、HEX2DECで10進数に戻しているのよね。

これで期待通りに計算できたのだが、もしかして、と思ってこうやって変えてみた。

=MOD(HEX2DEC(C6)-HEX2DEC(C5),65536) 

これでも同じ結果が得られた。


マイナスの数に対する余りってよくわからないんだよねぇ。

Windowsの電卓で –65435 mod 65536 は –65435 とマイナスで出てくる。

正の数に対する余りは正の数で出てくるのに、負の数に対する余りはプラスで出てくるのはなぜ?


符号付き整数のわり算のアルゴリズムってどうなってるの? と調べた。

足し算・かけ算は2の補数表現にしておけば、符号の有無を考慮しなくても問題は少ない。

でもわり算はそういう訳にはいかなくて、負の数が出てくると処理が変わってくる。

それで整数のわり算をやると、-10÷3=-3 のように0に近い側に丸めた整数で出てくるようだ。

余りは –10-3×(-3)=-1 となり、負の数のわり算は負の数の余りになるのは、そういう事情があるようで。


ただ、Excelは数値を実数で扱うので、整数でわり算して余りを出しているのかというとそうではない。

実際 =MOD(1.2, 1) と小数に対して余りを計算することができる。(この答えは0.2)

ExcelのMOD関数の定義は MOD(n,d) = n-d*INT(n/d) なので、コンピュータの整数演算の余りとはまた違う考えなのだ。

MOD 関数 (Microsoft)

なおかつ計算結果を整数に丸めるINT関数の定義は、小さい側の整数を返すということで、=INT(-10/3)の答えは-4となる。

さっきの整数演算で計算した結果と違うことからも分かるように、そういうものらしい。


なので、整数演算で最初に書いたことをやりたければ、やっぱり65536を足して剰余を取る必要があるようだ。

Cで書けば (cnt2-cnt1+65536)%65536 ってこと。

ただし、16ビットカウンターのカウント数の差分を計算するっていう観点ではもっとシンプルな方法もある。

16ビット符号なし整数型で計算すればいいんだ。すると 65535-1 は 2 になる。オーバーフローは捨てられるから。

実はそうなんだよね。16ビットカウンターの計算をするなら16ビットでやればいいんだよ。

実際、16ビットカウンターも0xFFFFの次を0x0000にすることを意識してやっているわけはなくて、

0xFFFF+1=0x0000 になってるってだけの話なんだよね。オーバーフローがなければ 0x10000 になってしまうところだけど。


というわけで、Excel特有の問題をExcel特有の手段で解決したという見方も出来る。

MOD関数の動きは独特だけど、好都合なのでよしとしましょう。


Author : hidemaro
Date : 2017/09/06(Wed) 23:23
コンピュータ | Comment | trackback (0)

Tools