今になってここへたどり着くとは。
Uncovering the R800 https://www.msx.org/forum/msx-talk/development/uncovering-the-r800

あとはS1990の資料が出てくるのを待つだけか…？

未定義命令使うってのは、無しな方向でお願いします

裏レジスタの存在を考えるとZ80って結構コンパイラ泣かせな気はする。むしろ8080か、IXH/IXL/IYH/IYLレジスタアクセスの保証されたZ280とかR800…

自分が生きてる間にgccなりLLVMなりでZ80を触れる日が来るのかどうか。

でもgccでもLLVMでもZ80に*ちゃんと*対応できてないって現実ありませんかね…？LLVMでもなんかパッチ当てた奴で、C to C translationしたものをSDCCに食わせるって話を最近どこかで聞いたよーな http://www.colecovision.eu/llvm+sdcc/

※酔ってるのであんまりオブラートでは包まない

なのでCOBOL死ね！とか言ってる人（日経でなんか偉そうな顔してる人とか）ってちょっとヤだなーって思うんですよ。あいつら絶対C言語にも矛先向けてくるから。

このアカウントは、notestockで公開設定になっていません。

（言い訳というか懺悔というか：TypeScriptとかJavaScriptって文法とかは本見るとしてむしろフレームワーク選びとかの方が重要だったりしませんか？ReactなのかVueなのかSvelteなのか…ちゃんと理解してる人ならどれ使っても変わらんとか言われそうだけど）

Rust本は手元にあるのにRust触ってない…
TypeScript本も手元にあるのにTypeScript触ってない…
JavaScript本も(ry

うううう

Zigってどうなんでしょう…

@hfp （感謝）次から試します…！（今回はbuild.shが動いちゃってます…）

https://marc.info/?l=openbsd-tech&m=154788241632182&w=2

え゛、（OpenBSD側の対応してから）3年以上もたってる…わああごめんなさいいいい＞＜

あー、NetBSD側でもこの修正は入ってるんですね（OpenBSD側で対処した際にどうやってNetBSD側に伝えたもんかと悩んだまま放置してましたごめんなさい）。 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/ehci.c?rev=1.254.8.8&content-type=text/x-cvsweb-markup

そーいやre(4)のwatchdog timer timeout、A8/A10のBulldozer機からIntel機に変えたら起こらなくなったな。どういうことなんだこれ…？
https://marc.info/?l=openbsd-tech&m=165987603706259&w=2

あんだよー、簡単に見つけられると思ってたら最後の最後に大ボスが出てきて潰された気分。なんかもう今日はお酒飲んで寝る…

（自分が投げるだけ投げてバージョンアップとかせずに放置したままのportsってありませんかね？というのが気になっているので、調べてる）

って、自分が過去に何してきたか調べてまとめてたんだけど大して数無いしこの程度なら楽だなと思ったら意外ににあるじゃないですか…

https://marc.info/?a=128092500500014&r=1&w=2

過去にportsの何をいじったか、というのを思い出す必要があるんだけどそれをこのメッセージの山の中から探すんですかいやだあああああああ＞＜

sys/dev/fdt/sxiccmu.c: (2021/12/03) Allwinner H6対応 https://marc.info/?l=openbsd-cvs&m=163855934921723&w=2
ports/inputmethods/fcitx-kkc: (2022/10/22) skk辞書のパス修正 https://marc.info/?l=openbsd-ports-cvs&m=166646579921884&w=2
sys/dev/fdt/ehci_fdt.c: (2024/02/12) Allwinner H616でのerrata対応 https://marc.info/?l=openbsd-cvs&m=170777376712370&w=2
ports/emulators/dosbox-x: (2024/03/09) 2024.03.01版への更新 https://marc.info/?l=openbsd-ports-cvs&m=170998929612895&w=2

sys/dev/usb/if_ugl.c: (2018/03/15) なんか直してる https://marc.info/?l=openbsd-cvs&m=152114983007448&w=2
ports/portaudio-svn: (2019/01/12) 複数デバイス対応をFreeBSDから持ってきた https://marc.info/?l=openbsd-ports-cvs&m=154732499120690&w=2
ports/gpsbabel: (2019/09/03) 1.6.0.1へ更新 https://marc.info/?l=openbsd-ports-cvs&m=156751851231986&w=2
sys/dev/fdt/sxiccmu.c: (2020/08/30) Allwinner H2/H3+対応 https://marc.info/?l=openbsd-cvs&m=159876505206763&w=2

sys/dev/usb/uhub.c: (2010/09/21) 確か栄村ハッカソンでの話。Core i3機のRMH絡みの修正。 https://marc.info/?l=openbsd-cvs&m=128507214215177&w=2
sys/dev/pci/pucdata.c: (2012/10/12) I-O DATA RSA-PCI2対応 https://marc.info/?l=openbsd-cvs&m=135007901825134&w=2
ports/gpsbabel: (2013/01/15) 1.4.4への更新 https://marc.info/?l=openbsd-ports-cvs&m=135736682327888&w=2
udav(4): (2014/01/28) RD9700対応の追加 https://marc.info/?l=openbsd-cvs&m=139091393211967&w=2

え、同姓同名(?)の自分じゃない人がいる…でもなんか微妙に違う…？誰だろう。
https://marc.info/?l=gentoo-desktop&m=108030780109205&w=2

OpenBSDのsysupgrade -sみたいに、NetBSDも常に最新版のnightlyのバイナリをインストールしてくれる手段は無いかな（そしてソースコードはCVSで取ってくる）。
毎回ビルドする、というのもちょっと疲れてきちゃって。

おお、Windows3.1で自分と同じ配色を好む人だー。

サクラの日：アナザーバージョン＠Win31 (2023/3/27) https://www.pixiv.net/artworks/106616075

@hadsn とっても漢字だらけなやつ？

まあ発言内容から何を検索してるかはモロバレですけどねｗ

時々とあるキーワードで検索して、見つけた発言をエアリプで牽制してみたりするなど（ここじゃないです）。

うーん…
運気のバフがかかっていてもこの程度っていうのは正直なあ…
バフ無しだともっとひどい状況ってことかい。

記事の冒頭にある「メタクソ化（enshittification）」に「えっ？えっ？？」となったけど、en/shitty+fi/cationか。お上品に言うなら不愉快化？（Facebookの話があるので）Metaに引っかけてメタクソ化としたのなら…ニヤッとする。

このアカウントは、notestockで公開設定になっていません。

FUJIMI-IM/sj3のfork、devブランチにutf-8対応をマージしました。マージ前のdevブランチはdev-preutf8として残しています。

むしろ「日本スゴイ」系の餌食にならないよう、VOCALOID/MMD系の方がああいう手合いに対し徹底して警戒すべきなのかも。奴らに絡まれたら本当にsceneが荒れる。
https://twitter.com/uaa/status/1781424224315597060

今度それ使ってみよう、git restore。

流石にもう\1000程度日経平均が下がった程度では、電車止まらないかー…

え、git stashって作業内容の一時退避なのか。てっきり「めんどくせーから今までの修正全部無し！やり直すわ！」ってぶん投げるためのコマンドだとばかり…
https://zenn.dev/ganmo3/articles/5bf0b9d42894c4

件のページで紹介されているカメラ、EKTAR H35だけフィルムカメラなんだけど…やっぱりイマドキのフィルムカメラはハーフサイズが主流なんだろうか（親が持ってた京セラのSAMURAIがかなりアレだったので実はあんまり良い印象を持ってないというのはちょっとあるんだけど）。

PENTAXの開発中のフィルム機もハーフサイズ/縦構図になるって言ってたし。
https://news.ricoh-imaging.co.jp/rim_info/2024/20240301_039652.html

あー、服のタカハシで買ったデニム、型番控えてるのでまた買えると思って通販サイト見たらどこも売り切れじゃん…

いちいち試着するの面倒なので型番控えておんなじの、という買い方をしてるんだけどそれができないのって本当に不便すぎ。靴に関しても廃版になったのでいちいち試着しに靴屋へ行く羽目になったし…

Z世代ってタイパとか重視するっていうし、だったらそういう「廃版にする→わざわざお店行かせる」って行為はタイパが悪いって敬遠されません？（とこじつけてみる）

（boost不可なのでboostしないけど）それはｱｧｧｧｧｧｧｧｧｧｧｧｧってなる…

このアカウントは、notestockで公開設定になっていません。

アレだよなあ、どこかの日本人は絶対GitHub上での活動に何らかの勝敗とか優劣とか設定するんだよ、謎ルール作って。

GitHub上での勝者が居るとしたら、幸せになるようなコードを書いたり、プロダクトを作ったり、それで幸せになる「みんな」だろ。

外野から謎ルールを設定して、コード書いたりプロダクト作ったりそれを使う人間を不幸にしようとする奴は、敗者どころか排除すべき敵だ。

より良いコードを書き、より良いプロダクトを作るためであれば、多少issueの文法がアレだろうと書き方が無礼だろうと、そこは目くじらを立てる場所じゃないと思うんですよね。

謎マナー講師はむしろそこを揚げ足を取るネタとして（＝お金に変えたくて）仕方が無いって顔してそうですけど。

もう少しシンプルにissueを書けないもんだろうか。
英語ならシンプルになるんだろうか…？（英語あんまし書けないし）

https://github.com/IchigoJam/ichigojam-firm/issues/19

「ｼﾂﾚｲにならない、これがissueを書く上でのマナー！」と謎マナー講師がGitHubでのissue書き方講座を始めるのも時間の問題か？

とはいえ、
FIO11-C. fopen() のモード引数の指定は慎重に行う (2014/04/16)
https://www.jpcert.or.jp/sc-rules/c-fio11-c.html
にあるように、「C 言語規格への厳密な合致と可搬性を確保するには、以下の表の文字列(C 言語規格から引用)を使用する必要がある。 」
表中には'r', 'w'の他に'rb', 'wb'もちゃんと書かれていて、テキストだのバイナリだのって話も出てる。

もう21世紀も1/4が経過しようとしてるんだからさー、'wb'じゃなく'w'でバイナリ吐けないようなfopen()を使う環境はポイしちゃいましょうよー

https://man.openbsd.org/fopen.3
The letter “b” in the mode strings above is strictly for compatibility with ANSI X3.159-1989 (“ANSI C89”) and has no effect; the “b” is ignored.
昔はテキストだーバイナリだーとfopen()でモード指定していたもんだけど、今は別に'b'があろうとなかろうと関係ないもんねってご時世な訳で。

まさかこういうコードを書くことになるとは。fopenで"rb"使ったり、ロードしたデータの末端に^Z(0x1a)が大量に付くことを想定するとか…もうそんな時代の環境を意識しなくても良い（というか意識したくない）はずなのに。

https://github.com/IchigoJam/ichigojam-firm/pull/18/files

オープンソース伝道師、って昔居たような…

このアカウントは、notestockで公開設定になっていません。

fopenのモード指示子って、単に"w", "r"じゃダメなケースがあるんですかね…z88dkだと"rb"にしないとバイナリファイルを読んでくれない。

#if BYTE_ORDER == BIG_ENDIAN
// big-endian用の処理
#else
// little-endian用の処理
#endif

んでもって、htobe16()だのswap16()だのの定義はz88dkに無いから自前で記述するしかない。

いまはちょっとその\5k未満すら捻出できねえ…買った人は存分に楽しんでほしい…

このアカウントは、notestockで公開設定になっていません。

Lite XL、Linux/macOS以外では動かないのかなあ（なんかFreeBSD/NetBSD辺りだとports化されてそうな気がする）

このアカウントは、notestockで公開設定になっていません。

動けばおっけではなくて、なるたけ意図しない動き（で脆弱性を作っちゃうこと）は排除しようということなんだろう、OpenBSDの思想は。

一般的には、重なった領域間のmemcpy()の動作は「未定義」とか「結果を保証しない」と言われる話なので、動いたとしたらそれはたまたま動くケースに該当しただけって話。

Apr 16 21:54:14 framboise IchigoJam_BASIC: backwards memcpy

お、おう…（OpenBSDのmemcpy()って重なった領域間のmemcpy()を認めてないのか…たとえ32byte先のデータを手前に動かすっていうだけでも）。

「youtube ブランドアカウント 移行」https://www.google.com/search?q=youtube%E3%80%80%E3%83%96%E3%83%A9%E3%83%B3%E3%83%89%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%80%80%E7%A7%BB%E8%A1%8C 辺りを熟読しておくか…

なんか色々いじったからか意味分からないことになってる。しばらく放って事態が落ち着くしかないのかも（落ち着かないかも）。

履歴も飛んでるけどこれはもうしゃーないものとするしかない。

自分とこのYouTubeチャンネル
https://www.youtube.com/channel/UCYp38rECEGdt1XhyTGHjC8A
コメントとかすると@takayoshisasano3795とかいう名称になるけどこれだとちょっと不便なので、ここを直したいというのがチャンネルいじりの理由。

と思ったら復活してる。移行中だったからなんだろうか。

あー、Youtubeのチャンネル移行に失敗したらしく、高評価の動画一覧が消えた…あれをブックマーク代わりに使っていたんだが…orz

The 3′ cis-Acting Genomic Replication Element of the Severe Acute Respiratory Syndrome Coronavirus Can Function in the Murine Coronavirus Genome (Scott J. Goebel et al, Journal of Virology 2004 Jul) https://www.ncbi.nlm.nih.gov/pmc/articles/PMC434098/
この時点でMHV, BCoV, SARS-CoV他との3'UTRの比較をやってるのか。

SARS-CoV-2, SARS-CoV, MERS-CoV, BCOV, MHV間である程度の類似性が見られるってのも面白いな。同じコロナウイルスの仲間だからその辺も似るっちゃ似る、ってことなんだろうけど…SARS-Cov-2以外のウイルスにおける3'UTRの研究成果をSARS-CoV-2に持って来れる（もしくはその逆）っていう可能性はあるんだろうか。

ああ、Figure 1にそう書いてあるじゃないですかー（ちゃんと読んでないのがバレた）

5'UTRが265塩基、3'UTRが337塩基、でいいのかな？ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7766253/
The RNA Architecture of the SARS-CoV-2 3′-Untranslated Region (Junxing Zhao et al, Viruses 2020 Dec)

ふーん（ぐぐって適当に見てる）、SARS-CoV-2の場合は5'よりも3'UTRの方が注目されてるのかな。5'側/3'側、それぞれのUTRの大きさがどれくらいか知りたいところだけど。

今だとRNAシーケンスを統計的に処理して、stem-loop構造のどの辺のRNAに変異が起こりやすいか（という所までは自分が院生やってた頃の話）に加えて…それが立体構造の変化にどう寄与するかなんてのもシミュレーションできるのかなあ。

おお、今の論文ってCC-BY-NC-NDとかで公開されてるのか。 https://pubs.acs.org/doi/10.1021/jacsau.3c00641

（ちょっとウイルス絡みの研究とかやってた時期も院生時代にあったもんで…こーゆう話、好物なんすよ）

3'UTRってことは末端側か（先頭の5'側にあるウイルスもあるけどSARS-CoV-2はそうじゃないってことか）。ウイルスRNAの非翻訳領域って立体構造を取って色々な働き（分かってないこともある）をするという箇所だからなあ…これは面白そう。

このアカウントは、notestockで公開設定になっていません。

趣味にも成果主義が求められているなーというのは実感としてあるんだけど、タイパ主義が入ってくるのも時間の問題っていうかもう入ってるんだろうなあ。

タイパ思想っていうか成果主義なんだろうなあ。「成果」として他人に認められないものは何をやっても無駄、って。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

NetBSD: sys/endian.h, endian.h
DragonFlyBSD: sys/endian.h, endian.h
OpenBSD: sys/endian.h, endian.h
FreeBSD: sys/endian.h, endian.h
Slackware: endian.h

BSD系だと<sys/endian.h>にしないといけないかなーと思っていたけど、<endian.h>で十分そう。

IchigoJamでマンデルブロ集合 (2024/03/07) https://lab.nshdot.com/old/mandel15/
これはIchigoJam実機向けのベンチマークになるので、IchigoJam-BASICで使うにはちょっとツライ（PCGの対応が無いので）。

MSX-DOS上でのGAME言語のベンチマーク　[MSX] (2019/12/31)
https://piclabo.blog.ss-blog.jp/BenchMark
これを拝借しようか…

とはいえ、Pentium G4600上のCP/Mエミュレータ上で動くIchigoJam-BASICだと完走する（Complete!の表示が出る）のに10分はかかっているから実機とかだとどうなるんだろう。

教訓：コンパイラを疑う前に自分のコードを疑え

…何度やったっけ、これ…

if (((pint)pc & 1) == 0) { // align 2byte
pc++;
}
if (pc >= list && pc + 4 < list + _g.listsize) {
pc += 4;
continue;
}

貴様か

なんか分かった気がする。最適化の問題じゃなくて、確保されるメモリのアドレスが奇数番地になってるのでtokenizerがうまく動いてない、ということみたい。

現在のcommitによる最適化ルール適用後(-O2もしくは-O1)と、非適用(-O0)のアセンブラコードの比較は多分必要だと思う。というかそれをやるしかないよなあ…

※面倒

1) 現在のcommitで、最適化ルールを削っていく→どこかで動くところが見つかる
2) 最適化ルールを、現在→過去のcommitにさかのぼっていく→どこかで動くところが見つかる

1)と2)を引き起こす箇所は、一致していない

試したことを淡々とissueの形で連ねておけばなんか分かってもらえるかな？

で、このバグ報告どう書けば良いんだろう。すごく難しい英語になりそうな気がするんだけど。

あー、NEGってed 44だから2byteコードか。8ステート。
AND rとかOR rの類は4ステートなので、なるたけこれを狙いたい。

and a→and (hl)もダメ、or (hl)もダメ。

nopを挟む, neg, inc a + dec aは8ステートなので、add/sub a,0ないしcp 0の7ステートで逃げるしかないか。

and aの代わりにneg突っ込めば大丈夫。

でも何でor aじゃダメなんだろうね？

うーん、
ld a,(hl)
and a
jp %1z,%2 ;%3
ld hl,%4
and aの部分をor aにしてもおかしい。
cp 0、inc a + dec a、and a + nop、nop + and a、add a, 0の組み合わせなら問題ない。

あれか、最適化した後のコードをさらに最適化とかしていて、その際になんかおかしなことを始めちゃうんだろうかね？

https://github.com/z88dk/z88dk/commit/e0388f03ffb4533e5c0d31ce77f6843412e0a97e
この修正の、前半に追加されてるline 4560~4587の部分が悪さしてる。line 5270~の修正は無関係。

さらに細かく見ると、%check 0 <= %1 <= 255以降を削ってもIchigJam BASICの動作がおかしいのに対し、それ以前（call l_gchar～ld hl,%4）を削れば改善する。

call l_gchar
ld a,h
or l
jp %1z,%2 ;%3
ld hl,%4
=
ld a,(hl)
and a
jp %1z,%2 ;%3
ld hl,%4

このセクション。何やってんだろこれ。

commit e0388f03ffb4533e5c0d31ce77f6843412e0a97e
Date: Sat Apr 3 18:17:58 2021 +0100
NG

こいつか

https://github.com/z88dk/z88dk/commit/e0388f03ffb4533e5c0d31ce77f6843412e0a97e

commit 1aa6f82a6da9c93f3f8c0a96f07d6e217e4ab88a
Date: Tue Aug 4 21:34:20 2020 +0100
OK

commit 239d3c3ae7d385d197332b2b0a354ce967338d88
Date: Sun Jun 20 22:23:18 2021 +0100
NG

commit 52ca45e772de53a7a34662e3742518c0f2dee8cd
Date: Sat Mar 20 19:56:31 2021 +0000
OK

commit e745499d2bedf1ff37733070cf7f5bed18c7b483
Date: Sat Apr 3 12:25:19 2021 +0100
OK

commit eae581dfa63cf94114c0495409d2912b88de542a
Date: Sat Apr 3 13:35:34 2021 +0100
OK

やっぱこの部分だけ抜く、では状況変わんない…

ピープホール最適化、ある命令シーケンスをこういう形に置き換えてねって最適化なのはわかるんだけど…

シーケンス（大）→置き換え(A)
シーケンス（小）→置き換え(B)

の時に、シーケンス（大）の中にシーケンス（小）が含まれるとどうなるんだろうというのは気になるところ。

2064行目の
jr nz,ASMPC+3
scf
call c,%2
=
call z,%2
なんてさっきのをjp→callに置き換えてるけど、これだって問題になりませんかね。

3394行目以降を削除→エラー出る
3307行目以降を削除→エラー出る
3201行目以降を削除→エラー出ない
3250行目以降を削除→エラー出ない
3275行目以降を削除→エラー出ない
3294行目以降を削除→エラー出る
3281行目以降を削除→エラー出る

3275行目～の最適化ルールって
jr nz,ASMPC+3
scf
jp c,%1 ;%5
=
jp z,%1 ;%5
これなんだけど…ここだけさっくり外して大丈夫なんか？

3500行目以降を削除→エラー出る
1750行目以降を削除→エラー出ない
2612行目以降を削除→エラー出ない
3080行目以降を削除→エラー出ない

{ "COPTRULES1", 0, SetStringConfig, &c_coptrules1, NULL, "", "\"DESTDIR/lib/z80rules.1\"" },

もしかしてCOPTRULES1=ファイル名、とかすると最適化ルールをいじれるのかな

デフォルトだとはz80rules.9→2→1→0(→8)の順で最適化入れるのか。

case 2:
rules[num_rules++] = c_coptrules2;
rules[num_rules++] = c_coptrules1;
break;
default:
rules[num_rules++] = c_coptrules2;
rules[num_rules++] = c_coptrules1;
rules[num_rules++] = c_coptrules3;
break;
}

/* z80rules.9 implements intrinsics and RST substitution */
rules[num_rules++] = c_coptrules9;

switch (peepholeopt) {
case 0:
break;
case 1:
rules[num_rules++] = c_coptrules1;
break;

z88dk(sccz80)、-O2はz80rules.9→2→1の順
-O1はz80rules.9→1の順
-O0はz80rules.9のみ
というルールファイルを使ってz88dk-coptを実行してる

やっぱ汎用的にμsecくらいの待ちを行うコードを書くのってすごく難しい。特定の機種の特定の設定、って範囲を限定してくれないと自分のスキルじゃ無理だわ。

この質問者って、模試作ったメーカーに「あんたの解説は正しくない！誤りを見つけてやったんだから謝礼寄越せ！」って言いたくて言いたくて仕方がないっていうのが行間からものすごく滲み出てる。

潰えた野望（ついえた-やぼう）

「将来の機能拡張のために予約」…この言葉を見るたびに気分が落ち込むな。

拡張された将来、が来なかったのだから。

（なんかおじーちゃんがボケ防止のために昔の資料引っ張り出してあーでもないこーでもないしてる、というのをやっているよな自分…）

MSX-BASICのワークエリアにJIFFY(0FC9EH, 2byte)があってこれがVDP割り込みによるカウンタなんだけど… http://ngs.no.coocan.jp/doc/wiki.cgi/datapack?page=2%BE%CF+%B3%E4%A4%EA%B9%FE%A4%DF

1/60secとは限らないんだよなコレ。PAL機なら1/50secというケースもあるし…確かMSX向けのMegaDemoでも50Hz/60Hz切り替えがあるものがあったと記憶してる。

MAIN ROMの0x2bを読めば自動判別できるはずなんだけど…MSX-DOS上からだとめんどいよね。
http://ngs.no.coocan.jp/doc/wiki.cgi/datapack?page=7%BE%CF+%A5%D7%A5%ED%A5%B0%A5%E9%A5%E0%B3%AB%C8%AF%A4%CE%BD%F4%C3%ED%B0%D5

買い替えたくても金が無い（そして中古も意外に安い…安物買いの銭失いであると分かっていたとしても）。

テレビ・ラジオ・新聞を牽制する役割をインターネットに求めているのだけど…ある程度はできているのか、あるいはこいつら（テレビ・ラジオ・新聞）がインターネットを取り込もうと今でも躍起になっているというか…

そろそろテレビ局の一つや二つ、断末魔を聞きたいな、って思ってはいるんだけど。まだかなあ。

このアカウントは、notestockで公開設定になっていません。

Philips mShield for hospital networks Securing medical devices
https://www.philips.com/c-dam/b2bhc/de/resourcecatalog/landingpages/smartpath/de/philips_mshield_white_paper_lr_spread_pages_final.pdf
非常に字が小さくて読みづらいけど
「mShield consists of both hardware and software, and is
based on the security-oriented operating system
OpenBSD.」など、OpenBSDが使われていることが書かれている。

これなのかな
OpenBSD on medical x-ray machines (AsiaBSDCon 2018)
https://www.youtube.com/watch?v=vOVoylirkUU (YouTube)
https://www.openbsd.org/papers/asiabsdcon2018-xray.pdf (PDF)

単に画像を見る、というよりは画像を解析するのでCPUパワー欲しいって話になるのかな。適当に検索してたらこんなのが見つかったんだけど（ちょいとグロい画像もあるので閲覧注意）。
https://www.medicalexpo.com/medical-manufacturer/linux-software-57997.html

ALAFIA AIVAS SuperWorkstation Product Overview https://amperecomputing.com/assets/ALAFIA_AIVAS_SuperWorkstation_Datasheet_Overview_Ampere_Embedded_World_83e121dda2.pdf

大量のCPUコアとGPUをLinuxで回す、までは分かったけど…どんなアプリを動かすんだろう（医者じゃないので名前聞いても分からないけど気にはなる）。

uaa@framboise:~/z/ichigojam-firm/console$ TOOLCHAIN=z88dk-sdcc gmake
zcc +cpm -lm -clib=sdcc_iy -I../IchigoJam_BASIC -I./src/ ../IchigoJam_BASIC/main.c -o IchigoJam_BASIC
../IchigoJam_BASIC/ram.h:106: warning 278: return type of function omitted, assuming int
../IchigoJam_BASIC/ram.h:106: error 1: Syntax error, declaration ignored at 'uint8'
../IchigoJam_BASIC/ram.h:106: syntax error: token -> 'ram' ; column 9

標準品(?)のllvmじゃなく、sdccと組み合わせるためのllvmを用意しないといかんか…

uaa@framboise:~/z/ichigojam-firm/console$ clang -S -o tmp2.ll -emit-llvm -O2 -I../IchigoJam_BASIC -I./src ../IchigoJam_BASIC/main.c -nostdinc -I/usr/local/share/z88dk/include
In file included from ../IchigoJam_BASIC/main.c:16:
In file included from ./src/config.h:9:
In file included from /usr/local/share/z88dk/include/unistd.h:9:
/usr/local/share/z88dk/include/sys/types.h:34:9: error: 'short _Float16' is invalid
typedef short _Float16; /* IEEE-754 half float type */

まあそうなりますよねー…

LLVMに処理したコードをsdccに食わせる、という話は確かに昔聞いてはいた。 http://www.colecovision.eu/llvm+sdcc/

で、確かにこの方法でC to Cな変換をLLVMでやらせることができそう（今はllvm-gccでなくclangになるけども）…と思ったんだけど、ヘッダの処理をどうするかって問題があるのか。
2010-3-20[土] LLVMで Cに変換してみる http://www.6809.net/tenk/?%E9%9B%91%E8%A8%98%2F2010%2D03%2D20