ハッカーのたのしみ 5-3から。
先頭から続く0を数えるのは、本質的に2を底とするlog関数。上手く使うと
指数分布するランダム関数が作れる。
・浮動小数点に置き換えて指数部をとる
→この発想は絶対にでてこない。思いついた奴天才。
・if(x<=0x00FFFFFF)の代わりに、if(x>>24)が使える。
→比較(減算)がbitシフトになるだけでなく、命令中に大きな即値がなくなる。
なるほど
・上位から比べるのと、下位から比べるのを同時に評価して、先に収束した
値を返す。
→これは仕事で使えそうだ。
CPUのレベルでやるには大変だけど、Verilogとかなら簡単だ。
ワーストケースが問題になるときには、得意な範囲の違うアルゴリズムを
2つ同時に動かして先に収束した方を解とする。
おもしろいな。
ついに構造体へ。
struct BOOTINFO *binfo = (struct BOOTINFO *) 0x0ff0;init_palette();
init_screen(binfo->vram, binfo->scrnx, binfo->scrny);
アセンブラ（asmhead.nas）で設定してあるのか。
; 画面モードを設定
MOV AL,0x13 ; VGAグラフィックス、320x200x8bitカラー
MOV AH,0x00
INT 0x10
MOV BYTE [VMODE],8 ; 画面モードをメモする（C言語が参照する）
MOV WORD [SCRNX],320
MOV WORD [SCRNY],200
MOV DWORD [VRAM],0x000a0000
普通にbinfoをグローバルにおいて、初期値設定すれば良いと思う。
アセンブラで確保した領域とか、メモリマップドされたレジスタ群への
アクセスに構造体でアクセスするのは、ぎりぎりセーフかな。できたら
やらない用がよい。他の人が見て理解できないのと、結局デバッグ時に
アセンブラ出力と格闘することになる。
IDT、GDTが何となくしかわからない。
GDTがセグメントの管理で、IDTが割り込みベクターでよいのかな。
リング構造とかあった気がする。
会社においてある 始めて読む486を読もう、そうしよう。
日記
Verilog Parserみーつけた！
http://vlsicad.eecs.umich.edu/BK/Slots/cache/www.veripool.com/verilog-perl.html
新FPGA
http://www.pldesignline.com/showArticle.jhtml?articleID=193002445
Systemc: from the Ground Up読みました。
よくわかる SystemCによるシステムデザイン入門の次くらいに読んでちょうど良いと思います。
初心者向けの解説本としては、非常に高いレベルでまとまっていると思います。
無理にC++を隠そうとせず、それでいて大事な概念をコードも交えて書いてあります。
インストールの仕方が無いことが、全くの初心者には辛いと思うので、「よくわかる」
から入った方がよいですね。また、実際になにかシステムを組んでみようという場合、
最後まで読み切っても、どうして良いのかさっぱり分からないです。
（これはこの本というより、SystemCの問題）
最後の方に、他の情報へのリンクがあるのはすばらしい。
エラッタも出ているので忘れずチェック。
一冊読んでみて気がついたのですが、SystemCも「万能の一冊」というのは存在しないですね。
まず、C++をどれくらい出すかにも依るのですが、C++の説明を入れ出すと絶対1冊では足りない。
C++の説明を飛ばすと、何をしているのかさっぱり分からない。文法事項の説明だけでは、
最初の一歩的な物が難しい。（例えば、SC_METHODが良いのか、SC_THREADが良いのか）。
これに論理合成が絡んでくるとさらに別の問題が発生する。
そんなこんなで、この本の演習をするべきか、いくつか回路を書いてみるべきか、
次のSystemCの本に行くべきか、C++をもう少し突っ込んで勉強するか悩み中
一応最後まで読んでみた。
p167
チャネルには、primitiveと、hierarchicalの2つのやり方がある。
primiriveチャネルには、port、hierarchy, SC_METHOD、SC_THREADが
無い。(一つでもあったらhierarchicalチャネル)
p169
チャネルは決してコピーされるべきでない。
→コピーコンストラクタのオーバライドの理由？
p174
sc_channelは、sc_moduleと同じ？
kernel\sc_module.hにこんな記述が！
typedef sc_module sc_channel;
typedef sc_module sc_behavior;
P176
違うインターフェイスをつなげるために、専用化されたチェネルがアダプター。
p190
SC_CTHREAD内での記述
wait(N)と for(i=0;i!=N;i++)wait(); は同じ。
wait_until(delay_expr)と、do wait() while(!expr)は同じ。前者は、delayed()を忘れないこと
p195
動的に接続を切り替える例。ていうか、こういうのはC++のメリット。
p199-
Dynamic Processの例：
ヒントつ SC_INCLUDE_DYNAMIC_PROCESSES
p208
エラーログの（生成方法の）リファレンス
p216
やっぱりsmart pointerは使うのか・・
The SystemC Verification library、要チェック
p219
「初心者にはデザインをコンパイルするだけでも最初の壁になる。」
電車で読んでいて思わず吹き出した。
p221
Reuse Methodolog Manualを買おう。
p221
SystemC lint
http://www.actisdesign.com/
pp146
sc_signal_out_ifは、sc_signal_inout_ifをdefineしているだけ。
request_update(), update()等は、sc_signalから継承。
p148
portはelaboration中に初期化されるpointerである。
なので、
sc_event_finderを使うと。
static sensitivityには、イベントの参照を渡す必要がある。
P152
portの初期化にはinitialize()を使う。
=operatorの混乱を避けるため、write()関数を使う。
p155
sc_portは配列にもできる。通信関連で便利。
p157
配列にしたsc_portはsize ()で数を取得できる。
SystemCのポート、インターフェイス、チャネルがわかりにくかったが
少し整理できた。
基本形
sc_port < interface> portname;
ポートは、Verilogのport宣言と同じ、外部への入出力。
portには、使用するインターフェイスを記載。
ここには sc_fifo< >とか、sc_signal<>とかがくる。
このインターフェイスには、ポートにアクセスするための関数(read()等)
が提供される。
実際にインターフェイスを実装している(read()関数の中身がある）所が
チャネル。
インターフェイスとチャネルの実装にpure virtual functionが使われて、
実際のportへのアクセスには、portへのポインターが使われる。
最後の方は消化仕切れていない・・・
Chapter11までざっと読む。
evalute-updateのパラダイムは、Verilogエンジニアには当たり前だけど、
ソフトの人には難しくないかな。この仕組みって、FFそのものだよな～
って思う。
メモメモ
p100
primitive channelは、ベースクラスとしてsc_prim_channelを持つ。
P105
sc_fifo<>のデフォルトの深さは16
P106
sc_fifo<>は論理合成を意識したときに使う。
パフォーマンス的には、boostのshared_ptr<>でオブジェクトを指して
行く方がよい。一般的には、STL deque<>が、データ数が分からない
テストベンチなどで使える。
p113
sc_signal<>は、verilogのreg宣言とノンブロッキング代入(<=)に
相当する。
p116
DEBUG_SYSTEMCマクロを定位すると、raceコンディションが発生した
時にruntimeエラーが立つ。
p118
pullupの実装例
p124～
いろんなインスタンスの仕方の例。
topは一つだけインスタンシエーションする。（for EDAツール）
コンストラクタを分ける事で、内部の実装を隠蔽できる。
（IPコアなどで、hファイルと、オブジェクトファイル.a、.oのみを
配布することができる）
p141
プロセスの中からポートにアクセスするときは、->演算子を使う。
要勉強。
システム開発 火事場プロジェクトの法則
前半については、この本で無くても他の本でカバーできる。
後半の方が圧倒的におもしろい。
技術書→ビジネス本という流れが僕と共通している。
ただ、自分は会社の中でビジネス本を読んでいるのに対し、この人は会社の外から
ビジネスを見ている。これは全然違う。全然違うことはわかるが、どう違うかは
僕は会社の中にいるのでわからない。
こういう本を読めば読むほど自分は独立できないと思う。
技術というのは独立してやっていくための能力の一つでしかない。
僕は独立してやっていけないから、会社に依存して自分の技術を伸ばす。
とある 5巻読みました。
どう読んでもｇｄｇｄでした。
コンピュータグラフィックス 理論と実践
15章まで。他の勉強がしたくて、全然手を動かせてない。
16章はボリュームでかいが、おもしろくなってきているはず。
読書じゃないけど、C/C++によるVLSI設計―SystemCによるJPEGコーデック設計
ちゃんと家にあった。良かった。
どうもSC_MODULEの書き方が気持ち悪かったのが解決。(p59)
SC_MODULE module_a; ならわかる。もしくは、SC_MODULE("module_a")でしょ。
なんで、SC_MODULE(module_a)なんだとずっと気になっていました。
SC_MODULEはsc_module.hでこう定義されていました。
#define SC_MODULE(user_module_name) \
struct user_module_name : sc_module
なので、SC_MODULE(module_a)というのは、
struct module_a : sc_module
に「マクロで」展開されます。要するにsc_moduleを継承したstructを定義している。なんか微妙。
（p70を見るとEDAツールの都合もあるみたい）
続いて、p64には、コンストラクタで引数を与えたい場合は、SC_CTORマクロを使わずに
書く方法が乗っている。
ちなみにSC_CTORの定義も、sc_module.hの中に。
#define SC_CTOR(user_module_name) \
typedef user_module_name SC_CURRENT_USER_MODULE; \
user_module_name( sc_module_name )
そのときは、SC_HAS_PROCESSを使うと。
Chapter7まで読みました。一気に読めそうなのですが、ただ読んでもしょうがないので
スピードを落としてまとめ中。
その中からメモメモ。そして、このメモが一番役に立つのは間違いなく1年後の自分。
p44
32bit以下のsc_intしか使わないなら、-D_32BIT_ フラグをつけてコンパイルすると速くなる。
sc_intはC++のintより遅い。論理型も、boolや、bitsetの方が速い。
p47
コンパイル時間を速くするために、固定小数点はデフォで入っていない。
ヒント:SC_INCLUDE_FX
p58
Elaborate中にやっていること
クロック、モジュール、チャネルのインスタシエーションと内部接続。
p64
sc_moduleはname()関数でインスタンス名を取得できる。
p72
sc_start()は引数でシミュレーション時間を指定できる。
時刻の出力は、
cout << sc_time_stamp() << endl;
p78、83、86
SystemCのイベントは、リアルタイムOSのイベントとはちょっと動きが違う。
前もってwatchしていないと意味がない。
WaitForSingleObject()のシグナル状態という概念も無い。
複数のイベントをwait()したとき、どのeventが発生したのか知る方法はない。ﾏｼﾞｶﾖ
さらに、発生する前ならcancel()できる。ワォ！
→ セミナーの先生いわく、この辺は規格で変わりつつあるらしく微妙。
p81
明示的にwait()を入れなくてもwait()が入る場合がある。
ヒント：sc_fifoへのアクセス
p91
SC_METHOD内ではwaitを入れられない事に注意する。
ヒント:sc_fifo
p96
シミュレーションエンジンは時刻0の前に、全てのプロセスを内部的に実行する。
防ぐためにはdont_initialize();
速い順に
C++の組込型:int, double, bool
sc_in<>, sc_unit<>
sc_bit, sc_bv<>
sc_logic, sc_lv[]
sc_bigint<>, sc_biguint<>
sc_fixed_fast<>, sc_fix_fast, sc_ufixed_fast<>, sc_ufix_fast
sc_fiexed<>, sc_fix, sc_ufixed<> ,sc_ufix
なるほど。
SystemCの某トレーニングを受けてきました。
講師の方のレベルも高く、非常に満足してきました。
会社のお金で行っているのであまり詳しくは書けないのですが、
論理合成という面でみるとSystemCはまだまだだと思う。
SC_CTHREADの本質なんて書き方買えたRTLじゃん。リセットがきたら
最初に戻って、CLKが来たらwait()の次のステートへ。演算部分に幅
を持たせていても、本質がRTLと全く変わらない。それが一番のショック。
動作の説明をするのにFFとか、組み合わせ回路とか、そんな説明を
しないといけない言語なんて駄目ですよ。
チャネルを組み合わせて、システムを組んで、ゲートとクロック数の
トレードオフを与えたら、そのまま論理合成へ。ここまでこないと
意味がない。
そして2つめのショックは、もっとC++の勉強をしないといけないと
分かったこと。SystemCがしているC++の隠蔽は中途半端だ。
SC_MODLE()のマクロなんて全然意味がない。
隠すならSystemCの枠組みで全てできるようにする、そうじゃないなら
できる限りC++の枠組みを見せるようにしたほうが、結果的に理解が
早いと思う。SystemCが普及すると、コピペハードウェア設計者が
増える気がする。
とりあえず、SystemCの普及はまだまだだ。遠回りしてでも、C++を
しっかり勉強しておこう。
こんな、今すぐお金にならなくても、京都からの出張費/宿泊代/
セミナー代を気前よく出してくれる会社に感謝。
(うちに来たい人はメールください。)
C言語の気持ち悪いところを書き直しながら、進めたけど色が変わらずはまる。
パレットに与える値を全部0xff（白）にしてみても、全く色が変わらない。
→ つまりビデオのコントローラに全くアクセスできていない。
こんな時こそ、The Undocumented PC: A Programmer's Guide to I/O, Cpus, and Fixed Memory Areasの出番。
と思って本を探したけどみつからない。もしかして、辞めていった人に貸した
ままなのか・・と一抹の不安が。こうやって、PCで遊ぶときのために買って
あるのに、肝心な時に見つからない。使えない本だ。
（嘘、いつか君の力が必要になるから機嫌が良くなったら出てきて☆）
http://community.osdev.info/index.php?VGAを眺める。
qemuのデバッガを立ち上げて、周辺アクセスしてみるか、と表示を切り替えたところで
誰かが呟く。
「OK、兄者、x86アーキテクチャは、I/O空間とメモリ空間は別だ」
そうか、ビデオのコントローラにポインター使ってアクセスしているから駄目なんだ。
ポインターでアクセスしていた所をio_out8()を使うようにする。というか自分が駄目にした
部分を元に戻す。
色ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━!!!!
やっぱり、この本はおもしろい。
VRAMのアドレスのように、システムで一意に決まっている値は#defineしちゃった方がよい。
#define VRAM_TOP 0xa0000
解像度は微妙で、定義しちゃっても良い気がするが、そこは今後の展開を見てみないと
どうなるのかわからない。ただ320と書くよりはべたべたでも定義した方が、後から
見るときに役に立つ。
#define XRESOLUTION 320
#define YRESOLUTION 200
もちろん#define XRESOLUTION320 とかで定義しても良いが、#define CONST320とかは
駄目。ようするに、320という値が解像度ですよ、と宣言することが大事。
できるだけ即値を書かないこと。
同じ理由で、色の#defineも読める形に。
#define BLACK 0 でも良いけど順番に値が入っているから列挙体使っても良いかな。
enum palette_color {
BLACK,
RED, ・・・
};
こうしちゃうと、実際の設定している値0x00ffffと色の対応が取れなくなるのが
ちょっと嫌だけどしょうがない。パレットの定義を変えたら、こっちの色も自動的
に変わるとか、コンパイルでエラーがでてくれたら理想だけど、さっと良い方法が
思いつかない。色テーブルの定義をこの宣言の近くにしてコメントを書こう。
boxfill8の関数もこんな感じで。
void boxfill8(enum palette_color color, int x0, int y0, int x1, int y1)
{
int x, y;
volatile unsigned char *vram_adr;
vram_adr = (volatile unsigned char *)VRAM_TOP;
for(y=y0;y<=y1;y++){
for(x=x0;x<=x1;x++){
*(vram_adr + y * XRESOLUTION + x) = color;
}
}
return;
}
教科書的には、(x,y)か、(x0,y0,x1,y1)を構造体にするべきだけど、そこまで
しなくて良いかな。構造体にすると、座標を渡していることが明確になるので
よりベター。
構造体のポインターを渡すことで高速化のメリットもあるけど、それよりも
引数の意味がはっきりする方が、メリットが大きい。
あと、このコードは引数を間違えると、メモリ空間をどこだろうがお構いなしに
色の値で書き込んでいく。かなり危険。本当なら、assertを入れて、範囲チェックを
入れたいところだけど、今の環境じゃassertを入れてもどうしようもないので、
とりあえずこのまま。
今日はこんな所。
blogに書いているといろいろと思い出す。
昔、2年目の時にFAXの伸張プログラムを書いたんですよ。LHAとZIPの本にも書いてある
のですが、データをバイトとして扱っては駄目で、bitのストリームとして扱わないと
いけない。
あるバイトの何bit目まで処理したかを保持するのに、関数内staticを使いました。
当時の僕には非常にcoolなテクニックに見えたから。
時が経ち、そのソースだけが別の部署のwindowsアプリ上で使われることになったときに、
「マルチスレッド化したら動かない」という面倒なバグに。調べてみたら、そのstaticが
原因でした。
Ｗｉｎ３２マルチスレッドプログラミングが当時は最もわかりやすい本でした。
ソースを補足していくコーナー。
この本はC言語の入門書ではないので、Cのソースについては本当に動いた物勝ち
で、説明もおおざっぱだ。将来の組み込みプログラマの為に、気になった点を
補足していこう。
(1)VRAMへのアクセス
この本では、VRAMへ1バイトのアクセスをするのに char *pを使っているが、
普通はこう書く。
volatile unsigned char *p;
volatileは最適化の対象外にするという意味。
unsignedは、最上位が符号bitでないから、余計なバグを防ぐためにもつける。
こちらも参考に。
http://www.kumikomi.net/article/explanation/2003/10kumi/13.html
(2)ポインターと配列
pをポインタで宣言したときに、
*(p + i) = i;
みたいな書き方はするが、
p[i] = i;
のような書き方は僕はしない。もちろん文法的には同じだけど、ポインターとして宣言
したものはポインターとしてアクセス、配列として宣言した物は配列としてアクセス
が行儀の良い書き方。
*(p+i)とp[i]は、同じ意味だが、char *pと、char p[] = "xxxx"では意味が違う。
(代入できるかどうかや、sizeofが返す値など)
ポインタは配列としてアクセスでき、配列はポインタを使ってアクセスできるが、
2つは違う物です。
その辺りに転がっていれば、C言語を256倍使うための本を参考に。
(3)符号について
char には、signedとunsigned の二つしかない。省略した場合は処理系に応じて
どちらかになるが正しい。「特に指定のない型」などは存在しない。
また、intやshortに関しては、省略したときはデフォでsignedになる。
charのみが、既存の処理系との整合性をとるために、曖昧になっている。
(4)関数内のstatic宣言について
パレットのテーブルをstaticで宣言しているが、これはグローバルに持って行った
方がよい。なんと言っても、デバッガで簡単に値が確認できる。
関数の内部でstaticをつけるのは、その変数をグローバルで宣言して、ラベルを
出さないのと同じ事。普通は、ファイルを分けて変数名を隠蔽し、アクセスする関数
だけをHファイルで公開する。（中途半端だけどカプセル化）
関数の内部でstatic宣言する方法は、他に方法が無いか良く検討した方がよい。
変な癖がつくとマルチスレッド化したときにはまるぞ。
とりあえず4日目までは動いたもん勝ちみたいなソースで、それはそれで楽しい。
偉そうなタイトルを付けるとグーグルで上の方に行くんだよなぁ。
間違って飛んでくる人もいると思うけど、現段階（2006/9/19）では、ほとんど読んでいません。すいません。
(1)Advanced Verification Techniques: A Systemc Based Approach For Successful Tapeout
(2)Transaction Level Modeling With SystemC: TLM Concepts And Applications for Embedded Systems
(3)Systemc: from the Ground Up
邦訳は基礎から学ぶSystemC
(4)System Design With Systemc
邦訳はSystemCによるシステム設計
(6)Advanced Verification Methodology Cookbook
(7)よくわかる SystemCによるシステムデザイン入門
(8)C/C++によるVLSI設計―SystemCによるJPEGコーデック設計
(9)Systemc: Methodologies and Applications
(10)A SystemC Primer
(1)から(7)までは、今机の上にそろってます。
(7)だけはざっと目を通している。
SystemCの事よく分かっていないのですが、分かっている振りをしてプレゼンするのに使いました。
プレゼンを聞いてくださった方、どうもすいません。一冊を斜め読みしかしていませんでした。
(1年以上前だし、時効にしてください）
(6)はメンターからもらった本。Webで同じ内容がダウンロードできます。
SystemCに限った話じゃないけど、おもしろそうなのでリストアップ。
これに、systemc.orgからダウンロードできるPDFが2つ(SystemC_2_1_features.pdfとFuncSpec20.pdf)。
(8)は家に帰ったらある気がする。
(9),(10)はまだかっていない事に気がついたので、(10)は早速アマゾンで注文。
(10)は、http://www.ebooks.com/ebooks/book_display.asp?IID=236586#buyで買えるので、どちらが
良いのか悩み中。パソコンで見る方が良いのか、本の方がよいのか。値段よりもそっち。
PDFで読み切ったちゃんとした本って、Data Crunchingくらいだし・・・・。
で、どの本を読むかというのは、あまり問題にならない。
全部読みたいから、問題はどの順番で読むか、だ。
(1)(2)(5)(8)は最初の一歩とは違う気がする。(9)、(10)は未入手だし、(6)はちょっと違うからはず
して、選択肢は、(3),(4),(7)の4つ。
番号順で(3)からに決めた。
(7)も今見たらおもしろそうな事書いてあるからちゃんと読まないと、このままだと
「インストールについて詳しく書かれた本、Untimedとかキーワードを拾うのに便利」
みたいな、かわいそうなレビューになってしまう。
せっかく本を作っている人がいるので、頑張って読もう、そうしよう。
30日OS
ずーっと棚においてあったのですが、C++の勉強が一段落したので手を出す。
3日目くらいで、Cの書き方にどんよりする。
ここで批判だけしても全く意味がないので、批判ではなく補足という感じで
普通はこう書くよ、みたいな物をまとめてみようかと思う。
これも時間かかるな～。
Oversea Pubilshing
GNU開発ツール
こんな本がでていたなんて知らなかった。
速攻注文。
これも、Insight c++ object modelと同じくらい重要な位置づけになりそう。
コンピュータグラフィックス理論と実践
思い出したように読み始めて14章突破。次は15章。
C++ 入門書の次に読む本
読みました。
auto_ptrとか、今まで読んだ本に無い概念にぶつかる。というか、C++の本はとりあえず、
5冊くらい読まないと、全貌が見えない。継承に関する考え方（実装方法）も作者によって
違うだろうし、いろんな目でいろんな機能を見ないと行けない。等、考えてしまった。
LHAとZIP
ちょっと読んで断念。
この本に期待していたことは、C++のいろんな機能を実際のアプリでどのように
実装するのか、なのですがあまりそちらの説明は少ない。
圧縮に関しては、bit操作がメインなので、C likeな書き方になるのはしょうがない
けど、ちょっと求めている物と違うのを感じて勉強中止。
ざっと、コラムっぽい所だけ読ませてもらって、アルゴリズムの解説は飛ばしました。
思い出したのは「データ圧縮ハンドブック」という本。フロッピー付きで、いろんな
アルゴリズムをCソースでどのように実装するかを詳しく書いてあった。
買って勉強したのは覚えているんだけど、本自体がどこに行ったか忘れた。実家帰ったら
探そう。
Insight c++ object model
内部の実装を調べるのに便利そうな本だけど、調べてみると邦訳も含めて入手困難らしい。
ふと、本棚を見たら既に買ってあったのでぱらぱらと立ち読み。
キタ━━━━━━(ﾟ∀ﾟ)━━━━━━!!!!
これは良い。
この手の本は手を動かさないといけないので時間がかかる。
しかし、僕のやりたいことを実現するためには、必須の知識なので読んでみよう。
知っておきたかったこと
http://www.shiro.dreamhost.com/scheme/trans/hs-j.html
今、大学生に戻れるとしたら、もうすこしゲームを減らして、物理学を勉強しよう。
大人になってから、物理学で学んだことの応用は学べても、物理学そのものを学ぶの
は難しい。特に、理解の間違いを即座に指摘して、正しい答えを教えてくれる機会
なんてほとんど無い。
たとえば、君が大学の1年生で、数学と経済学のどっちを専攻しようかと 迷っているとする。 この場合はね、数学の方が選択肢がひろがるんだ。 数学からはほとんどどの分野へも 進むことができる。数学を専攻していたら、 経済学の大学院へ進むのは簡単だろう。 でも経済学を専攻して、 数学の大学院へ進むのは難しい。
この情報を高校の先生は知らない。もちろん、僕が高校生の時、僕自身はこの事を知らないまま、
理学部 物理学科に進んだ。今は、たまたま進んだこの学科で学んだことに感謝している。
もっと勉強しておけばと悔やむのは簡単、だから今勉強しよう。
理系たまごの英語40日間トレーニングキット10日目終了
完全に1日分/1週ペース
・frequency distribution 度数分布
frequency＝周波数決め打ちになっていたけど、頻度という意味でも重要単語
・map 写像
写像ってmapなのか。というより、mapに写像って訳を当てた人は偉いな。
日本語のすばらしいところはテクニカルタームとそうでないものが、簡単に区別が
つくところ。その分、初期投資はしているわけだけど、"word"でワープロソフトの
使い方を検索しないといけない外人さんに同情。
ハッピィエンジニアリング
読みました。
日本版デスマーチ。
前半は非常におもしろい。そちらの業界にいなくて本当に良かったと思う。
しかし、大企業の方の設計能力が下がっている現実や、ソフトで起きたことは
数年後にハードの世界に降りてくる現実を見ていると、そのうちハードの設計
でも同じ事が起きそうな気がする。
一番大事なことはお金を出す側が、しっかりと決定権を行使し、その結果の責任
を負うこと。しかし、下っ端ができることは、全員一丸となって終わらせること
だと思う。(←徹夜しろって意味じゃないよ)
最近のキーワードはやはり「チーム！」
ゲリラ流 最強の仕事術
読みました。
無理して読まなくても良いし、この手の本を読んだことがないなら読んでも良いかな、くらい。
アマゾンの書評にあるとおり、過激なタイトルの割にはまじめな本でした。
次のキーワードは「ライフバランス」。
10月から始まる、共稼ぎ＋娘の送り迎え生活。頑張ろう。
とある魔術の禁書目録 3巻
読みました。
一人くらい僕に(ry
出張があったので、電車の中で読む。
最初の数章は広義のPLDの歴史から始まって、各ツールが使っているアルゴリズムを
あっさりと説明。実はこの辺りが一番おもしろい。
後半に入ると、各プロダクトの説明っぽくなってきて、いまいちおもしろみがかける。
各アーキテクチャ毎の、圧倒的に強い部分や、どうしてもここが弱点みたいな考察が
不十分。商品紹介と、ざっくりしたメリットくらいしか書いていない。
論理合成後のマッピングから、分割にかんしては、純粋にアルゴリズムの話で、有向グラフの
モデルとかが出てきて驚く。もっと学校でコンピュータサイエンスを。BASIC教えるのも
いいけど、データ構造とアルゴリズムもしっかり教えるべきだ。
リコンフィグというのがFPGAに対抗する形で存在するのがおもしろい。FPGAが圧倒的に
弱い多ビットの演算(乗算、加算)が一つにUNITになっている物が多い。だから、
演算系の命令は、自在に組み合わせることが可能だけど、FPGAみたいにどんなロジック
でもというわけにはいかない。
噂のDAPDNAについては、簡単にアーキテクチャが書いてある。なるほど、小さいプロセッサ
（それぞれにキャッシュとか持ってる）のデータパスを瞬時に入れ替えることで、
リコンフィグとしているのか。
リコンフィグのメリットが出てくるのは、物理的に小さいところに沢山の演算系の
機能が必要なとき。ぱっと思いつくのがポータブルなカメラとかで、大量の画像、映像の
フォーマットを処理しないと行けないとき。いろんな種類のフォーマットの圧縮/伸張
をする必要があるが、同時に扱うのが1種類とか2種類とかいうのが理想だ。
もうちょっと突っ込むと機能縮退がある装置とかどうだろう。
普段は大量のデータでそのまま処理するけど、回線の調子が悪くなると差分だけ送ったり、
さらに悪くなると、ぱらぱら漫画になったり、最終的にはワイヤーフレームみたいな表示
だけど、最低限の表示をするようなシステム。軍関連とか、危険な作業のロボットとか
そういうところとかどうだろう。
いろいろ考え出すと止まらない。
熱狂する社員
非常に良い本。
人の評価に関しては非常に難しいところがあり、私も模索中です。
この本の中でも出てきますが、日本の終身雇用というのは一つの理想型だったの
かなぁと。しかし、それが崩壊した今、終身雇用に変わる新しいシステムの必要は
感じました。エンジニアより、もしくは１プロジェクトという目で見た場合は
Peoplewareのの方法が役に立つ。（Peoplewareが1980年代の後半にかかれていると
事実は、デマルコのすごいところだと思う。）
この本はどちらかというと、もう少し経営よりであり、長期的視点から物事を見ている。
しかし、この前読んだデスマーチを読んで、チームについて勉強意欲が高まってきた。
また本を読もう。
Data Crunching
読みました。
内容的に不十分ですね。XMLにしてもSQLにしても、もうちょっと実践的な本を読んだ方が
理解が早い。いろんな言語、Python、Java、C++、Perlが出てきて、ある程度のプログラマー
を想定しているようだけど、その割には内容は初歩的すぎし、各言語の特徴の違いがテキストに
生きていない。次のステップへ進むための書籍紹介もいまいち感がある。
データ処理（Data Crunching）で一冊本を書くという発想はすばらしいと思っただけに残念。
SQLとかBinaryの所は一切いらないから、テキストとXMLに限って、もっと突っ込んだ使い方、
デバッグ手法、UNIXのシェルと合わせて具体的なアプリケーションまでいけたら良かったと思う。
翻訳されることはないでしょうが、もし翻訳されたら立ち読みしてから買うのをお勧め。
Druckerから
"Actually, a company can make a social contribution only if it is highly profitable.", [Peter F. Drucker, Management - Tasks, Responsibilities, Practices]
読むのは正直かったるいが、たまにはっとする表現が見つかる。実際の事例とか、歴史的な
説明とか飛ばしてくれればずいぶん読みやすくなるのに・・・。
データの処理の方法について、いろんな角度から書いてある本。
同じような本が無いので、買って読んでいるが微妙な感じ。
特別なテクニックが書いてあるわけではなく、データ処理の概念、用語、基本ツールを説明してある
本。最初のテキスト処理だけで掘り下げて欲しいのだけどそうでもないし、正規表現はPerlの本
見た方が早そうだし、Pythonは使わない人間にとっては疑似コードでしかないし。
読者にどういう人間を想定しているかが絞れていない。
全くの初心者にはパラグラフ毎に言語が変わるのは敷居を高くしているし、ある程度プログラムを
した人には正規表現とかXMLの説明はかったるい。
とはいえ、じっくり読むとはっとするような事を発見できるからおもしろい。
String patStr =
".*?" // anything before the first address
+ "(" // start of group 1
+ "[\\w_\\.-]+" // user name
+ "@" // literal '@'
+ "[\\w_-]+" // first part of domain
+ "(\\.[\\w_-]+)*" // rest of domain (group 2)
+ ")" // end of group 1
+ "(.*)"; // rest of string (group 3)
正規表現にこういうコメントの付け方があるんだとか。
とりあえずXMLの所まで来て、いろんなライブラリや処理方法があることを知った。
実際にXercesでプログラム書きたくなったが我慢。
そこにはいると寄り道しすぎ。
さっと読み切ろう。
某ゼミナーで、光って音が鳴るヨーヨーをもらってきました。
娘にあげようとしたのですが、音がピーピー鳴ってうるさすぎる。
しょうがないので、ドライバで分解し、スピーカへの配線を
切って光るだけにしてみた。
それを後ろで見ていた嫁が「なんで、音だけ止められるの？」と
びっくり。結婚して初めて見せたパパの本気でした。
デスマーチに続いて読んだ本
憂鬱なあんまん本読みました。
勉強になりました。
前にC++を勉強したのが98年くらいだったので、それからこの間に言語使用だけでなく、
コンパイラ、設計手法など、がらりと変わっているのを実感しました。
誤解のページにほとんど自分があたっているのをかんじました。
短期間で読めたのは、Accelerated C++に依るところが大きい。
まずは、Acceleratedで試行錯誤してから、他のC++の本を読むと理解が深まると思う。
なんで、Acceleratedではそんな難しいことをやっていたのか、かなり理解が深まる。
この本を紹介してくれたあんまん戦士に感謝。
球場のビールはなぜ800円でも売れるのか
読みました。
すごい良い本。
特に自分でお客の所へ行って物を売っている人（かつ、売り上げが伸び悩んでいる人）にぜひ。
新しい発見があるはず。アマゾンのレビューにもあるとおり、タイトルは裏腹に非常にまじめ
に経営/営業について書いてある本です。
「スモールビジネス」成功のセオリー90! と合わせて読むのがお勧め。
デスマーチ 第2版
読みました。
実写版ディルバートみたいな感じですが、楽しく読めました。
この本を楽しく読んでいるうちは、まだまだ大丈夫。それよりも、IT先進国の方が
デスマーチが酷い現実を見せつけられた。同時に、インド人、中国人エンジニア
に勝つために、さらなるデスマーチが引き起こされている。
ピープルウェアも合わせて読みましょう。
第1版も読んでいるはずだけど、新しい事をいっぱい発見できた。
読めば読むほど、春の軟禁はデスマーチすれすれだったと思う。無事帰って来れて
ラッキーだったのだが、これをラッキーで終わらせるか、次に続くかはちゃんと
ポストモーテムをしないといけなんだけど、十分できていない気がする。
そしてデスマは繰り返される。
気になった点(1)
チームレビューを！
コードレビューも、回路図レビューも重要だけど、チームレビューも大事。
各役割を持った人間が、正しく機能したのか(というか、チームとして機能をしたのか)
をレビューしよう。そうしよう。
気になった点(2)
プロセスのダイナミックスをきっちりと認識しよう。
生産性が下がる→給料を下げる→生産性が高い人間が辞める→もっと生産性が下がる
とかいうループに対して、関連している要因と、一つのパラメータを変更した
時に与える影響をモデリングしよう。
気になった点(3)
イノベーションのジレンマと相反するところも多い。スパイ大作戦型、カミカゼ型の
プロジェクトでも危険を感じて終わらせてしまえば、イノベーションはそこで終わり。
腕時計でVC++を動かす所にビジネスがあるかもしれない。
そして、アマゾンで参考書籍をカートに入れる。
まだまだ勉強。
26 hour day
終了。予想以上に良いことが書いてあった。（実際にやるのは大変だけど）
それほど、外人っぽい内容でも無いので邦訳されてもよさそう。
GTD本の近くにおいておけば結構売れるんじゃん。
全く新しい幸せを探しに行くより、今目の前にある幸せに気づこう。そうしよう。
インターフェイスの街角
読みました。これはおもしろい。
僕が今まで読んだ本とはまた違う視点からコンピュータを見ている。
基本的には普通のユーザーを見ているんだけど、時折見せるプログラマへの
切り口が楽しい。
読むときには何年に書かれたのかを意識しながら読むのが良い。
VisorでPoBOXを使っていた頃が懐かしい。
PocketBSDの記事もあるので、そっちもなつかしみながら読めました。
ちなみにWebでも読めます。ここ
この人の文章で一番好きな物富豪的プログラミング
憂鬱なプログラマのためのオブジェクト指向開発講座
読んでいます。
突然セガサターンがでてくるのは、あんまん戦士の陰謀。
理系たまごの英語40日間トレーニングキット9日目終了 Σの読み上げが難しい。Y sub i は Yiの事。（添え字）
そういえば、HTMLで数式を定義するのってどうなったんだろう。
Latexみたに書けば、ブラウザが正しく数式を表示するみたいな規格を作ろうって動きがあったんだけど。
26 hour day
module 7 終了：モチベーションコントロールについて。
できる！という強い意志が重要。まさに愛と勇気。そして、健康。
本全体の半分は超えた。
High Performance Memory Testingから。
Appendixまで目を通す。
こっちは考察少なめで、パターンの羅列。
これにて、High Performance Memory Testingの勉強終了
これだけに18000円はさすがに高い気がする（DS lite買える）が、確実に自分の物になったので
OKとしよう。
Accelerated C++
13章突破：Handle Classという概念を勉強。
14章は斜め読み、パフォーマンスアップの為の知識はもう少し後。
テンプレート特化（template specializetion)とか、なんでもありだと思った。
15章も読むだけ。
分かった事はClass設計がトップダウンであること。ベースの型、ユーザーに開放するインターフェイス等、
最初に決めることは多い。C++については、継承して、継承して、みたいなボトムアップなイメージが
強かったので勉強になった。
16章：カーネギーホールのジョークに笑う。
というわけで、Accelerated C++
---------------------------- 終了 -----------------------------------
ついでに「とある魔術の禁書目録」2巻読みました。
この人は、全体のプロットとか、キャラとか良いと思うのに、細かいところが
全然駄目だと思う。もったいない。途中はぐだぐだだけど、最後の方の各登場人物の
エロゲ的立場はおもしろかった。そうきたか、と。
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
