  |
はてなキーワード: レジスタとは
途中エログロあり
あなたはとある本屋のレジスターが壊れたため向かっているエンジニアという設定
レジスターは別のエンジニアがかかりきりで治るまで帰るなと言われる
たちの悪い客が本を盗んだりする
この本は俺が書いたかどうかあててみろ→原著にはその人の名前が書いてないのでNO→残念！これのスワヒリ語版の訳者は俺だ、だから買えとか
刃物持った奴が逃げるのを阻止しようとする
全然飯食ってないんでちょっと出てきます、でこのステージクリアらしい
犬がじゃれてきて後ろ手に縛られたようなかっこうになる
気がつくとどこかの部屋で眠っていてここまでは夢オチ
布団抱えて逃げる
さっきのカフェテラスの1階から上がって行くが階段はなく、机や棚をのぼる
足の踏み場ないほど食器おかれ、さらに手すりにジャムをつけられたりする
やっとのおもいで上の方にいくと下から覗かれる
思ってるうにもちろんのように下からぐりぐりされる
なんとかして上についていちおうクリアらしい
クリア後げろい気分でアプリ削除しようとしたら他に20くらいアプリが入れられてて全部消した
夢でこれだけやられたら腹立つ
コンビニで会計する時にどうにもsuica(≒電子マネー全般)が使いづらい。
1. 品物をレジに持っていく
3. ｢xxxえーん、xxxえーん、xxxえーん、合計xxx円になります｣
4. レジの人が袋詰めし始める。普通はこの時客が現金を用意するとか、そういう並列化がなされてる。
5. 袋詰が終わった後で(現金を期待してそうなレジの人に)｢あ、suicaでお願いします。｣っつって会計してもらう。
本当はシーケンス4で客はsuicaの会計をすべきなんだけど2-4の間で声をかけるタイミングがないし、suicaで支払うにはレジで操作が必要なので作業に割り込んでしまう。
じゃあ初めに言えよということだが、初めに｢suicaで｣と言ってもどうもsuicaの指定をするには総計を出してからじゃないと(レジスターのUI的に)できなさそうで、そこまで"この客がsuicaで支払う"事を覚えてるバイトの人はなかなかいなかったりする。普通は会計は一番後だから。
この｢順番にやる作業は順番に指定しないとダメ｣ってのはスタバの注文とかでもそうだけど、まあその辺を綺麗に頭の中で処理できることを少なくともバイトに期待するのは荷が重い気がする。
「プロテクトかけたアルゴリズムを実装したバージョンに差し替え」たなんて言われると本当に「プロテクト」がかかっているのか確かめてみたくなるのが人情というもの。というわけで、プロテクト強化後のもふったー(v0.9.6b)からconsumer secretが抜けるか試してみた。結論から言うと、あっけなく取り出せた。以下に手順を記す。
動作がよくわかっていないアプリケーションを解析して仕様を明らかにすることをリバースエンジニアリングと呼ぶ。ソフトウェアのリバースエンジニアリングは基本的に対象を逆アセンブルしてひたすら読むことによって行う(その補助に1命令ずつ実行してレジスターやメモリーの様子を観察することもある)。しかし、よっぽど小規模なものでなければオブジェクトコード全体を逆アセンブルして最初から最後まで読むなんてのは不可能だ。人間の読速度には限界があるし、時間も有限だからだ。そして、詳しい動作を知りたい部分というのは全体のごく一部であることが多いので全逆アセンブリを読むのには非常に無駄が多い。
だから、リバースエンジニアリングではいかに詳らかにすべき動作を行っているコードを絞り込むか(=読むべき逆アセンブリを少なくするか)が重要になる。
この場合も同様だ。TwitterのGUIクライアントを頭から読むのは到底無理なので、どうやって解析すべきコードの範囲を狭めるかを考えた。それにはOAuth認証においてconsumer secretがどのような役割を果たすのかを知る必要がある。
OAuth認証で、consumer secretはそのままサーバーに送信されたりはしない。signatureの生成にHMAC-SHA1が使われ、その鍵にconsumer secretが使われる。HMACは次のように算出される。
HMAC (K,m) = H ((K ⊕ opad) ∥ H ((K ⊕ ipad) ∥ m))
ここで
である。
まずはこのあたりから攻めようと思った。SHA-1の計算にはいくつか特徴的な定数が使われるので、そこからSHA-1の計算に使われているであろう関数444190を特定する。この関数のエントリーポイントに中断点(ブレークポイント)を設定してOAuth認証をさせるべくもふったーの「ブラウザで認証」ボタンを押す。狙い通り中断するので関数を抜けるまで実行する。関数401100の4012DAに出た。少し下を見るとこのようになっている。
CPU Disasm Address Hex dump Command Comments 00401311 |. 33F6 xor esi, esi 00401313 | 8D8C24 A40000 /lea ecx, [local.54] 0040131A |. 394C24 14 |cmp dword ptr ss:[local.90], ecx 0040131E |. 75 0E |jne short 0040132E 00401320 |. 3BF5 |cmp esi, ebp 00401322 |. 73 29 |jae short 0040134D 00401324 |. 0FB68434 A400 |movzx eax, byte ptr ss:[esi+esp+0A4] 0040132C |. EB 21 |jmp short 0040134F 0040132E | 3BF5 |cmp esi, ebp 00401330 |. 73 1B |jae short 0040134D 00401332 |. 8B5424 18 |mov edx, dword ptr ss:[local.89] 00401336 |. 52 |push edx ; /Arg1 = [LOCAL.89] 00401337 |. 8D8C24 FC0000 |lea ecx, [local.33] ; | 0040133E |. 8BD6 |mov edx, esi ; | 00401340 |. E8 CB4D0000 |call 00406110 ; \mofooter.00406110 00401345 |. 83C4 04 |add esp, 4 00401348 |. 0FB6C0 |movzx eax, al 0040134B |. EB 02 |jmp short 0040134F 0040134D | 33C0 |xor eax, eax 0040134F | 34 5C |xor al, 5C 00401351 |. 888434 B80000 |mov byte ptr ss:[esi+esp+0B8], al 00401358 |. 83C6 01 |add esi, 1 0040135B |. 83FE 40 |cmp esi, 40 0040135E |.^ 72 B3 \jb short 00401313 00401360 |. 895C24 3C mov dword ptr ss:[local.80], ebx
0040134F | 34 5C |xor al, 5C
が注意を引く。もしかしてこれはopadとのxorではないか?
00401351 |. 888434 B80000 |mov byte ptr ss:[esi+esp+0B8], al
はxorした結果を格納している。
先ほどの中断点は無効化しこのループを抜けた地点である401360まで飛ばす。この時点でesp+0B8を見ると次のようになっている。
Hex dump 64 2E 16 64|37 04 32 6D|0F 0D 26 29|3A 37 1F 2F| 18 69 6E 6E|0D 25 29 33|11 34 29 69|12 36 24 1E| 05 16 33 6A|04 3B 0E 68|7A 5C 5C 5C|5C 5C 5C 5C| 5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|
あとはこれと5Cとをxorすればconsumer secretが手に入る。終わり。
はてなは増田のスーパーpre記法で半角の＜＞が含まれていると投稿が出来ないのを早く直してください。
もふったーの作者から反応があった。「本気だったつもりのもふったーのデバッグ処理が残ってた」らしい(http://blog.livedoor.jp/blackwingcat/archives/1763951.html)。修正したとのことなので最新版(v0.9.6e)を見てみた。確かに若干変更されているが何の問題もない。SHA-1の呼び出しに中断点を設置して渡されているバイト列を見るだけ。
CPU Disasm Address Hex dump Command Comments 00401324 |. 8D4424 20 |lea eax, [local.102] 00401328 |. 50 |push eax ; /Arg1 = 00401329 |. E8 623A0400 |call 00444D90 ; \mofooter.00444D90
ここでeaxが指すメモリーを見ると以下のようになっている。
01 23 45 67|89 AB CD EF|FE DC BA 98|76 54 32 10| F0 E1 D2 C3|00 02 00 00|00 00 00 00|40 00 00 00| 40 4F 73 53|62 54 5C 7E|59 57 53 42|55 45 7A 57| 61 47 7A 5B|42 4F 7B 61|5D 66 5E 7A|42 7F 40 63| 79 66 05 55|79 4C 60 42|02 10 36 36|36 36 36 36| 36 36 36 36|36 36 36 36|36 36 36 36|36 36 36 36|
見出しはこれ http://anond.hatelabo.jp/20121219191602
http://toro.2ch.net/test/read.cgi/unix/1288765389/232
232 ：名無しさん＠お腹いっぱい。：2012/03/25(日) 15:05:26.72 今月はじめ、職場に新しいPC(Pentium4の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要がありOSにオープン系を採用するのは 聞いていたのですが、搬入されたPCのダンホール箱に乗っかっていたのは UNIXのインストールパッケージでした。 「うへぇ～、よりによってUNIXかよ」 デバイスドライバがない、コマンドが変・オプションがない、X環境が古い、 今の奴は日本語入力大丈夫なのか(Wnn/Canna/kinput2)、将来の64bit移行はどうなのか、 今時のネットで必須のflashのプラグインは存在するのか不安はつきませんし、 非メジャーなのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一CADなどのエンジニアリング環境が充実していたUNIXは大学など 教育機関に浸透していて、日本のUNIX界に多くのバカを輩出しました。 これから私は、おそらくそういうバカが、makeしてもemacsが入らない、 TeXが入らない、コンソールでEUCは使えないのか、Rubyが使えないのかなどと、 サバ管気取りの偏ったどうでもいい我侭を言い出し、(だから鯖にするんじゃねーよ、 鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 そして時代によって決着している、過去10年のUNIX界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではPlamoでもDebianでもRedHatでもKondaraでも Slackwareでもなんでもいいですがメジャーかつ現行のLinuxにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1355909018/4
4 ：名無しさん＠お腹いっぱい。：2012/12/19(水) 18:44:07.79 今月はじめ、職場に新しいPC(Core i7の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要があり、複数マシンでファイルを共有するのは 聞いていたのですが、起動したマシンの/etc/fstabの項目に書かれていたのは nfsという文字でした。 「うへぇ～、よりによってNFSかよ」 ファイルロックすると刺さる、ファイルを消したのに.nfsXXXが残る、 今の奴はACL大丈夫なのか、ファイルのCapabilityに対応してるのか、 今時のLAN上で使ってもセキュリティは大丈夫なのか不安はつきませんし、 ユーザーが減ってるのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れてすりこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一ローカルディスクかネットワーク上かの区別なく透過的にファイルに アクセスできたNFSは大学など教育機関に浸透していて、日本のストレージ界に 多くのバカが輩出しました。 これから私は、おそらくそういうバカが、ファイルに書き込んだら所有者がnobodyに なっちゃったよとか、タイムスタンプがずれるよとか、NFSv4にしたらマウント できなくなったよとか、TCPよりUDPの方がオーバーヘッドが無い分速いはずだよね などと、鯖管気取りの偏ったどうでもいい我侭を言いだし、 (だからNFS鯖にするんじゃねーよ)それと戦わなければならないのでしょう。 そして時代によって決着している、過去25年のNFS界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではSambaでもNetatalkでもFTPでもなんでもいいですが 安定してユーザーが多いファイル共有システムにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1351627596/3
3 ：名無しさん＠お腹いっぱい。：2012/10/31(水) 10:57:28.82 今月はじめ、職場に新しいPC(Core i7の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要がありOSに*BSDを採用するのは聞いていたのですが、 搬入されたPCのダンホール箱に乗っかっていたのはFreeBSDのインストールパッケージ でした。 「うへぇ～、よりによってFreeBSDかよ」 カーネルが変、日本語環境がない、ソフトが変・揃ってない、今の奴は 日本語文字コード大丈夫なのか(utf-8)、x86_64環境は大丈夫なのか、 今時のネットに繋いでもセキュリティは大丈夫なのか不安はつきませんし、 非メジャーなのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れてすりこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一PC98環境が充実していたFreeBSDは大学など教育機関に浸透していて、 日本のFreeBSD界に多くのバカが輩出しました。 これから私は、おそらくそういうバカが、ポーツ(笑)でemacsが入らない、 TeXが入らない、コンソールでEUCは使えないのか、Rubyが使えないのかとかなどと、 鯖管気取りの偏ったどうでもいい我侭をいいだし、(だから鯖にするんじゃねーよ、 鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 そして時代によって決着している、過去20年のFreeBSD界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではUbuntuでもdebianでもFedoraでもRHELでも OpenSUSEでもなんでもいいですがメジャーかつ現行のLinuxにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1209056071/887
887 ：名無しさん＠お腹いっぱい。：2012/10/21(日) 11:56:55.61 今月はじめ、職場に新しい組み込みマシン(ファン付きだけど結構省スペース構成)が 入りました。多分私が開発全般をまかされそうな雰囲気です。業務的にとある 構造分析やシミュレーションなど行う必要があり、プログラムにアセンブラを 使用するのは聞いていたのですが、添付のサンプルソースコードからチラッと 見えたのはsethi %hi(hoge),%o0という命令でした。 「うへぇ～、よりによってSPARCかよ」 長くなるバイナリーコード、奇数アドレスワードアクセス不可、使いにくい レジスタウィンドウ、今時の素早いコンテキストスイッチに対応できるのか不安は つきませんし、今の若者はこんなCPU使わないので人材も少なくソフト開発も大変です。 おそらく導入に際して、大学など教育機関で最初にSPARCに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、32bitCPUでRISCでM68K系よりも高速で動作したSPARCは 大学など教育機関に浸透していて、日本のCPU界に多くのバカが輩出しました。 これから私は、おそらくそういうバカが、16bitイミーディエイト値すら1命令でロード できかないのかよとか、関数呼出しのたびになんで約100バイトもスタックフレームが 要るんだよとか、フラグレジスタの読み出しがなんで特権命令なんだよとか、 %g0ってレジスタ値変わらないし壊れてるよ、初期不良で交換だよとか、 アセンブラ通気取りの偏ったどうでもいい我侭を言い出し(だからSPARC使うんじゃ ねーよ) それと戦わなければならないのでしょう。そして時代によって決着している、 過去25年のCPU界隈のくだらないそれらの議論が再現され、それに巻き込まれるの でしょう。もう今からうんざりです。 だからお願いです。教育現場ではi386でもi568でもi686でも x86_64でもなんでもいいですが現行のCPUにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
前のはこれ http://anond.hatelabo.jp/20121219191602
http://toro.2ch.net/test/read.cgi/unix/1036951410/601
601 ：名無しさん＠お腹いっぱい。：2012/07/10(火) 15:04:00.62 今月はじめ、職場に古いパソコン(i486DX2の結構ローエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要がありハードにパソコン系を採用するのは聞いていたの ですが、搬入されたパソコンのダンホール箱に印刷されていたのはPC-9801という 文字でした。 「うへぇ～、よりによって98かよ」 NetBSD/OpenBSDインストール不可、Solarisも不可、SATA-HDDからブートできるのか、 今時のLCDディスプレイにつながるのか、FreeBSD9.xは対応してるのか、 今時のネットに繋いでもセキュリティは大丈夫なのか不安はつきませんし、 非メジャーなのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一コンソールでの漢字ROMによる日本語表示ができたPC-98は大学など 教育機関に浸透していて、日本のパソコン界に多くのバカを輩出しました。 これから私は、おそらくそういうバカが、makeしてもemacsが入らない、 TeXが入らない、firefoxは使えないのか、Rubyが使えないのかなどと、 サバ管気取りの偏ったどうでもいい我侭を言い出し、(だから鯖にするんじゃねーよ、 鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 そして時代によって決着している、過去20年のパソコン界隈のくだらないそれらの 議論が再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではPC/ATでもSPARCでもPA-RISCでも PowerPCでもなんでもいいですがメジャーかつ現行のマシンにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/992942337/737
737 ：名無しさん＠お腹いっぱい。：2012/09/16(日) 16:27:31.40 今月はじめ、職場に新しい組み込みマシン(ファンレスの結構省電力構成)が入りました。 多分私が開発全般をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要があり、プログラムにアセンブラを使用するのは 聞いていたのですが、添付のサンプルソースコードからチラッと見えたのは LD A,(HL)という命令でした。 「うへぇ～、よりによってZ80かよ」 アドレッシングモード皆無、リロケート不可、使いにくいインデックスレジスタ、 今時の関数引数のスタック渡しに対応できるのか不安はつきませんし、 今の若者はこんなCPU使わないので人材も少なくソフト開発も大変です。 おそらく導入に際して、大学など教育機関で最初にZ80に触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、8bitCPUでi8080上位互換でi8085よりも多くのツギハギ命令を追加拡張した Z80は大学など教育機関に浸透していて、日本のCPU界に多くのバカが輩出しました。 これから私は、おそらくそういうバカが、ADD A,(HL)はできるのにADD B,(HL)は できないのかとか、相対アドレスのCALL命令はないのとか、 スタックフレームポインタとして使いたいのにLD HL,SPっていう命令ないじゃんとか、 アセンブラ通気取りの偏ったどうでもいい我侭を言い出し(だからZ80使うんじゃねーよ) それと戦わなければならないのでしょう。そして時代によって決着している、 過去30余年のCPU界隈のくだらないそれらの議論が再現され、それに巻き込まれるの でしょう。もう今からうんざりです。 だからお願いです。教育現場ではi386でもi568でもi686でも x86_64でもなんでもいいですが現行のCPUにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1011306728/134
134 ：名無しさん＠お腹いっぱい。：2012/07/15(日) 14:17:53.53 今月はじめ、職場に新しいPC(Core i7の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要があり、X Window System上のアプリケーションを 使用するのは聞いていたのですが、OSを起動して黒いバックに白い文字だけの 英語の画面に表示されていたのはlogin:というプロンプトでした。 「うへぇ～、よりによってxinit方式かよ」 CUIログインなんて古い、コマンド入力なんて古い、今の奴は日本語入力設定大丈夫 なのか(XMODIFIERS)、今時のマルチシート環境に対応できるのか不安はつきませんし、 xinitユーザーが少ないのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にxinitに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、X11で唯一$HOME/.xinitrcを手書きするというCUI的方法で環境設定できた xinit方式は大学など教育機関に浸透していて、日本のX11界に多くのバカが輩出しました。 これから私は、おそらくそういうバカが、GNOME/KDEはどうやって起動するのか、 ウィンドウマネージャを終了したらXごと落ちたとか、ck-xinit-sessionはないのか などと、X11通気取りの偏ったどうでもいい我侭を言い出し(だからxinit方式にするん じゃねーよ)それと戦わなければならないのでしょう。そして時代によって 決着している、過去25年のX11界隈のくだらないそれらの議論が再現され、 それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではgdmでもkdmでもwdmでも xdmでもなんでもいいですがグラフィカルなディスプレイマネージャにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1094041299/383
383 ：名無しさん＠お腹いっぱい。：2012/07/12(木) 19:20:13.06 今月はじめ、職場に新しいPC(Core i7の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要があり、制御コマンドとしてシェルスクリプトを 使用するのは聞いていたのですが、そのファイルを開いて1行目に書かれていたのは #!/bin/tcshという文字列でした。 「うへぇ～、よりによってtcshかよ」 ファイル記述子のリダイレクト不可、クオートのネスティング等に無理あり、 今の奴でさえシェル関数は使えないし、パイプラインの終了ステータスもおかしいし、 今時の担当者が扱ってセキュリティは大丈夫なのか不安はつきませんし、 スクリプトとしてのcshは嫌われるのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にcshに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、シェルで唯一aliasやhistoryやジョブコントロールの機能が使えた cshは大学など教育機関に浸透していて、日本のシェル界に多くのバカを輩出しました。 これから私は、おそらくそういうバカが、$*でスペース入りファイル名が扱えないとか $<でファイルから読めないのかとか、if文の条件式のコマンドでリダイレクト できないのかなどと、シェル通気取りの偏ったどうでもいい我侭を言い出し (だからcshスクリプト書くんじゃねーよ)それと戦わなければならないのでしょう。 そして時代によって決着している、過去25年のシェル界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではbashでもzshでもkshでもashでも Bourne shでもなんでもいいですがBシェル系のシェルにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
続く。
いちおう横になるけど、Sandby Bridge以後は 数値演算系は２５６Bitのレジスターが追加になっていて
アセンブラ書けばベクター系は早くなったりするとか 細かい機能はついてたはず。
GHzだけが、速さじゃないからね。クロック下がっても専用命令が付けば早くなるし。
カンファレンスでインテルの人が突っ込まれてたけど、クロック上がっても、命令にかかるクロック数が多くなれば遅くなるし。
結局ベンチマーク次第。だとおもう。
念のために言っておけば、OSとアプリが別コアになれば、早くなることはあると思う。４コアまでいるか？といわれると、微妙だが。
残念ながら、その読書履歴だと、ここで言う「原理」には辿り着いてないと思います。挙げられた本はどれも計算に関する抽象概念からさらに上の、アーキテクチャを言語化する部分に関してです。それらも原理と言えば原理なのですが、そこからスタートしてもC言語でのプログラムは書けるようになりません (Rとかなら書けるかもですが)。
ここで言う『原理』すなわち、なぜ char x[sizeof(int)]; がダメなのか、という理解につながる原理は、「レジスタ」「ALU(CPUの中の計算ユニット)」「バス」「メモリ」といった原理です。メモリアクセスやヒープ・スタックの使い方、アセンブラといったような話です。
なんで言語の約束事の上っ面を覚えるのが難しいか、というと、「原理」を理解していないからなんです。原理を理解せずに約束事だけ覚えたって使えません。曖昧で良いので、プログラムを動かしているときにどのようにメモリが構成されどのようにアクセスされるのかを知る努力をして下さい。その上でC言語をよく見ると、いかにCPUアーキテクチャに近い所で記述されているのかがわかるようになると思います(*)。
それだけで、目の前の箱がどう動いているかの理解度が劇的に上がる筈です。
*: 理解したつもりになるだけですが、現実のコンパイラもCPUも、そのさらに7歩ぐらい先に行っています。ですが、この領域は進めば進むほど泥沼なので、「あ、Cって高級アセンブラなんだな」という所で実用上は十分だと思います。てか、偉そうなこと言っている私(某大学博士課程在籍、要は増田で現実逃避中のダメ学生)も、そこから先はちゃんと理解していません…。
可読性が悪いにもほどがある・・・と思った１関数
http://blog.livedoor.jp/dankogai/archives/51490675.html
inline U64 powmod(U64 base, U64 power, U64 mod){
return base ＞= UINT_MAX ? powmod_gmp(base, power, mod)
: power ＞= UINT_MAX ? powmod_gmp(base, power, mod)
: mod ＞= UINT_MAX ? powmod_gmp(base, power, mod)
: powmod_64(base, power, mod);
}
３項演算子を連打とか・・・
if(base ＞= UINT_MAX){ return powmod_gmp(base, power, mod); }else if(base ＞= UINT_MAX){ return powmod_gmp(base, power, mod); }else if(mod ＞= UINT_MAX ){ return powmod_gmp(base, power, mod) }else{ return powmod_64(base, power, mod); }
って事で、要するに
if(base ＜ UINT_MAX ＆＆ power ＜ UINT_MAX ＆＆ mod ＜ UINT_MAX){ return powmod_64(base, power, mod); } else { return powmod_gmp(base, power, mod) }
って事じゃないのか？実際Cは左辺優先評価で１つ目がFALSEの場合２つめ以後は評価されない（してはいけない）でelseにジャンプ だからif演算の回数だけなら等価
まぁ、確かに、パイプラインを考えればthen節とelse節は等価ではないので、データによって真ん中の書き方のほうが下より早いとか遅いという差はでるけど・・・
なくても、真ん中か、下の書き方でいいよなぁ。
まかり間違って
if(base ＞= UINT_MAX || base ＞= UINT_MAX || mod ＞= UINT_MAX){ return powmod_gmp(base, power, mod) }else{ return powmod_64(base, power, mod); }
と書いても、おそらく、コンパイラ先生がただしく最適化してくれればおなじになるだろう。正しく最適化しないと、コレは遅い可能性もあるが、そんなことはまず無いだろう。
いや？演算子が悪いとは言わないけど、チーム組んで初級の若いプログラマがこういうコードを読めるとは思わないし、読む必要があるとも思わないんだが・・・
ジェネリックに、みんなに分かりやすく。
トリッキーに書くのもいいけど、それは、速度かメモリかで恩恵が受けられる場合で、メリットがないなら、初心者でも読みやすく、メンテしやすくする。って間違ってるのかなぁ？
？連打の方が世の中読みやすいのか？
どうでもいいけど・・・UINT_MAX って、最大値＋１じゃなくて、最大値だよなぁ・・・。確か＞=の＝の有り無し逆じゃね？
もっと、どうでもいいけど、mmレジスタとxmmレジスタのmod演算ってクロック数違うんだっけ？だれか、教えて。ifでパイプライン崩すのとどっちがいいんだろう。
ほんと、そのへんが、プログラマの領域だと思う。
俺はそうは思わない
コンパイラの賢さを考えると、人間が注力すべきは、プログラム全体のアルゴリズムであって、姑息な最適化じゃない
コンパイラが出力するコードは、人間が書くコードよりも、圧倒的に賢い
まず、基本ブロックの入れ替えが起るような、大域的な最適化は、手じゃ絶対に無理
例えば Lazy Code Motion (PLDI '92) を手でできる人はいないだろうし
partial redundancy elimination が扱っている冗長性を理解している人すら、あまりいないだろう
それに、局所的な最適化でもコンパイラ（を書いた人）のほうが賢い（ハードウェアに詳しい）
ターゲットマシンが x86 で、レジスタを0で初期化するときに、gcc で最適化オプション付けると
xorl %eax, %eax
ってなるけど
subl %eax, %eax
でも
movl $0, %eax
でも無く、xor が一番速い理由を知ってるやつとか、なかなかいないだろう
＞JAVAを最初に学んでその後に現場で実際に用いるであろう言語（例えばPHP+SQL）を習得するといったルートは現実的なのだろうか？
いろいろ言う人はいるけど、PHPでも、問題ないよ。
ただ、欲をいえば、PHPのモジュールをC++で書く拡張機能あたりをちゃんと勉強しておいたり、ちゃんとコードをチューニングして行けば勉強になると思う
SQLはただ使うんじゃなくて、データーの正規化やインデックスなんかをきちんとマスターしておくと、違う感じ。あとは、ストアードプロシージャ
＞上記のケースで前段階として学ぶ言語はどの程度のレベルまで到達する必要が有るのか
というか、本気で学ぼうとすると、トランジスタから始まって、フリップフロップ、レジスタ、アキュムレーター、バスの配線、クロックというハードの構成がどうなっていて、
それに対応するマシン語があって、それがニーモニックに変換されて、
そこにスタックという概念が持ち込まれて、レジスタをスタックに退避するという概念が生まれて、関数コールができて、C言語が生まれて、さらにそこにthisポインタをコンパイラが自動補完して関数テーブルを保管することでオブジェクト指向というか、C++ができている。そこに（Cの世界に）BNFなどの構文があって、それを構文ツリーにするBisonなんかがあって、PerlやPHPができている。
という、なぜC++のオブジェクトはポリモルフィズムができるのか？というソフトからハードまでを一貫して知る必要がある。
そこまで理解していると、コードのレベルは確かにハンパないレベルにはなるけど・・・。正直、業務には必要ないというか、そんなクオリティーの仕事が少ない。
やりたければ、やってもいいけど、PHPからやったら？そして必要になったらPHPをCで拡張するという形でCに入ると良いと思うよ。
やりたい言語をやるのが一番だ。
でも、本気で知りたいなら、死ぬ気でアセンブラをやれ。それがすべての始まり。
わりといえば、普通に大学入って、授業を真面目に受けた方が早い。
＞そもそも実際に現場で使用することを想定した言語で、今から学ぶのに本当に適しているのは何か？
PHPでいいでしょ。大差ない、むしろ、自分が気に入った言語で、どれだけコードを沢山書くか。日々の鍛錬。
ちなみにWeb系といわれたから、ライトウェイトな言語を中心に考えたけど、つぶしが効くのは意外とJavaやC++であることも。書いておく。
http://d.hatena.ne.jp/faith_and_brave/20100220/1266673222
まず第一にエンタープライズでの開発が考慮されていない。エンタープライズの開発だと１００人２００人 マスタークラスから ジュニアーまで様々なレベルの開発者が携わる。
その中で重要になってくるのは可読性。
はっきり言って、歴史的な可読性を犠牲にして効率が上がるならともかく、気持ちの問題程度の効率では意味がない。
第２に
スレッドとファイバーの違いぐらいわかれ、わざわざスレッド起こしたらコンテキストスイッチにどれだけコスト食うんだよ。
関数コールするとレジスタとかが、スタックにPUSHされるんだよってわからん奴が、IF書くなと同じで、スレッドってコンテキストスイッチの塊なんだよってのがわかんないのに下手にスレッド書かせるな。
３にラムダ式・・・いらん・・・必要なのは曲芸じゃない、可読性。可読性を犠牲にして早くなるならともかく・・・
４にforeachではlastを変数に取るな。途中でReallocしたり、eraseしたりしたときに余計なバグを生んで面倒だ。レビューの時も邪魔。速度？速度が必要な背景でSTLのVector使うな。配列使うかポインタ使え。
なんつーか、トータルで見て、次はC++と各種OpenCLとかGLとかのライブラリの集合だな。C++0xはまともに使う人もいなさそう。正規表現とかもライブラリ使えば良いし、そもそもC系列ならBisonとかLRとかだろうと。C系列の使い手ならBNFを使え。正規表現使いたければそれこそ、Perl使え。
