まあ、当たり前のことなんですけどね。 前回の記事のプログラムを書き直した 前回の記事の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

RISC-V勉強会@Online 2023/03/16 (木)に登壇して2つの話をしました。 そのうちのひとつがこちら。 「RISC-V原典」の出版当時と現在のRISC-V：進化と変化のポイント 発表スライド 動画 次の発表者の@a4lg　さんがもっと突っ込んだ話をしてくれました。そのスライドのリンクを貼っておきます。 RISC-Vの仕様とそのステータス一覧 最近策定された(Rafified)拡張一覧 参考 RISC-VのExtensionの最近の状況を知るのはこの記事がよさそうです。 RISC-V Instruction Set Architecture Extensions: A Survey 関連

RISC-V勉強会@Online 2023/03/16 (木)に登壇して2つの話をしました。 そのうちのひとつがこちら。 RISC-Vアセンブリ言語をより簡単に理解するための逆アセンブル表示ツール 発表スライド 動画 Githubリポジトリ 宣言した通り、英語版のスライドも作りました。 関連

前回の記事を書いたら、ありがたいことに色々な情報を教えてもらうことができました。「まず情報を出すと情報を得られる」"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の実行形式と同じヘッダ

2023/01/15にオンライン開催されたKernel/VM探検隊online part6で10分の枠で話をしました。 発表資料 発表スライド YouTubeのアーカイブ (発表時のスライドでs3であるべきところをi3と誤記していました。現在のスライドは修正済み) 勘違い。i3は正しい。むしろi32と書くべきところをs32と書いてあったので修正した。 関数の未使用引数について fn func(x: i32, y: i32, z: i32) i32 { _ = z;　　　　　　// これがないとコンパイルエラー return x + y; } twitterで指摘をいただき調べました。 変数shadowingの禁止について Rustはむしろ同じスコープでも新たな変数に同じ変数名を使うことを許可しています。つまり、変数shadowing禁止とは真逆です。 「RustはSSAをベースに」はちょっ

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

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)が意識されているらしいです。 紹介してもらったこの動画が