スイッチ

読み終わったのは結構前で内容忘れているのだけど、
読んだ本。

スイッチ！

スイッチ！

この本、何というか問題にぶち当たった時に小さな何かを変えるだけで、
事態が好転していくものだよ！って本だったと思っている。 それは環境だったり習慣だったり考え方だったり。
小さな何かを変えると結果は大きく異る。
そういうポイントを抑えた改革をすれば低予算で・・・
って言うビジネス書に入るのだと思う

さて、昨日TL上でとある夫婦の話が話題になっていた。
最後の1ヶ月。TLで流れていたのは違うアドレスでしたが。
これの結末の話は置いておいて、この話で奥さんのした提案は
スイッチで言いたかった小さな変化だったのではないかな？と思う今日この頃です

SystemC: 連結の落とし穴

SystemC

SystemC Advent Calendar2012 の 11日目がbool型を連結するのはやめましょうでした（リンク先は同一）。
下手をしたら本記事は12日目ということになるらしいですが、
それはリンク先の人が決定するので、細かいことは知りません なりました。

本題。個人的に、連結の落とし穴と言えば別の方だったのでそれについての記事。
ただ、元記事は別の方向でちょっと興味を惹かれたので、まずはそちらを。
何に興味を惹かれたかと言うと、出力結果。
出力部分を引用させていただくと、

in = 0b011111010
out = 0b000000001

ここで、in,out は共に sc_uint<8> で、2進表現で出力しているわけですが、
ここで思ったこと、この表現9ビットじゃないか？ということ。
ちなみに、試しに sc_int<8> 型の変数tmpに上述のinと同じ0xfaを代入して、
2進表現させてやると、

tmp = 0b11111010

あれ？今度はちゃんと8ビット。。。
signed 変数ならば最上位が符号だからそのままのビット幅で出せるけど、 unsigned のときは1ビット追加して、最上位に0を付加して正の数だと明示すると。
親切な気もするのですが、あくまで8ビット変数なのでちょっと気持ち悪いです。

だらだら書いてきましたが、ようやく本題の落とし穴ｗ
ただ、こちらは超簡単です（え？
元記事と同様にboolが関わりますが、とりえあず下記のコードをどうぞ。

#include <systemc.h>

int sc_main(int argc, char **argv)
{
    sc_uint<8> out1, out2, out3;
    sc_uint<5> in1;
    unsigned int int_five;
    sc_uint<3> sc_five;

    in1 = 0x15;
    int_five = 5;
    sc_five = 5;

    out1 = (in1, 5);
    out2 = (in1, int_five);
    out3 = (in1, sc_five);

    cout << "in1 : " << in1.to_string(SC_BIN) << endl;
    cout << "in1,5 : " << out1.to_string(SC_BIN) << endl;
    cout << "in1,int_five : " << out2.to_string(SC_BIN) << endl;
    cout << "in1,sc_five : " << out3.to_string(SC_BIN) << endl;

    return 0;
}

出力は次のようになる

in1 : 0b010101
in1,5 : 0b000101011
in1,int_five : 0b000101011
in1,sc_five : 0b010101101

まず、in1の出力は初期値通りなので問題なし。
問題というかハマることがあるのが真ん中の２つ。
5という値を連結するため、
4つ目の出力の0b010101101が2,3番目にも出そう（と思わないですか？）ですが、
実際のところは、"5"やint_fiveは1ビット変数として連結される。
冷静に考えると、ビット幅の定まっていないものを連結しようとしているのだから、
こうなるのもわかるのですが、ハマるときはハマると思います。

QEMU on CentOS の続き

前回の記事でCentOS5へのインストールに失敗したわけですが、 その後日談。。。。。 試しに1.1.0をインストールしようとすると問題なくインストール可能。 ちなみに最新版の1.3.0は当然NGだけど、CentOS6にはやっぱりインストール可能。 気になってUbuntuに入っているバージョン確認したら結構古い（バージョン失念 で、Mac Homebrewで入れている奴は普通に1.3.0にupdateされた。 てっきりapt-getで入れているUbuntuは最新に追従していると思っていたけど、 そんな状況ならCentOSも1.1.0でとりあえずいいかな・・・と

QEMU on CentOS

職場でQEMU使ってみましょう！ってことになって入れてみた。

  • 自宅Mac(homebrewで)
  • 会社Ubuntu(apt-getで)

の２つに試しに入れていた（後者は動かした）のだけど、 やはり他のEDAツールとの絡みからCentOSで動かしたいかな・・・と。 殆ど自分専用になってしまっているマシンがあったからCentOS 5.6でチャレンジ。

多分楽勝だろうと思ったら大苦戦。 まず、yum install qemu とやろうにもなくなっていた。。。 その後、ソースからのビルドを試みたのだけど、 make で下記のエラーになってしまった。

lt LINK libcacard.la /usr/bin/ld: libcacard/.libs/vcard.o: relocation R_X86_64_PC32 against `vcard_delete_applet' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status

この後、調べたら -fPIC は意図的に削られていたことがわかったりで、 結局有効な解決策がわからず。。。。 で、諦めて最近チームで環境整備中のCentOS 6.2（だっけ？）で試したら一発で通った。 というわけで、CentOSでQEMUいじるなら6系がよいようです