ちょっと前にcabalを1.16に上げようとしたらエラーになってた。。。 で、結構困ったのだけど、エラー内容ググったらここにたどり着いた。
というわけで、ghc-pkg recache実行したら無事に問題解決
ちょっと前にcabalを1.16に上げようとしたらエラーになってた。。。 で、結構困ったのだけど、エラー内容ググったらここにたどり着いた。
というわけで、ghc-pkg recache実行したら無事に問題解決
読み終わったのは結構前で内容忘れているのだけど、
読んだ本。
この本、何というか問題にぶち当たった時に小さな何かを変えるだけで、
事態が好転していくものだよ!って本だったと思っている。
それは環境だったり習慣だったり考え方だったり。
小さな何かを変えると結果は大きく異る。
そういうポイントを抑えた改革をすれば低予算で・・・
って言うビジネス書に入るのだと思う
さて、昨日TL上でとある夫婦の話が話題になっていた。
最後の1ヶ月。TLで流れていたのは違うアドレスでしたが。
これの結末の話は置いておいて、この話で奥さんのした提案は
スイッチで言いたかった小さな変化だったのではないかな?と思う今日この頃です
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ビット変数なのでちょっと気持ち悪いです。
だらだら書いてきましたが、ようやく本題の落とし穴w
ただ、こちらは超簡単です(え?
元記事と同様に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の出力は初期値通りなので問題なし。
問題というかハマることがあるのが真ん中の2つ。
5という値を連結するため、
4つ目の出力の0b010101101が2,3番目にも出そう(と思わないですか?)ですが、
実際のところは、"5"やint_fiveは1ビット変数として連結される。
冷静に考えると、ビット幅の定まっていないものを連結しようとしているのだから、
こうなるのもわかるのですが、ハマるときはハマると思います。
職場でQEMU使ってみましょう!ってことになって入れてみた。
の2つに試しに入れていた(後者は動かした)のだけど、 やはり他の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系がよいようです