「試して理解 Linuxのしくみ」 Amazonでは "[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識" という名前になっています。 著者の武内さんのハンドルネームから、sat本と呼ばれることも多い書籍です。 武内さんが配布されているCのコードはこちら、私がRustで書き直したコードはこちらにあります。 以下は、ポエムです。 本の感想 私自身は、Linuxやメモリにそれなりには興味を持っていたので、すごく目新しい内容は、それほど多くはありませんでした。けれども、読んで非常によかったと感じています。 「試して理解」と銘打っているとおり、書かれていることを実際に試して、理解を深められるようになっています。なんとなく聞いたことはあったけれど、実際試したことはなかったものを、実際に試すことができたのは本当によかったです。 なぜRustに移植したのか 持論として、「
Linux の共有ライブラリを作るとき PIC でコンパイルするのはなぜか 通常、Linux の共有ライブラリを作るときは各 .c ファイルを PIC (Position Independent Code) となるようコンパイルします。しかし、実は PIC でコンパイルしなくても共有ライブラリは作れます。それでは PIC にする意味はあるのでしょうか。 さっそく実験してみます。 int func () { printf(""); printf(""); printf(""); } PIC でコンパイルするには gcc に -fpic または -fPIC を渡します。-fpic の方が小さく高速なコードを生成する可能性がありますが、プロセッサによっては -fpic で生成できる GOT (Global Offset Table) のサイズに制限があります。一方、-fPIC はどのプロセッサで
この記事は「言語実装 Advent Calendar 2017」の11日目のネタです。 今、私は「IL2C」 というプロジェクトをやっているのですが、その実装中に起きた予期せぬフロー解析を、素人なりに実装した話です。IL2Cについては以下を参照してもらえればわかりますが、.NETのIL (Intermediate Language) を、C言語ソースコードに変換します。 GitHub: IL2C step-by-step design project YouTube: Playlist: Making archive IL2C 「AOT技術 Advent Calendar 2017」でもこれまでの内容を要約して書いてます。この記事はダブルエントリーにしました。 また、「Extensive Xamarin」 でその時点までの技術的なポイントを執筆したので、興味があれば参照して下さい… いや、
RTags is a client/server application that indexes C/C++ code and keeps a persistent file-based database of references, declarations, definitions, symbolnames etc. There’s also limited support for ObjC/ObjC++. It allows you to find symbols by name (including nested class and namespace scope). Most importantly we give you proper follow-symbol and find-references support. We also have neat little thi
この記事について LinuxのIPC(プロセス間通信)を紹介します。 プロセス間通信とは Inter Process Communication(IPC)はプログラムの実行単位であるプロセスの間で行われるデータ交換のことを指します。プロセスの依存関係は可能な限り疎結合になるようOSで管理されています。そのため、IPCはLinux OSの機能を経由して行う必要があります。 OSがプロセスに提供するデータ交換の方法はひとつだけではありません。それぞれ特徴のある多彩な方法を提供しています。 ここで紹介するのは以下の5つです。 共有メモリー セマフォ マップドメモリー パイプ ソケット通信 (他にありましたらコメントで教えていただければ幸いです。) それでは、見ていきましょう。 共有メモリ プロセス間で同じメモリを共有します。 共有メモリの最大の利点はそのアクセススピードにあります。 一度共有メモ
先日 inline-c という、Haskellのソースの中にインラインでCのコードを書けるようにするパッケージがリリースされました。これまでの類似のパッケージよりも使いやすい感じで、愚直にFFIを書いたり、ブリッジライブラリを書いたり使ったりするよりやっぱり楽なもんだなあと感心していたんですが、これってもしかしたらインラインのCのインラインにアセンブリ書けば、Haskellに直接インラインでアセンブリを書くこともできるんじゃないか?と、ふと思ったので、やってみたら普通にできましたという話です。 inline-c inline-c に関しては、GitHubレポジトリに丁寧な README.md があるので、詳しくはこちらを見てくださいというところなんですが、せっかくなので少し試してみましょうか。 {-# LANGUAGE QuasiQuotes #-} import qualified La
Zig is a general-purpose programming language and toolchain for maintaining robust, optimal and reusable software. ⚡ A Simple LanguageFocus on debugging your application rather than debugging your programming language knowledge. No hidden control flow.No hidden memory allocations.No preprocessor, no macros.⚡ ComptimeA fresh approach to metaprogramming based on compile-time code execution and lazy
時は2016年、プログラミング言語Cの言語仕様は2度のメジャーバージョンアップを経て、"ISO/IEC 9899:2011"(通称 C11)にたどり着きました。ところで誰か使ってるの? もちろん、これでC言語の進化が止まったわけではありません。次世代標準 C2x に向けた検討が始まっているのです。C2xリリーススケジュールとして、2021年末までの検討作業、2022年末までの国際標準(IS)発行が予定されています。 C2x憲章 ISO/IEC JTC1/SC22/WG14 N2086 "Programming Language C - C2x Charter"より、プログラミング言語Cの 次世代標準 C2x に向けて、基本原則として考慮される15項目のリストを訳出しました。各項目では冒頭の要約文のみを訳出しているため、詳細について知りたければ原文を参照ください。 オリジナル原則 1. Ex
Unix in your browser tab Run C, C++, Go and Node.js programs as processes in browsers, including LaTeX, GNU Make, Go HTTP servers, and POSIX shell scripts. Programs written to run on conventional operating systems typically depend on OS abstractions like processes, pipes, signals, sockets, and a shared file system. Compiling programs into JavaScript, asm.js, or WebAssembly with tools like Emscript
Verasco is a static analyzer for the CompCert subset of ISO C 1999 that establishes the absence of run-time errors in analyzed programs. The analyzer is based on abstract interpretation and combines several abstract domains, non-relational (integer intervals, floating-point intervals, integer congruences, points-to properties) and relational (integer linear inequalities, symbolic equalities). Vera
逆に言うと、Rubyの文字列型の内部実装がropeになれば、freezeしてもしなくても変わらない速度が出るようになって、結局freezeする必要なんてなかったんやーで丸く収まるんじゃないの?と思いました #雑な感想 — Kazuho Oku (@kazuho) October 6, 2015とツイートしたところ、処理系の中の人から @kazuho 文字列を弄る話じゃなくて、文字列の identity の話なので、ちょっと関係ないかなぁ、と — _ko1 (@_ko1) October 6, 2015みたいなツッコミをもらって、うっすみません…ってなってRuby VMのコードを読むことになったわけです。 で、まあ、いくつか気になる点があったので手をつけてしまいました。 1. オブジェクト生成のホットパスの最適化 ホットスポットだとされていたところのコードを読んでると、オブジェクト生成の際に
Facebook、静的コード解析ツール「Infer」を公開。Objective-C/Java/Cコードのバグを指摘してくれる Inferが対応するコードはAndroidのJavaとiOSのObjective-C、およびC。現時点ではAndroidとJavaではNullPointerExceptionおよびリソースのリーク。iOSとCコードではメモリーリークを発見してくれます。 実際にプログラムを実行することなくバグを発見しようとする静的コード解析は、コードをビルドしてテストプログラムなどを実行するよりも迅速にバグを発見できる方法として期待されています。 Inferも、Facebookがより早く高い品質のソフトウェアをデリバリする目的で開発されたものです。下記はInferを発表したブログ「Open-sourcing Facebook Infer: Identify bugs before y
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く