はてなブックマーク

まあ、当たり前のことなんですけどね。 前回の記事のプログラムを書き直した 前回の記事のMJPEGからJPEGを切り出すプログラムにはバグがありました。脚注にも書きましたが、それは読み込んだバッファの最後のバイトが0xffで、次のバッファの先頭が0xd9のときに、JPEGの終わりを見逃してしまうというものです。 なので、ちゃんと4つの状態を遷移するように書き直しました。 const std = @import("std"); const fs = std.fs; const io = std.io; const os = std.os; const BUF_SIZE = 64 * 1024; const OUTPUT_FILENAME_PATTERN = "out{d:0>4}.jpg"; const JPEG_START0 = 0xff; const JPEG_START1 = 0xd8;

メモとして残します。 MJPEGを入力してJPEGに切り出すプログラム ChatGPT-4 に作らせました。 USBカメラから入力された生のmjpegの映像データを標準入力から受けて、jpegの静止画に切り出してファイルに保存するプログラムをC言語で書いてください。書き出すファイル名はout%03d.jpg という感じでフレーム番号を含めてください。ソースコード内のコメントは英語で書いてください。 最初のものはffmpegやらたくさん外部のライブラリに依存するコードを出してきたので、もっとシンプルなやつにしてくれとお願いしました。できたものはこれ。[1] #include <stdio.h> #include <fcntl.h> #include <unistd.h> #define BUF_SIZE 1024 #define OUTPUT_FILENAME_PATTERN "out%03

「入門モダンLinux」 こちらのオンラインイベントで、著者の方の話を聞き、これは買おうと思いました。 オライリーのサイトから電子書籍を購入しました。 読みながらメモをツイート PDF版をダウンロードして読んでいます。 それから電子版だと、本文のURLのところはそれをクリックするだけでブラウザが開いで見ることができるので便利です。 感想 UNIXの基本的な作法については1980年代に「UNIXプログラミング環境」という水色の表紙でちょっと厚い本を何度も読み返して身につけました。それ以降の新しいことはその都度キャッチアップしていたのですが、この本はそういう基本的なところも網羅して、現代の(モダンな)Linuxを知るのにちょうどよかったです。 操作はコマンドラインで行うことに一貫しています。私のようにラズパイやクラウドのサーバにsshでログインして使用している人にはぴったりです。便利なコマンド

「CPUで浮動小数点演算はFPUで行います。」と書かれていたとして、これをFPUって何？と思う若者がいるかもしれません。FPU(　Floating-Point Unit)は昔はCPUとは別のチップになっていて、FPUコプロセッサと呼ばれていました。 組み込み用のマイクロコントローラを除いては、現代ではFPUはCPUに内蔵されているが普通です。FPUコプロセッサのチップはもうすっかり見なくなりました。 以下、記憶の範囲内で書いています。不正確なところがあったらごめんなさい。 パソコン向けCPUでの話 パソコン用のCPUではFPUが内蔵されたのはintelのCPUで言うと80486からです。それまでのパソコンのマザーボードにはFPUを挿すためソケットが用意されていて、必要な人は別途FPUコプロサッサを買って取り付けるということをしていました。 その頃に、FPUコプロサッサをつけると〇〇のアプリ

いちいち説明されないので知らない人もいるかもいるかもしれません。 Linuxの話をしていると識者が strace(1) とかopen(2)とか後ろに(数字)をつけることがあります。この数字はマニュアルの章の番号です。1がコマンド、2がシステムコール、3がライブラリです。コマンドとライブラリで名前が被っているものがあるために区別します。 例えば、printf(1)はコマンドでprintf(3)はライブラリです。それぞれのman を見るためには章番号を明示して、 man 1 printf や man 3 printf とします。 man man としてmanコマンドのマニュアルを見ると、全ての章の説明があります。 The table below shows the section numbers of the manual followed by the types of pages they

Linuxでスレッドのコンテキスト切り替えのたびにFPUのレジスタはメモリに保存されるのか？ シングルコアプロセッサしかなかった時代とマルチコアの時代で挙動が変わっています。 chatGPTに聞いてみた 間違えたことを言ったと気がついたら、すぐに謝ってくれるのはいい奴ですね、 スクリーンショットでは見にくいので、実際の内容を以下に貼り付けました。 In Linux kernel context switch does it save all FPU regsters each time? In Linux, the kernel does not save all floating-point unit (FPU) registers every time a context switch occurs. This is because saving and restoring the F

本書の構成 第1章。「ふむふむ、このレベルから説明してくれるのか」 第２章の途中からギアアップしてきて、「スーパースカラ+スーパーパイプライン化」で現代のCPUの規模感のようなものを思い知ることになります。順調にCPUの中を流れる命令列はまるでナイアガラの滝のよう。 でもちょっとしたことでその流れは止まってしまい、そのペナルティの大きさを実感することになります。 第3章から第8章で、CPUの処理の流れを止めるさまざまな要因が語られていきます。 第9章は「マルチプロセッサ」。一段と複雑になる要因ですが、現代のCPUでは外せないもの。 第10章から第12章で、共有メモリ型マルチプロセッサでのマルチスレッドをするときの注意点が語られていきます。 第13章がまとめ。それ以降は付録です。 私としては第9章の「マルチプロセッサ」以降が非常に勉強になりました。ぼんやりとしかわかってなかったことがこれでク

前回の記事を書いたら、ありがたいことに色々な情報を教えてもらうことができました。「まず情報を出すと情報を得られる」"give & take" の典型ですね。 UEFIの雑なまとめ IntelとHPが共同で開発していた次世代64bit　CPUのItanium向けのブートローダーとしてMicrosoftを巻き込んで開発されたのがEFI。 EFIはアーキテクチャには依存しないように設計されていた。 EFI v1.x はIntelに所有権があったが、Unified EFI Forumにそれを移管し、v2.x にするとともにUEFIと改名した。 UEFIはx86_64, aarch64などで採用され、MIPS, RISC-Vもそれに続くと思われている。 だいたいWikipediaに書いてある。 @oruminさん 「UEFI の reference のアプリケーション開発 SDK である EDK2

RISC-Vのカーネルイメージのエントリーポイント kernelvmのrisc-vのチャネルで「riscv環境におけるlinuxのカーネルがロードされた直後からどう動くのかを知りたい。どこのコードから読めばよいか」という質問があり、あれこれ調べるうちにここだということが判明しました。 #ifdef CONFIG_EFI /* * This instruction decodes to "MZ" ASCII required by UEFI. */ c.li s4,-13 j _start_kernel どうもEFIで起動するイメージの先頭はASCIIコードで"MZ"となっている必要があるようです。 "EFI MZ" でいろいろ検索 どうやら、EFIで起動するイメージは(EFI Application)はPE(Portable Executable)というWindowsの実行形式と同じヘッダ

Zig言語の話をするときに、初めての人にざっと読んでもらうためのページ。 Zig言語とは 静的型付きのコンパイル言語。C言語と同じ立ち位置。 本家 ziglang.org のoverview 日本語 Wikipedia Wikipedia 英語版 ドキュメント 標準ライブラリのリファレンス 現在の状況 まだ開発中で正式リリースには至っていない。なのでまだ破壊的変更はあり得る。 記事を書いた時点の安定版タグは0.10.0。 公式なパッケージマネージャはまだない。[1](非公式なものは複数存在する) ** 2023/08/15 追記 ** 安定版0.11.0のリリースとともに公式版パッケージマネージャが利用可能になりました。 私が考えたキャッチコピー 「C言語が誕生したのは1972年。Zig言語はそれを2020年代の知見で再構成するもの。50年分の進化!!」 "C but with the p

Twitterで "green thread" という単語をたまたま見かけたので、知っていることをつぶやいたよ。 Green thread 言語のスレッドとOSのスレッドの関係 N:1 mapping 言語のスレッドの全てがひとつのOSのスレッドの上で実行されるもの。その代表が上記のJavaのgreen thread。 OSのシステムコールを呼ぶときには必ずnonblockingモードを使い、EAGAIN または EWOULDBLOCKが返ってきたときには他のスレッドの実行権に譲るようにする必要がある。うっかりシステムコールでブロックされてしまうと、全部のスレッドが巻き添えになって動けなくなる。 スレッドの生成やコンテキストの切り替えは軽い。しかし、マルチコアを生かすことができないため、シングルコアの環境でのみ使用される。 1:1 mapping OSのスレッドと言語のスレッドが1対1対応

(雑に書いている戯言であることを最初に断っておきます。あくまで個人の感想です。) 実は私は今までRISC-Vには懐疑的だったのですが、最近の状況を知って考えを改めました。 RISC-Vとは RISC-V（リスク ファイブ）とはオープンソースライセンスで提供されている命令セットアーキテクチャ (ISA)です。 研究にも使うことができるし、実際に多くの半導体メーカーがこの仕様に基づいたCPUを開発、出荷しています。 多くのオープンソースのOSやツールチェインもすでにRISC-Vに対応しています。 私が懐疑的だった理由 RISC-Vはオープンソースであるゆえ、自由に拡張することができます。そのため様々な派製品が登場しています。シンプルな組み込み用のマイクロコントローラからパソコン用、サーバ用、HPC用など広い分野に渡ります。 かつてRISCの考え方にもとづいて開発されたMIPSというCPUがあり

前回の続き。 ちょっとZig言語が面白そうです。まだあまりzigでコードは書いていないのですが、ドキュメントやソースコードをながめて思ったことを書き散らかしてみます。 (他の人がすでに書いていることはなるべく書かない) オブジェクト指向でなくてデータ指向 C言語に後にC言語っぽい文法の言語はたくさん出てきました。C++, Java, C#, Go, Rustなど。 C++やJavaはオブジェクト指向の考え方を取り込んだもので、GoやRustはいきすぎたオブジェクト指向を反省して、interface とか trait とか良いところだけを抽出した感じになっています。(個人の感想です) Zigには純粋にC言語からの改善をしていて、オブジェクト指向の香りがあまりしません。 むしろ「データ指向設計」(Data-Oriented Design)が意識されているらしいです。 紹介してもらったこの動画が