ここにいる私の同僚は私に1つの有用な負荷を与えました。選択的失明の危険性について簡単に話をします。彼女と一緒にいると、私たちの業界は完全に安全ではないからです。それでは、まず、私たちの共通の敵である忌まわしい失明と戦う前に、コミュニティが実際にどうあるべきかを確実に知るために、コミュニティが見ないものの例を議論し、研究しましょう。

物語

だから、1986-89。ニクラウス・ワースと彼の同僚は、グラフィカルユーザーインターフェイス、インターフェイスでテキストを使用するための高度な概念、そして全体としてN.ワースの概念の適用性の重要な証拠である、Oberonシステムの最初のバージョン、マシン、Oberon言語コンパイラ、およびSystem Oberonオペレーティングシステムを開発しました。このオペレーティングシステムは、製品と言語の進化的分岐の始まりを困難な運命でマークしました。それぞれが個別の記事に値します。

ほぼ30年後、ITにおける製品の制御不能な合併症の状況を観察したN. Wirthは、小型で強力かつ信頼性の高いシステムを構築する方法についてのビジョンをもう一度発表することにしました。著者の仕事そのものが、そのようなシステムが存在して機能している証拠として役立ちます。

すべてが流れ、すべてが変化する

判明したように、元のシステムで使用されていたプロセッサモデルはすでに市場から姿を消しています。建築物のように。 N. Wirthは、既製の商用ソリューションを使用する代わりに、システムを別のコンポーネントであるLolaというFPGAプログラミング言語のバージョンで補完することにしました。したがって、新しいマシンのプロセッサは、RISCに基づいてWirth自身が開発しました。これについては、記事の別のセクションで検討します。システム全体は、1 MBのメモリと25 MHzのプロセッサを備えたザイリンクスSpartan-3開発ボードで動作しました。

つまり、ゼロからコンピューティングコンプレックスの開発のフルサイクルが実装され、エンジニア/プログラマーが利用できるこのプロジェクトのすべての段階が実装されるプロジェクトがあります。

CPU

RISCアーキテクチャは、データを使用したプロセッサ操作の特別なシーケンスによって区別されます。すべてのプロセッサプロセッサ命令はレジスタにあるデータで動作し、データは特別なプロセッサ命令SAVEおよびLOADによってメモリとの間で転送されます。したがって、命令ごとのクロックサイクル数が予測可能な場合に作業の単調性が達成され、多くの場合、ほとんどの命令が1クロックサイクルに収まります。 Wirthプロセッサの機能は、データをメモリに書き込むためのパイプラインの並列動作でもありますが、このため、結果のプロセッサの周波数を50〜25 MHzから半分に減らす必要がありました。

コマンドシステムは32ビットワードに基づいており、コマンドの形式を決定するために最上位4ビットが与えられます。コマンドの形式によって、操作のクラス、オペランドの数、およびそれらの場所が決まります。

ALUコマンドは、3つのレジスターまたは2つのレジスターと定数を使用して、算術および論理演算のセットを定義します。 ALUチームは、特別なシングルビットレジスタに結果の符号に追加の値を残します。

メモリコマンドは、メモリにロードして、レジスタの1ワードまたは1バイトをメモリから読み取る命令を定義します。

フロー制御コマンドを使用すると、PCレジスタの値を制御して、レジスタまたは定数の値に基づいて条件付きおよび無条件の遷移を記述することができます。

システムには16個のレジスタがありますが、いくつかの上位レジスタはオペレーティングシステムとコンパイラによってサービスとして予約され、スタックへのポインタ、モジュールテーブルのアドレスなどを格納します。

次のようになります。

一連の指示についての詳細は、一般化されたドキュメントと特定のドキュメントに記載されています。 Verilog言語でプロセッサと周辺機器の図を提供しますが、その後のエディションでは、追加のデバッグと検証の後、Wirthは言語の説明とともにLola回路を提供しました。

Wirthは、RS232などのいくつかの標準インターフェイスを使用した作業のスキームと実装についても説明し、データストレージとしてSDカードを接続する方法についても説明します。周辺機器の実装方法はプロジェクトのドキュメントに記載されています。私は主にプログラマであり、電子技術者ではないため、非常に幼稚な間違いを防ぐために詳細を説明しません。おそらく、経験豊富な同志がこのギャップを埋めるのに役立つでしょう。

システム

OSの主な目標は、ユーザーとプログラマーに一定レベルの抽象化を提供することです。 I / Oデバイス、ストレージデバイス、およびこれらのデバイスとやり取りするためのインターフェイス、およびハードウェアの制限。 Oberonシステムで選択された抽象化の柔軟性により、さまざまなソフトウェアプラットフォーム/ OSで独立したプログラムとしてシームレスに実行でき、プロセッサレベルまたは抽象化のソフトウェア実装のレベルをエミュレートできます。

言語

もちろん、Oberonは将来のOSを作成するためのプログラミング言語として選ばれました。ソース言語は2007年に改訂され、このプロジェクトの枠組みの中で、Wirthは言語をさらに簡素化し、有効性の点で疑わしい機能を取り除きました。最小限の機能セットにより、動作するコンパイラの実装が簡素化され、コードの制御が改善されます。システムをゼロから作成するため、これは重要です。

Oberon OSを構築するために重要な主な機能は、モジュール性、基本的なメタ情報、モジュールの動的ロード、およびガベージコレクターが必要なメモリモデルです。

それぞれについて簡単に説明します。

モジュール性

Oberonでは、モジュールはアルゴリズムとデータ構造を構造化する手段であるだけでなく、コンパイル、ロード、および配布の単位でもあります。つまり、モジュールは、コンパイラーがコンパイルできる最小のエンティティーです。他のモジュールに対する1つのモジュールの依存関係は自動的に計算されますが、あるモジュールから別のモジュールへのコードの組み込みにはつながりません。コードのバージョンを制御するために、インポートされたエンティティの識別子と依存関係のハッシュコードのみが含まれます。

モジュールはロード単位です。つまり、特別な場合を除き、モジュールコードはエントリポイントがあり、無制限の時間実行できる完全なプログラムです。つまり、完全なプログラムです。 OSカーネルでさえ、メモリにロードされる最初のモジュールにすぎません。

また、モジュールは、ソースの形だけでなく、バイナリーの形でも、インターフェース部分の形でも配布されることを想定しており、その起動には特定のプラットフォームまたは複数のプラットフォームのみが必要です。一般に、これらの概念はOberonのモジュール性の概念に含まれており、モジュール指向プログラミングを構成します。

基本的なメタ情報

モジュール性の概念は、任意の数のモジュールが同時にメモリ内に存在できることを前提としていますが、すべてのモジュールが互いについて何かを知ることができるとは想定されていません。この場合、ユーザーまたはプログラマーは、そのようなモジュール内のエンティティーにアクセスする必要があります。このため、メタ情報の存在の要件がOberon言語実行環境の要件に導入されています。モジュラーシステム内の特定のエンティティも不明である可能性があるため、このプロジェクトでは、メタ情報はフルネームでモジュールのエクスポートされたプロシージャに制御を移すことができることのみが必要です。

動的なモジュール性

OSがインフラストラクチャ製品であり、それ自体ではユーザー向けの特定のアプリケーションを持たないため、ユーザーはプログラムのプロセスで必要なモジュールをロードできる必要があります。。同時に、モジュールにはエントリポイントと1回実行される本体がありますが、重要なポイントは、モジュールがメモリにロードされたままであり、他のモジュールのさらなる作業のためにそのタイプと手順を提供できるという事実です。そのため、OSが既にロードされているモジュールに制御を移し、同時にモジュールをロードしてそのプロシージャを実行できるようにするには、名前でプロシージャを実行できる必要がありました。もちろん、この機能には主流の想像を絶するほど複雑な類似物がありますが、現時点ではこの機能で十分です。とにかく、それはライブラリに実装されていますが、言語に何も追加する必要はありません。

ごみ収集

Oberonオペレーティングシステムでは、ヒープ上の動的オブジェクトの配置を制御するガベージコレクションがOSカーネルレベルで実行されます。コンポーネント環境の場合、クライアントに動的オブジェクトを提供するコンポーネントはメモリからそれらをいつ削除するかを決定できないため、ガベージコレクターは明らかに必要です。

このテーマに関するWirth自身からの引用を以下に示します。

Oberonシステムは、変数が参照されなくなることをプログラマが通知できるようにする明示的な割り当て解除手順を提供しません。この省略の最初の理由は、通常、プログラマーが割り当て解除をいつ呼び出すかわからないことです。そして第二に、この「ヒント」は

信頼できるとみなされない。誤った割り当て解除、つまり問題のオブジェクトへの参照がまだ存在するときに発生する割り当て解除は、同じスペースの複数の割り当てをもたらし、悲惨な結果を招く可能性があります。したがって、ストアのどの領域が本当に再利用可能かを判断するために、システム管理に完全に依存することが賢明と思われます。

したがって、言語とその実行環境（OS、ランタイム）の要件が定義されたら、コードの記述を開始できます。実際、一連の機能のOSはほんの数個のモジュールで記述できます。他の機能は、サードパーティのコンポーネントに引き継ぐことができます。コンパイラはOSの一部である必要はありませんが、それなしではプロセッサ用の単一のコマンドを作成できないため、最初に検討します。

コンパイラ

プログラミング言語とは、構文を構成する限られた式のセットによってリンクされたキーワードのセットからの文字の無限のセットです。各式は、それを記述するための規則を備えた構文構造です。記述内容の意味は、各構成に関連付けられた一連のセマンティックルールによって決まります。

オベロン

初版のOberonは、構成に余分なものがない言語として考えられていました。言語のミニマリズムに関連する明らかな問題を解決するために、モジュール性の概念が提案されました。したがって、異なる機能のモジュールのセットは、言語自体の機能の拡張的な成長を効果的に置き換えることができると想定されていました。言語の説明は20ページ未満で、コンパイラは非常に迅速に実装されます。一般的に、Wirthは学習に優れた言語であることが判明したことを強調しました（Pascalよりも優れています）。もちろん、邪悪な舌はすぐにこのフレーズを拾い上げ、それを急いで、オベロンは学習にのみ適していると主張しました。まあ、中傷は根絶するよりも播種する方が簡単です。

このプロジェクトでわかるように、Oberonとその概念は、あらゆるレベル、低レベル、ミドルウェア、高レベルの回路エディター、メーラーなどでコードを実装するのに適しています。 Wirthは、これらすべてのアプリケーションを彼のOSの概念実証として実装しました。

Oberon言語の低レベルコードの例。

カーネルモジュール、ガベージコレクター。 github.com/ilovb/ProjectOberon2013/blob/master/Sources/Kernel.Mod#L82

(* ---------- Garbage collector ----------*)

  PROCEDURE Mark*(pref: LONGINT);
    VAR pvadr, offadr, offset, tag, p, q, r: LONGINT;
  BEGIN SYSTEM.GET(pref, pvadr); (*pointers < heapOrg considered NIL*)
    WHILE pvadr # 0 DO
      SYSTEM.GET(pvadr, p); SYSTEM.GET(p-4, offadr);
      IF (p >= heapOrg) & (offadr = 0) THEN q := p;   (*mark elements in data structure with root p*)
        REPEAT SYSTEM.GET(p-4, offadr);
          IF offadr = 0 THEN SYSTEM.GET(p-8, tag); offadr := tag + 16 ELSE INC(offadr, 4) END ;
          SYSTEM.PUT(p-4, offadr); SYSTEM.GET(offadr, offset);
          IF offset # -1 THEN (*down*)
            SYSTEM.GET(p+offset, r); SYSTEM.GET(r-4, offadr);
            IF (r >= heapOrg) & (offadr = 0) THEN SYSTEM.PUT(p+offset, q); q := p; p := r END
          ELSE (*up*) SYSTEM.GET(q-4, offadr); SYSTEM.GET(offadr, offset);
            IF p # q THEN SYSTEM.GET(q+offset, r); SYSTEM.PUT(q+offset, p); p := q; q := r END
          END
        UNTIL (p = q) & (offset = -1)
      END ;
      INC(pref, 4); SYSTEM.GET(pref, pvadr)
    END
  END Mark;

  PROCEDURE Scan*;
    VAR p, q, mark, tag, size: LONGINT;
  BEGIN p := heapOrg;
    REPEAT SYSTEM.GET(p+4, mark); q := p;
      WHILE mark = 0 DO
        SYSTEM.GET(p, tag); SYSTEM.GET(tag, size); INC(p, size); SYSTEM.GET(p+4, mark)
      END ;
      size := p - q; DEC(allocated, size);  (*size of free block*)
      IF size > 0 THEN
        IF size MOD 64 # 0 THEN
          SYSTEM.PUT(q, 32); SYSTEM.PUT(q+4, -1); SYSTEM.PUT(q+8, list3); list3 := q; INC(q, 32); DEC(size, 32)
        END ;
        IF size MOD 128 # 0 THEN
          SYSTEM.PUT(q, 64); SYSTEM.PUT(q+4, -1); SYSTEM.PUT(q+8, list2); list2 := q; INC(q, 64); DEC(size, 64)
        END ;
        IF size MOD 256 # 0 THEN
          SYSTEM.PUT(q, 128); SYSTEM.PUT(q+4, -1); SYSTEM.PUT(q+8,  list1); list1 := q; INC(q, 128); DEC(size, 128)
        END ;
        IF size > 0 THEN
          SYSTEM.PUT(q, size); SYSTEM.PUT(q+4, -1); SYSTEM.PUT(q+8, list0); list0 := q; INC(q, size)
        END
      END ;
      IF mark > 0 THEN SYSTEM.GET(p, tag); SYSTEM.GET(tag, size); SYSTEM.PUT(p+4, 0); INC(p, size)
      ELSE (*free*) SYSTEM.GET(p, size); INC(p, size)
      END
    UNTIL p >= heapLim
  END Scan;

Texts, . github.com/ilovb/ProjectOberon2013/blob/master/Sources/Texts.Mod#L127

  PROCEDURE Store* (VAR W: Files.Rider; T: Text);
    VAR p, q: Piece;
      R: Files.Rider;
      off, rlen, pos: LONGINT;
      N, n: INTEGER;
      ch: CHAR;
      Dict: ARRAY 32, 32 OF CHAR;
  BEGIN pos := Files.Pos(W); Files.WriteInt(W, 0); (*place holder*)
    N := 1; p := T.trailer.next;
    WHILE p # T.trailer DO
      rlen := p.len; q := p.next;
      WHILE (q # T.trailer) & (q.fnt = p.fnt) & (q.col = p.col) & (q.voff = p.voff) DO
        rlen := rlen + q.len; q := q.next
      END;
      Dict[N] := p.fnt.name;
      n := 1;
      WHILE Dict[n] # p.fnt.name DO INC(n) END;
      Files.WriteByte(W, n);
      IF n = N THEN Files.WriteString(W, p.fnt.name); INC(N) END;
      Files.WriteByte(W, p.col); Files.WriteByte(W, p.voff); Files.WriteInt(W, rlen);
      p := q
    END;
    Files.WriteByte(W, 0); Files.WriteInt(W, T.len);
    off := Files.Pos(W); p := T.trailer.next;
    WHILE p # T.trailer DO
      rlen := p.len; Files.Set(R, p.f, p.off);
      WHILE rlen > 0 DO Files.Read(R, ch); Files.Write(W, ch); DEC(rlen) END ;
      p := p.next
    END ;
    Files.Set(W, Files.Base(W), pos); Files.WriteInt(W, off); (*fixup*)
    T.changed := FALSE;
    IF T.notify # NIL THEN T.notify(T, unmark, 0, 0) END
  END Store;

(Active Oberon), (Component Pascal, Zonnon), (JVM, CLR, JS), Java. Microsoft Singularity. , , , .

. , , , .

:

symbol character, , .

. . , RISC. .

, .

, , , . . .

, , , - . — -, ROM .

, , , .

, - FPGA .

. , , , . . , . .

, , .

, , , . , SD SPI. , - .

Modules. ( ) , . , , . .

Files, SD-. Files . , , .

, . , , . .

, . , , .

, . . , . BlackBox Windows, .

, , .

, , , — . , .

, , ( ), , . , , . .

, , , . , .

, , , .

.

, , , , , .

, , . , , , .

, . ? — , , , , .

, , , , , , , , - , . , , , .

, , , GNU/Linux , ( , ).

, , , , , -, . , , , . — , , , . , .

. , – . . …( ), – , , . , . … , . …

Project Oberon 2013

物語