← 2026-03-29 の一覧へ戻るホーム
オープンブースト・オン・モトローラ 88000プロセッサー

2026/03/27 23:39

オープンブースト・オン・モトローラ 88000プロセッサー

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

（欠落している詳細を補完しつつ明瞭さを保つ）**

モトローラ 68000 ファミリーは、1990年代中頃のワークステーション（Apple、Amiga、Atari ST、Sun、HP、NeXT）や多くの産業用ボードで普及していました。  
その RISC 後継機種である 88000（m88k）は、68k と PowerPC の間に導入されましたが、約 1994 年頃に期待された性能を提供できず廃止されました。m88k は二世代存在しました：

• 88100 – 第1世代 CPU で、オプションの外部 88200 CMMU チップを搭載し、MVME180（20 MHz、2 本の CMMU）と MVME181 に使用されました。  
• 88110 – 第2世代 CPU で、統合キャッシュ／MMU を備え、50 MHz を想定していましたが実際には約 40 MHz で販売されました。MVME187（25 MHz、デュアル CMMU、最大 64 MB）、MVME188（SMP、最大 4 CPU と 8 CMMU）、および MVME197 系列（セカンダリキャッシュ）に搭載されました。

VME バスは 32‑bit アドレス／データラインを備えたパッシブバックプレーンであり、複数ボードサポート、割り込みベクタ、オプションのスレーブマッピング、および終端要件があります。

OpenBSD のポートは 1995 年に MVME187 上で開始されました。Nivas Madhur、Steve Murphree、Marc Espie らの貢献は CVS マージ競合、アカウント停止（Theo de Raadt の関与）、GCC‑2.95 互換性問題、カーネルパニック（「align & align‑1」アサーション）および MVME188 上の不完全な SMP サポートに直面しました。ポートは 3.1‑beta スナップショットまで達成しましたが、ハードウェアエラー（VME バスロックアップ、DCAM2 コンフリクト、I²C フェイル）が未解決のまま残っています。

m88k アーキテクチャに関するドキュメントは、モトローラ AT&T System III/V、Data General DG/UX、Omron UniOS などのプロプライエタリ Unix バリアントと無料 CMU Mach コードから取得されました。メンテナー間の個人メール交換は協力、衝突解決、およびニッチなポートの保守課題を示しています。

MVME VME ボードおよび他の m88k システムのユーザーは、この OpenBSD ポートに安全性と安定性を依存しています。継続的なサポートがない場合、利用可能な OS を失うリスクがあり、新しいアーキテクチャへの移行が必要になるかもしれません。

*改善された要約はすべての主要ポイントを反映し、不適切な推測を回避し、主旨を明確に提示し、曖昧または混乱を招く表現を排除しています。

本文

（リンクをクリックすると、メインのm88kページに戻ります。）

PART 1：忘れ去られた RISC アーキテクチャ

いいえ、タイプミスではありません。

多くの人はマツリックス（Motorola）の 68000 アーキテクチャを知っているか、あるいは耳にしたことがあるでしょう。
このプロセッサは次のような機械で使われていました：

  • 初代 Apple Macintosh コンピュータ
  • Amiga と Atari ST のホームコンピュータ
  • Sun、HP、NeXT（例として挙げるだけ）などが製造したワークステーション
  • Motorola、Tadpole、Heurikon、Performance Technologies などが製造した産業用システムやボード（例を挙げるだけ）

68000 アーキテクチャは非常に成功しましたが、その CISC 性質（複雑なアドレッシングモードと多くの命令）ゆえ、Motorola はスピード競争に追いつけませんでした。

性能と MHz を提供するためには、より容易に拡張できる別のプロセッサアーキテクチャが必要でした。

PowerPC について話すのではないかと思われるでしょう。PowerPC も後世の Apple Macintosh コンピュータや IBM と Bull（主に）からのワークステーション、そして象徴的な BeBox に採用され、成功したアーキテクチャです。
68000 と PowerPC の間には「黒い羊」と呼ばれる家族の一員がいます。多くの約束をしたにもかかわらずそれらを果たせず、忘却に沈められたまま――悪夢だったような存在です。

そのアーキテクチャは Motorola 88000（略称 m88k）です。

m88k の概要

Motorola が全エンジニアを PowerPC に再配置する前に、88000 プロセッサは二世代存在しました。

  1. 第一世代 – オプションの外部 88200 「CMMU」（キャッシュ‑メモリ管理ユニット）付きの 88100 CPU。

    • CMMU はキャッシュメモリと MMU 機能を両方提供します。
    • 別々のチップにすることで、MMU を必要としない設計を迅速かつ安価に完成できました。NCD はこの理由で 88100 を X ターミナルラインで大量採用しました。
    • すべての CMMU はプロセッサと同じ P‑Bus 上に配置され、密接に協力して機能を果たします。このバスを共有することで、各 CMMU は他の CMMU を監視し、プロセッサ間で自動的にキャッシュ整合性を保つことができます。また、すべてのプロセッサから可視化されるため、あるプロセッサは別のプロセッサに代わってキャッシュ無効化や MMU 操作を行うことができ、割り込みを発生させずに済みます。
    • これにより、多プロセッサ実装はソフトウェア的観点から従来のアーキテクチャよりも格段に容易になります。

  2. 第二世代 – 88100 の欠点を学び、Motorola はより伝統的なアーキテクチャへ戻しました：キャッシュと MMU を 88110 CPU に統合し（システムプログラマ向けにははるかに単純な例外モデル）

    • 当初は 50 MHz で動作させ、将来的に 100 MHz を目指す予定でした。初期の 50 MHz プロセッサは安定してその速度で動作できず、欠陥が修正されるまで 40 MHz 部品として販売されていました。その後、50 MHz 超（最大 60 MHz）で動作する部品が生産され始めました。
    • IBM が PowerPC プロジェクトへの協力を求めた際、Motorola は短命の AIM（Apple–IBM–Motorola）同盟を終えてパワーアップを中止しました。

88110 の設計の一部は最初の PowerPC プロセッサへ取り入れられました。特に PowerPC 601 の外部バスは 88110 と非常に似ています。

m88k ハードウェア

短い寿命（≈1988‑1994）と、第一世代ではシステム設計の複雑さから、このアーキテクチャ上でシステムを構築したハードウェア企業は少数でした。今日ではこれらのシステムに関する情報はほぼ残っていません。

OpenPA の名高き Paul Weissmann は、m88k エコシステムを「badabada」という名前で文書化する比較的控えめな取り組みを始めました。このサイトは現在オフラインですが、最後のバージョンは Internet Archive と現在の m88k.com ウェブサイトにミラーされています。

代表的なユーザー

  • Motorola – 自社製 MVME VME ボードラインで数モデルを提供。
    VME（Versa Module Eurocard）バスは、68000 プロセッサ向けに設計されたシンプルなバスで、多くの独立したボードが同じ 32‑bit メモリアドレス空間を共有できます。
    VME システムは受動的バックプレーンに VME ボードを差し込み、バックプレーンがすべてのスロット間で信号を転送します。ボードはプロセッサ、メモリ、I/O（Ethernet、SCSI）、グラフィックス、シグナル取得など多岐にわたります。一つのボード（通常左端のスロット）がシステムコントローラーとなり、バス全体をリセットするなどのグローバル操作を行うことがあります。

  • Omron – Luna ワークステーションラインで 88100 プロセッサを採用。Luna‑88k は最大四つの 88100 を再利用し、既存のデスクトップシャーシを活かしたもので、CMU の CMU Mach OS で広く使用されました。

  • Data General – AViiON ワークステーションラインで 88100（後に 88110）を選択しましたが、Motorola が 88000 プロセッサの製造を停止した後は Intel Pentium に乗り換えました。

他にも独自 Unix バリエーションが使用されていました：Motorola の AT&T Unix System III およびその後の System V、Data General の DG/UX、Omron の UniOS。CMU Mach は研究 OS であり、ほとんどのソースコードは無料ライセンス下で公開されています。その Luna‑88K 上での利用により、Motorola 社員 Nivas Madhur が 1995 年に OpenBSD を MVME187 に移植し、m88k の OpenBSD ストーリーが始まりました。

（元テキストの残りはこの形式では長すぎます。特定のセクションや追加情報をご希望の場合はお知らせください。）

同じ日のほかのニュース

一覧に戻る →

2026/03/29 2:39

GitLab の創業者は、会社を立ち上げることでがんと闘う

## Japanese Translation: **概要** 著者は、上部脊柱のT5椎骨に位置する腫瘍性骨肉腫との個人的な闘いを語ります。標準治療オプションを試みたものの適切な臨床試験が見つからない中で、著者は自身の状態に合わせた新しい診断手法と並行治療プロトコルを開発しました。また、「癌ジャーニーデッキ」と埋め込み型OpenAIフォーラムプレゼンテーションを作成し、この経験を記録しています。著者のアプローチはevenone.venturesに掲載されている企業によって支援され、さらにエリオット・ハーシュバーグによる著者の旅路についての包括的な記事や、ルクサンドラ氏が執筆した「The bureaucracy blocking the chance（機会を阻む官僚主義）」という患者優先医療実践を批判する作品も広い文脈に含まれます。治療データと詳細なタイムラインは、https://osteosarc.com/ で公開されており、データ概要ドキュメントや25 TBの読み取り可能なGoogle Cloudバケットが含まれています。著者は読者にメールリストへの登録を促し、更新情報を受け取れるよう案内しています。また、`cancer@sytse.com` で連絡を取ることもできます。

2026/03/29 5:39

CSSは終焉を迎える運命にあります。

## Japanese Translation: この記事は、CSSのみでレンダリングを行い、ロジックには最小限のJavaScriptしか使用しない完全にプレイ可能なDOOM風ゲームをウェブブラウザ上で動かす方法を紹介しています。壁・床・天井・スプライト・弾道などを表現するために数千もの `<div>` 要素が生成され、各要素はカスタムプロパティとして生のDoom座標を保持し、CSS が `hypot()`（距離）や `atan2()`（角度）といった関数で幾何学を計算します。ワールドはプレイヤーの動きに逆行するように `translate3d` と `rotateY` で移動されますが、CSS にはカメラオブジェクトがないためです。 床は `rotateX(90deg)` で回転し、`clip-path`（または新しい `shape()` 関数）を使って任意の多角形や穴に切り取られます。テクスチャタイルはセクター全体にわたって背景位置をワールド座標に合わせて (`background-position: calc(var(--min-x)*-1px) …`) 配置されます。ドア、リフト、その他の動的要素はカスタムプロパティ上で CSS トランジションによってアニメーションし、JavaScript が状態属性を更新します。スプライトは `rotateY` でカメラに向き、`scaleX` で鏡像化したビルボードです。スプライトのアニメーションは CSS の `steps()` キーフレームで行い、攻撃・死亡フレーム用のデータ状態は JavaScript が供給します。弾道は CSS アニメーションで移動し、衝突検出はまだ JavaScript で処理されます。 照明はセクターごとに `filter: brightness(var(--light))` を使って全体的に適用され、ちらつくライトは `@property --light` を通じてアニメーションします。プロジェクトではアンカー位置決め、`@property`、および「ハッキー」な CSS‑のみのカリング手法（オフスクリーン要素を隠すために負の遅延でアニメーションを一時停止）といった実験的機能が採用されています。 数千もの 3D 転送された要素によるパフォーマンスは課題となり、著者は JavaScript で手動フラスタムカリングを実装し、条件付き `if()` のサポートが登場すれば将来的に純粋 CSS ソリューションへ移行する計画です。記事では Safari のビュー遷移による 3D フラット化、background‑image 再ラスター化の問題、コンポジタ不安定性などブラウザバグも文書化し、インラインスタイルやバグ報告といった回避策を紹介しています。 著者はより多くのロジックを純粋 CSS に移すことで JavaScript を完全に排除できる可能性があり、パフォーマンスをさらに向上させることを想定しています。成功すれば、このアプローチは軽量なブラウザベースゲームを刺激し、高度な CSS グラフィックス機能のサポートを促進し、重いエンジンを必要としない効率的なレンダリングが求められる開発者に利益をもたらすでしょう。

2026/03/27 6:16

データのコピーやサーバーの立ち上げなしに、チーム横断でデータベースを統合する

## Japanese Translation: --- ## Summary Datahikeは、データベースのすべての状態を不変スナップショットとして保存します。各スナップショットは、ノードがコンテンツアドレス化され、バージョン間で共有される永続的なB‑tree派生構造です。そのため、書き込み時には新しいノードが作成され、古いノードは変更されません。接続(`@conn`)を参照すると、ブランチヘッドキーのみがロードされ、以降のクエリノードはストレージから遅延読み込みされローカルにキャッシュされるため、読み取りは高速です。 ライターは各トランザクションを直接永続ストレージへフラッシュするため、ストア自体が権威的であり、読みアクセスには別途トランザクタやAPI層は不要です。これによりDatahikeはサーバーレスで低遅延のリードエンジンとなります。 システムは**Konserve**を使用しており、S3、ローカルファイルシステム、JDBC、IndexedDBなど多くのバックエンド上に抽象化されています。ブラウザクライアントは`konserve-sync`でデータベースをローカルにレプリケートでき、クエリはローカルレプリカに対して実行されるため往復通信が不要です。WebSocketによる同期では変更されたツリー・ノードのみが送信され、構造的共有を活用した効率的な更新が可能です。 Datahikeの値ベースモデルは、異なるバックエンドにある複数のデータベースを単一のDatalogクエリで結合できるようにします。また、`d/as-of`を使用して異なる時点のスナップショットを混在させることで、追加の調整なしに履歴データを監査・デバッグできます。 Clojure REPLのサンプルでは、2つの独立したデータベースを作成し、それらにデータを投入してクロスデータベース結合を実行する方法が示されています。バックエンドキーワードを変更するだけで同じコードが異なるストレージバックエンドでも動作します。従来のETLパイプライン、メッセージキュー、およびAPI層を排除することで、このモデルは遅延・保守負担と新たな障害モードを削減し、不変スナップショットデータベースを分散アプリケーションに実用的にします。