すべてアセンブリ言語で書かれたMenuetOS、ついにバージョン1.0となる 77
ストーリー by headless
遠路 部門より
遠路 部門より
すべてアセンブリ言語で書かれたPC用OS「MenuetOS」が15日、ついにバージョン1.0となった(リリースノート、
Computerworldの記事、
Slashdotの記事)。
MenuetOSはマルチプロセッサーに対応したプリエンプティブマルチタスクOSで、USBやネットワーク、サウンドなどのデバイスをサポート。フロッピーディスク1枚の容量にWebブラウザー/サーバーやFTPクライアント/サーバー、電子メールソフト、開発環境、ミニゲームなどが同梱されている。今回バージョン1.0がリリースされた64ビット版のMenuet64は個人および教育で使用する場合は無償だが、商用の場合は別途許可を得る必要がある。許可なく再配布やリバースエンジニアリンクなどをすることは禁じられている。一方、32ビット版のMenuet32はGPLとなっている。
Menuet32の最初のバージョンがリリースされたのは2000年5月16日。バージョン1.0に到達するまでに15年を要したことになる(Menuet32は2月にリリースされたバージョン0.86が最新版)。Menuet64の最初のバージョンがリリースされた2005年6月22日からは、ほぼ10年が経過している。2013年11月にバージョン0.99.34がリリースされた際、開発者のVille Turjanmaa氏は、不完全なコードをリリースすることは避けたいため、バージョン1.0のリリースまでに少なくとも1年はかかると述べていた。
MenuetOSはマルチプロセッサーに対応したプリエンプティブマルチタスクOSで、USBやネットワーク、サウンドなどのデバイスをサポート。フロッピーディスク1枚の容量にWebブラウザー/サーバーやFTPクライアント/サーバー、電子メールソフト、開発環境、ミニゲームなどが同梱されている。今回バージョン1.0がリリースされた64ビット版のMenuet64は個人および教育で使用する場合は無償だが、商用の場合は別途許可を得る必要がある。許可なく再配布やリバースエンジニアリンクなどをすることは禁じられている。一方、32ビット版のMenuet32はGPLとなっている。
Menuet32の最初のバージョンがリリースされたのは2000年5月16日。バージョン1.0に到達するまでに15年を要したことになる(Menuet32は2月にリリースされたバージョン0.86が最新版)。Menuet64の最初のバージョンがリリースされた2005年6月22日からは、ほぼ10年が経過している。2013年11月にバージョン0.99.34がリリースされた際、開発者のVille Turjanmaa氏は、不完全なコードをリリースすることは避けたいため、バージョン1.0のリリースまでに少なくとも1年はかかると述べていた。
凄いとしか (スコア:2, 興味深い)
スクリーンショットのアプリがコレ系の独自OSにしてはかなり充実してます。
どうやって作っているのかとシステムコールのドキュメント見たら、全てアセンブラでした(笑)
あのアプリも全部アセンブラって事ですね。
Re:凄いとしか (スコア:2)
すごいですよね。
昔から「アセンブラでもできるし、サイズも小さく作れる」
とは言われていましたが、やる気と技術力のためか、
「という声もある」止まりな感じでした。
しかし、このOSを見ると「ほんとにできるんだ」と思います。
「利用者やメンテナー」の視点だと、違う感想や想像をしてしまいますが、
技術力として「作った」のはすごいと思います。
Re: (スコア:0)
あのアプリも全部アセンブラ？
あのアプリも全部、アセンブリ言語を機械語にできるってこと？
Re: (スコア:0)
日本語難しいですよね。
日本語(特に口語で)は自明(あたりまえ)の事は省略(elision)できます。
元コメの人の「あのアプリも全部アセンブラって事ですね」は
「あのアプリも全部アセンブラ(を使って作られている)って事ですね」
と言う意味が省略されています。
アプリ=アセンブラと言うそのままの意味にはなりません。
こういう省略は日常会話でも良く使うので覚えておくと会話の幅が広がりますよ。
例えば、皆でお店に入って飲み物を注文するとき、
「A君はウーロン茶で、後の皆はビールね」
と言う言い方をしたりしますが、これはA君=ウーロン茶と言う意味ではなく、
A君はウーロン茶(を注文する)と言う意味が隠されています。
どんな意味が隠されているかは状況によって変わって来るので慣れるまでは難しいです。
日本語を読んでいて、そのままの文で意味がおかしいと思ったら、
省略された意味がないかな？っと考えてみて下さい。
ヘルシンキ発？ (スコア:1)
なんか一人、すごい人が出てくると後続が続くとすればLinusは、フィンランドに貢献したよね。
なぜコンパイラではで出来ないの？ (スコア:1)
なぜ「今更」なアセンブラに負ける部分が残っているのだろうか？
コンパイラのサイズ最適化が甘いのだろうか？
いえ、決してコンパイラやアセンブラをディスってるわけじゃなくて、
コンパイラのサイズ最適化にはまだ大幅な改善の余地があるのか？
それとも、コンパイラ脳より、アセンブラ脳で考えた方が構造的に小さくなるのかな？
という事で
なぜアセンブリ言語？ (スコア:0)
何か理由があってアセンブリ言語にこだわっているのか？ プロセッサの処理能力もメモリもジャブジャブ有り余っていて、昔と比べてコンパイラも飛躍的に性能が良くなったのに..........
Re:なぜアセンブリ言語？ (スコア:1)
電力とか容積をジャブジャブ使えない環境を想定してるから
Re: (スコア:0)
アセンブリ言語ってことはX86のIA32とIA64が前提ですよね。
Intel EdisonでGUI環境構築するとかがターゲットになる…のかな？
ARMとかに移植可能な状態なら大量に出てるARMのPSoC組み込みで使えるけど、
X86な組み込みってそこまでバリエーション無かったと思うんだよなぁ…
古いPCでも近代的な機能が使えて軽いとかならメリットあるけど、
Windowsとかと互換性ないと近代的な機能が使えるうちに入るか微妙だしうーん
Re: (スコア:0)
IA64・・・？
Re: (スコア:0)
Intel 64でしたごめんなさい
Re: (スコア:0)
いやそれ、さんざん言われている幻想だから…。
今時の、pipeliningやout-of-orderバリバリのプロセッサのアセンブリ言語で、コンパイラより効率の良いコードを書くなんて無理よ。
今でも、ごく小さいコードについて人間が最適化するケースはあるけど、OS全体を手書きのアセンブラで書いて、コンパイラに勝つなんてありえない。
コードサイズについても、コンパイルの設定で、余分なランタイムを一切使わないバイナリを生成することだってできるし、その場合手書きコードと比べて劣る点は一切ない。
コードサイズについては、LinuxがCで書かれていることからも明らかでしょ。
Re:なぜアセンブリ言語？ (スコア:1)
LinuxがCで書かれてるのはコードサイズが小さいからじゃない。
生産性とかパフォーマンスとか学習効率とかその他もろもろのバランスが良いから。
参加者全員の知識とスキルが十分に高くて、時間が無限にあるならフルアセンブラで書かれてる。
# 今時アセンブラでバリバリ最適化する人はコンパイラが吐く最適化済みのコードとか
# コンパイラの最適化部分のソースとかも読んだ上で最適化を考えてるのでコンパイラに負ける事はない
Re: (スコア:0)
# 今時アセンブラでバリバリ最適化する人はコンパイラが吐く最適化済みのコードとか
# コンパイラの最適化部分のソースとかも読んだ上で最適化を考えてるのでコンパイラに負ける事はない
これ。人間はコンパイラの吐いたコードを参考にするが、逆はない。
Re: (スコア:0)
ああ、これ見てこの変な流れの理由が分かった気がする。
元コメの人、とにかくアセンブラで書くだけで早くなるんだ！
みたいな、汎用機上がりのおっさんにでも出会って、
それがアセンブラ使いの全てと思い込んじゃってるんじゃないか？
# 知識をアップデートしてないって時点で、自分が馬鹿にしてるアセンブラ使いと同じレベルなんだけど。
Re: (スコア:0)
手書きアセンブラの方が速いとか言っている人は、絶対に今どきのアセンブラの最適化をやったことがないよね。
今どきのCPUの最適化って、ループのμopの数を数えて命令キャッシュに入るか確かめるとか、
ALUの表を作ってパイプラインストールがないかチェックするとか、「こんなことはコンピュータがやれよ」と思うような作業ばっかりなんだけど、
こういう人たちは、優秀なハッカーなら、映画かアニメみたいにすらすら完璧なコードを書けると思ってるんだろう。
Re: (スコア:0)
SSE/AVXのレジスタの割り当てとか、人間がやるほうが効率が良い場合もあるよ。
SSE/AVXのロード・ストア命令もCPUによって最適な命令が違ったりするけどコンパイラはそんなこと考慮にしてくれないしね。
Re: (スコア:0)
元コメとは違うACだけど、
元コメAC氏は「今でも、ごく小さいコードについて人間が最適化するケースはあるけど」とそういった事例は認めた上で、
「OS全体を手書きのアセンブラで書いて、コンパイラに勝つなんてありえない。」と述べてるんですよ。
Re: (スコア:0)
「コードサイズについても、コンパイルの設定で、余分なランタイムを一切使わないバイナリを生成することだってできるし、その場合手書きコードと比べて劣る点は一切ない。」とも言ってますね。
Re: (スコア:0)
高級言語の場合はだいたいABIが決まっているからアセンブラのほうが有利だな
Re: (スコア:0)
irreducibleなグラフはコンパイラは最適化を諦めて保守的になるから、アセンブラのほうが有利だな
Re: (スコア:0)
それ以前の話で、C言語とかでうまく仕様をコンパイラに伝えることができないからじゃないの？
例えば、ローテイト命令、エンディアンの変換なんて、それをC言語で書いちゃうとかなり無駄なコードになってしまう。
それを書かれた言語の意味が変わらない範囲でいくら最適化したところで無駄なコードができてしまう。
そういった一般的によくある問題は、すでにアセンブラなど最適化された関数が用意されてるからいいもののないものに関してうまく伝えることができない。
Re: (スコア:0)
で、アンタはどんなすごい最適化ができるというの？
Re: (スコア:0)
Re:なぜアセンブリ言語？ (スコア:1)
C言語でもC++でもRustでも、実用的な速度で動作するOSを作るならCPU別にアセンブリコードが必要になるから。
x86/x64専用と割りきってアセンブリで書くのもいいと思うけど、x86/x64以外で動かすならQEMUという手もあるし。
Re: (スコア:0)
昔と比べてコンパイラも飛躍的に性能が良くなったのに..........
でもまだ人手でasm書いたほうが速いし小さいじゃん
Re: (スコア:0)
人間てのは「あともう少し足りない」生物なんだなあと、いつも思ってる。
「メモリが4Gから8Gになりました、わーい快適、めでたしめでたし」とはいかなくて
「じゃあ今まで出来なかった事に挑戦だ → やっぱりあとちょっと足りないんだよなあ・・・」となる。
いつもこうだ。
ジャブジャブ有り余る時代なんてまだしばらく来ない。
このOSみたいに100%ピュアasmにこだわるのは、ある程度は道楽だろうけど、ここから1byteを稼ぐアイデアが出てきて、コンパイラやメモリ管理モジュールにアイデアを反映できたりする事もあるんだろう。
Re: (スコア:0)
拘りではなく、それしか出来ないってこともありますよね。
少なくとも1年はかかる (スコア:0)
少なくとも嘘は言っていないな・・・
しかも10年も開発が続いたのはすごい！
スクリーンショットを見るとGUIもあるとは。
プラットフォームはAMD64、x86なのね。
Re: (スコア:0)
開発から10年。
バージョン 1のリリースまで少なくとも 1年はかかると言ったのは2013/11のリリースの時。
Re: (スコア:0)
わかってなかった・・・
いろいろわからん (スコア:0)
ファイルシステムは独自かな?usb mass storage+fat32はサポートとは書いてあるのでfatの実装は含んでるらしいけど。
API見ただけだと分かりません。ディレクトリの作り方もわからん。
Quakeとか書いてあるのでDOS互換のAPIも持ってるってことかな?
そもそもなんで作り始めたのか?がサイトでは見つけられなかった。
Quakeを高速に実行したかったのか、単にOS作る興味だったのか、なんだろうねぇ
…といろいろわからん。
ダウンロードして実行したりインストールされるドキュメント見たりソース見たりすればわかるんだろうけど、
そこまでの興味が起きない(笑
Re: (スコア:0)
動作中のスクリーンショットのタイトルがSDL QUAKEってなってるので、SDLが移植済み…なのかなぁ？
# ドキュメントざっと見るとオーディオのサンプルすらASMベタ書きで、SDLあるならそう言ってくれって気分
システムコールはかなりスッキリまとまっていて、
デバイスドライバのサンプルもスッキリしたインタフェイスになってるけど…
ほんとにこんなんでそれだけの機能が過不足無く動くのか、
フェイクじゃないのか逆に不安になってしまった。
まぁ現物置いてあるし実際動くんだろうけど。
ある方面の先端 (スコア:0)
アセンブラで究極に軽いOSを書きたい！
移植性のNetBSDとかマイクロカーネル(IPC)のL4とか
こういうのはワクワクします
Re: (スコア:0)
どれくらい軽くて速いのか環境ある人の感想が聞きたいですね
最近JQueryばかり使ってて
この富豪感に何やってんだ俺、と思う事がしばしばあるので
ちょっと羨望はありますね
Re: (スコア:0)
クライアントプログラムって、内部的な動作を考えると直感的にこりゃ遅いだろうって処理も体感的にはほとんど分からないくらいだったりしますからね。
アイデアを持たないエンジニアの究極の形 (スコア:0)
よくぞ続けてこられたと絶賛したい気持ち三割、こういう技術者になりたくない気持ち半分以上。
OSを作るのは自分の技術力を試すには格好の車輪かもしれないけど、
その車輪を木や鉄で作るのではなく、砂を糊でちまちま固めて作るようなものではないかなと。
多少精巧なものは出来るだろうけど、役割としては変わらない、車輪は車輪。
それだけの技術力や時間があるのなら、既存の車輪を活かしてもっと別の乗り物を組み立てて、世界を魅了して欲しかったな。
もちろん個人の自由だから、OS作ろうが何しようが勝手なんだけど。
おまけにアセンブラだったら、他の開発者もそう容易く近づけないし、
一世一代のOSで終わりそうなのも残念。
Re: (スコア:0)
CPU変わったら移植性ゼロなんじゃね？
あと、コードの可読性とかチームでのメンテナンスとか出来る？
尤もx86-64はあと15年くらいは大丈夫だと思うけど。
Re: (スコア:0)
>あと、コードの可読性とかチームでのメンテナンスとか出来る？
OS/2はご存知?
Re: (スコア:0)
名前とPC-9801シリーズでリリースされたことがあるくらいしか知らないので教えてくださいorz
Re: (スコア:0)
これとか
『OS/2 の大半はアセンブラで書かれているという』
http://srad.jp/comments.pl?sid=382782&cid=1262131 [srad.jp]
Re: (スコア:0)
アセンブリ言語って、言語というより命令セットと言った方がよいもので、機械語を人間に読みやすく1対1対応させたもの。
だから原則的にはCPU固有のものなのよ。
もちろん後方互換は意識されるし、元コメが書いているようにx86がそうそう消えるとは思わないけど。
だからこのOSはPowerPCやARMでは少なくとも直接は動作しない。
それでも遥か昔は、こういう命令セットをいくつも覚えているのが普通の時代があったのだ。
命令セットがコンパクトだったり単純だったという事もあるだろうけどね。
それでも、CPU固有の命令セットなんて覚えていられないわけで、
汎用的な命令セットというか言語を作って、各CPU向けに翻訳すれば良いんだ！と考えて出来たのが高級言語。
こういう技術史は直接役には立たないかもしれないけど、知っておいて損は無いよ。
Re: (スコア:0)
どっちかというとそれらは中間コードに当てはまりそうな説明ですね。
LLVMのビットコードやJavaVMのバイトコードや.NETのMSILみたいな奴。
# こいつらでOS書いたら、JITコンパイル機能を持ったブートローダーを各CPU向けに記述すれば移植可能なOSとか出来上がるのかなとか一瞬思ったけど、各CPUやアーキテクチャに依存したタスクスイッチや割り込み周りの記述を解決する仕掛けがないと無理だったorz
Re: (スコア:0)
命令セットと言語の違いが曖昧な書き方だったね。
中間コードを含めるとざっくりこんな歴史になると思う。
1. アセンブリ言語だと覚えるの辛いし汎用性ないからCという「言語」を作ろう
2. Cだと効率の悪いところがある部分的にアセンブラで書くか。CPUの違いはマクロとかで吸収しよう。
3. アセンブラやっぱり辛いし、部分最適だと汎用性に欠けるので、「言語」から中間コードという「汎用的な命令セット」に翻訳して、
中間コードを使って最適化だ！
Re: (スコア:0)
長々と書いている割に内容が空っぽなのに哀しみを禁じ得ませんが
本件の場合は、車輪→既存のハード、乗り物→このOS、アプリや人間→乗り手だよ。
＃アセンブラを知らなきゃ仕方ないか～
Re: (スコア:0)
君の好きなように例えていいが、どうやっても新規性はない
Re: (スコア:0)
であんたは何をなしとげたのかな？
あんたみたいなのにはなりたくないな
Re: (スコア:0)
なしとげた事と、くだらない事なしとげた人の批判と、論理的にどう関係があるの?
Re: (スコア:0)
まあまあ。
「俺はオヤジみたいに平凡な大人にはなりたくない！」って
言っちゃうのは、正常な発達過程だと思いますよ。
まあ大人になったら、しんちゃんパパがかなりの勝ち組であることに気がつくわけですが。
Mona OSの作者は現在Twitter本社で働いている (スコア:0)
「OSASK」「Mona OS」とか、個人製作の国産OSが話題になっていたのって
もう10年以上前の話になってしまうのですね。
「MenuetOS」もそういう中で名前が出てきたので覚えています。
Mona OSの作者は現在Twitter本社で働いているそうですね。
http://gihyo.jp/lifestyle/serial/01/survival_strategy_engineer/0005 [gihyo.jp]
http://hrnabi.com/2014/09/24/3739/ [hrnabi.com]
http://logmi.jp/33415 [logmi.jp]