IPパスカル

IP Pascal は、 IP ポータビリティ プラットフォーム、複数のマシン、オペレーティング システム、および言語実装システムを使用したPascal プログラミング言語の実装です。言語「Pascaline」(Blaise Pascal の計算機にちなんで命名) を実装し、Pascal Validation Suite に合格しています。

この記事は、かなり古いバージョンの Pascaline について説明しています。Pascaline の新しいバージョンは、Pascal-P シリーズの一部である Pascal-P6 です。以下の参考文献を参照してください。

IP Pascal は、ISO 7185 Pascal の高度に拡張されたスーパーセットである言語「Pascaline」(ブレーズ・パスカルの計算機にちなんで名付けられた)を実装しています。並列タスクモニターの概念、動的配列、オーバーロードとオーバーライド、オブジェクト、および言語に対するその他の多数のマイナーな拡張機能を含む、名前空間制御によるモジュール性が追加されています。IP は、ウィジェット ツールキット、TCP/IPライブラリ、MIDIおよびサウンド ライブラリ、およびその他の機能を含む移植プラットフォームを実装しており、これにより、IP Pascal で作成されたプログラムと IP Pascal 自体の両方を複数のオペレーティング システムとマシンに移行できます。

IP Pascal は、ISO 7185 Pascal への準拠を検証するために作成された大規模なテスト スイートである Pascal Validation Suite に合格した、現在も存在する数少ない Pascal 実装の 1 つです。

Pascaline は ISO 7185 Pascal を拡張していますが、Pascal の型の安全性を低下させることはありません (他の多くの Pascal 方言では、いわゆる「型エスケープ」を含めることで低下しています)。言語の機能はC#の機能に似ており(C++ のような言語を実装していますが、型の安全性は削除されています)、Pascaline はマネージ プログラムが使用できる場所であればどこでも使用できます (C# より 30 年古い言語に基づいていますが)。

IP Pascal は、 ISO 7185 Pascal ( Niklaus Wirthのオリジナル言語を標準化したもの)から始まり、次のものが追加されています。

module mymod(input, output); 

uses extlib;
 const one = 1; 

type string = charのパックされた 配列;  procedure wrtstr( view s: string); private var s: string; procedure wrtstr( view s: string); var i: integer; begin for i := 1 to max(s) do write(s[i]) end ; begin {initialize monitor } end ; begin {shutdown monitor } end .














   

モジュールには、エントリ セクションと終了セクションがあります。モジュール内の宣言は独自のインターフェイス仕様を形成し、インターフェイス セクションと実装セクションの両方を持つ必要はありません。別のインターフェイス宣言ファイルが必要な場合は、モジュールからコードを取り除いてモジュールの「スケルトン」を作成することによって作成されます。これは通常、モジュールのオブジェクトがソースなしで送信される場合にのみ行われます。

モジュールは 1 つのファイルを占める必要があり、モジュールはusesまたはjoinsステートメントを介して他のモジュールを参照します。これを可能にするには、モジュールの名前がファイル名と同じである必要があります。usesステートメントは、参照されるモジュールのグローバル宣言が参照元モジュールとマージされ、その結果として名前が競合するとエラーが発生することを示します。joinsステートメントは、参照されるモジュールが参照元モジュールを介してアクセスできるようにしますが、2 つのモジュールの名前空間はマージしません。代わりに、参照元モジュールはいわゆる「修飾識別子」を使用する必要があります。

モジュール.識別子

ISO 7185 Pascal のプログラムはモジュールと直接類似しており、事実上、終了セクションのないモジュールです。システム内のすべてのモジュールは「デイジー チェーン」されており、それぞれが順番に実行されるため、プログラムは、モジュールとは異なり、完全な機能が完了するまで初期化を終了しないという理由だけで、プログラムの「コマンド」を引き受けます。実際、複数のプログラム セクションがあり、それらが順番に実行される可能性があります。

プロセスモジュールには、プログラムモジュールと同様に、初期化セクションのみがあり、そのセクションで開始、完全な機能、完了を実行します。ただし、プログラムモジュールを実行するメイン スレッドとは別に、独自のスレッドを取得して実行します。そのため、モニター モジュールと共有モジュールのみを呼び出すことができます。

モニターは、外部からアクセス可能なプロシージャまたは関数の各呼び出しでタスク ロックを含み、セマフォによるタスク間の通信を実装する モジュールです。

共有モジュールにはグローバル データがまったくないため、システム内の他のモジュールで使用でき、ライブラリ コードを配置するために使用されます。

モジュール システムは、モニターの概念を使用してマルチタスク/マルチスレッドを直接実装するため、マルチスレッド アクセスの問題の大部分を解決します。モジュールのデータは、ミューテックスまたは相互排他セクションを使用してコードにバインドされます。サブタスク/サブスレッドは、プロセス モジュールを使用して透過的に開始されます。複数のサブタスク/サブスレッドは、モニターまたは共有モジュールにアクセスできます。共有モジュールはデータのないモジュールであり、モニターのロック メカニズムを必要としません。

IP Pascalでは、動的配列は静的配列の「コンテナ」とみなされます。その結果、IP Pascalは、動的配列が元の言語のISO 7185静的配列と完全に互換性を持つ唯一のPascalである可能性があります。静的配列は、プロシージャまたは関数の動的配列パラメータに渡すか、新しい

プログラムtest(output);

タイプstring = charのパックされた 配列;  var s: string;プロシージャwrtstr( view s: string); var i: integer; begin for i := 1 to max(s) do write(s[i]) end ; begin









   





   新着(12);
   s := 'こんにちは、世界';
   wrtstr(s^);
   wrtstr('これですべてです')

終了。

このような「コンテナ」配列は、任意の数の次元にすることができます。

定数宣言には他の定数の式を含めることができる

定数b = a+10;

$ff、&76、%011000

ラベルexit;
 goto exit;

var my_number: 整数;

:= 1234_5678; です。

'_' (区切り) 文字は、最初の数字を除いて、数字のどこにでも含めることができます。これは無視され、数字の数字を区切る目的でのみ使用されます。

const str = 'スペインの雨\cr\lf';

標準ISO 8859-1ニーモニックを使用します。

手順x(i: 整数);前進; 

...

手順x(i: 整数);

開始

   ...

終了;

これにより、カットアンドペーストによる転送の宣言が容易になり、プロシージャまたは関数のパラメータが実際のヘッダー内に保持されて表示できるようになります。

手順エラー(ビューs:文字列);

開始

   writeln('*** エラー: ', s:0);
   halt { プログラムを終了する } 

end ;

プログラムmyprog(入力、出力、リスト);

開始

   writeln(list, 'リストの開始:');
   ...

プログラムecho(出力, コマンド); 

var c: char; 

begin 

   while  not eoln(コマンド) do  begin

      読み取り(コマンド、c);
      書き込み(c)

   終了;
   書き込み

終了。

プログラムnewprog(入力、出力、エラー);

開始

   ...
   writeln(error, 'パラメータが不正です');
   停止する
   ...

「command」はコマンド ラインに接続するファイルなので、通常のファイル読み取り操作を使用して読み取ることができます。

プログラムcopy(source, destination); 

var source, destination: text;
    c: 文字;

開始

   リセット(ソース);
   書き換え(宛先);
    eof(source)ではない間は開始し、  eoln(source)ではない間は開始します

        

         読み取り(ソース、c);
         write(destination, c)

      終了;
      readln(ソース);
      writeln(destination)

   終了

終了。

「ソース」ファイルと「宛先」ファイルは、プログラムのコマンド ラインのパラメーターに自動的に接続されます。

 プログラムextfile (出力) ; var f :整数のファイル; begin assignment ( f , 'myfile' ) ; { 外部ファイル名を設定 } update ( f ) ; { 既存のファイルを保持し、書き込みモードに設定 } position ( f , length ( f )) ; { 追加するファイルの末尾の位置 } writeln ( 'ファイルの末尾は: ' , location ( f )) ; { ユーザーに新しい要素の場所を通知 } write ( f , 54321 ) ; { 新しい最後の要素を書き込む } close ( f ) { ファイルを閉じる } end . 
     
 
      
     
      
      
      
     
 

固定テーブル:レコードa: 整数の配列[1..5] 、 charのパック配列[1..10] end =配列レコード1、「data1」終了、
                   レコード2、「data2」終了、
                   レコード3、「data3」終了、
                   レコード4、「data4」終了、
                   レコード5、「data5」終了終了;
  
                

                   

                

プログラムテスト;
 var a, b: integer;
 begin 
   a := a and b;
   b := bまたは$a5;
   a :=ではないb;
   b := a xor b
終了。

プログラムテスト。
変数a: linteger;
    b: 枢機卿;
    c: 枢機卿;
    d: 1..maxint*2;
...

拡張範囲の仕様は、-maxint..maxint の範囲外にあるスカラーのルールを示します。どのくらい大きな数値が可能かは実装によって異なりますが、Pascaline は、double 範囲の整数の linteger、符号なし整数の cardinal、符号なし double 範囲の整数の lcardinal など、拡張範囲を活用する一連の標準型を定義します。Pascaline は、maxlint、maxcrd、maxlcrd などのこれらの型の新しい制限も定義します。

モニターテスト; 

var notempty, notfull: セマフォ;
プロシージャenterqueue;
 begin 
   while nodata do wait(notempty);
   ...
   シグナルワン(満杯ではない)
終わり;
...
始まり
終わり。

セマフォは、 Per Brinch Hansenによって概説された古典的な方法を使用して、言語内で直接タスク イベント キューイングを実装します。

モジュールtest1;
仮想 プロシージャx;
開始
   ...
終わり;

プログラムtest;
 test1に参加;
プロシージャxをオーバーライド ;
継承されたx
の開始終了;
開始終了。

   

別のモジュールのプロシージャまたは関数をオーバーライドすると、そのルーチンが効果的に「フック」され、そのルーチンのすべての呼び出し元の定義が置き換えられますが、元の定義はフック モジュールで使用できるようになります。これにより、オーバーライド モジュールは古いプロシージャまたは関数に新しい機能を追加できます。これは任意の深さで実装できます。

手順x;
 begin 
end ;
オーバーロード 手順x(i: integer);
 begin 
end ;
オーバーロード 関数x: integer;
 begin
   xx:= 1
終わり;

オーバーロード「グループ」を使用すると、一連のプロシージャや関数を同じ名前で配置し、それらの形式パラメータまたは使用「シグネチャ」でアクセスできます。この概念を実装する他の言語とは異なり、Pascaline は、オーバーロードが互いにあいまいでない限り、同じグループに属するものとしてオーバーロードを受け入れません。つまり、オーバーロードの「優先順位」はなく、オーバーロード グループのどのルーチンが特定の実際の参照に対して実行されるかについての疑問もありません。

プログラムtest;
基本クラスを使用します;
クラスalpha;
 betaを拡張します;
型alpha_ref = alpha
への参照;  var a, b: integer;
          次: alpha_ref;
仮想 プロシージャx(d: 整数);
開始
   aaa:= d;
   自分l:=次へ
終わり;
プライベート
変数q: 整数;
始まり
終わり。
 var r: alpha_ref;
始める
   新しい(r);
   ...
   rがアルファの場合、 ra := 1;
   rx(5);
   ...
終わり。

Pascaline では、クラスはモジュールの動的インスタンスです (モジュールはクラスの静的インスタンスです)。クラスは、モジュールとプロシージャおよび関数の間に存在するコード構造 (型ではありません) です。クラスはモジュールであるため、定数、型、変数、固定、プロシージャ、関数 (「メソッド」になる) などの任意のコード構造を定義し、クラスのクライアントに対して公開したり、「private」キーワードで非表示にしたりできます。クラスはモジュールであるため、修飾された識別子を使用してアクセスできます。

モジュールとしてのクラスは、C# や C++ と同様に、修飾子を必要としない名前空間への自動アクセスを持ちます。クラスの外部では、修飾子付き識別子または参照のいずれかによってクラスのすべてのメンバーにアクセスできます。参照は、クラスに従って作成されるオブジェクトへのポインターです。クラスのインスタンス (「オブジェクト」と呼ばれる) は、new() ステートメントを使用していくつでも作成でき、dispose() ステートメントを使用して削除できます。変数 (またはフィールド) やメソッドなど、インスタンス データが関連付けられているクラス メンバーには、参照を介してアクセスする必要があります。参照は型であり、ポインターに似ており、nil 値を持つことができ、他の参照型との等価性をチェックします。ポインター アクセスを "^" で修飾する必要はありません。

Pascaline は、「参照の猶予」の概念を実装し、インスタンスごとかどうかに関係なく、参照がオブジェクトの任意の部分にアクセスできるようにします。この特性により、クラス メンバーを「昇格」、つまり定数から変数に移動し、さらに「プロパティ」(読み取りおよび書き込みアクセスが「get」および「set」メソッドによって提供されるクラス フィールド) に移動できます。

オブジェクトのメソッドにはオーバーロードとオーバーライドの両方が用意されています。オーバーライドされるメソッドは仮想として指定する必要があります。

オブジェクト メソッドは、キーワードを使用してアクセスするために使用される参照を変更できますself。

単一継承のみが実装されています。

試す

   ...

...
を除いて、それ以外は...;

投げる

「try」ステートメントは一連のステートメントをガードすることができ、コード内でフラグが付けられた例外は「except」の後のステートメントにルーチン化されます。try ステートメントには、try ブロックの正常終了時にステートメントを実行できる else 句も備わっています。

コード内では、throw() プロシージャによって例外が発生します。try ステートメントを使用すると、プログラムはネストされたブロックから抜け出すことができ、プロシージャ内 goto (Pascaline でもサポートされています) のより適切な代替手段となります。処理されない例外はデフォルトでエラーを生成するため、throw() プロシージャは汎用のエラー フラグ システムとして機能します。

assert(式);

システム プロシージャ assert は、テストされた値が false の場合にプログラムを終了させます。これは通常、ランタイム ダンプまたは診断と結合されており、コンパイラ オプションによって削除できます。

IP Pascal は、コンパイル時に簡単な切り替えを行うことで、ISO 8859-1モード プログラム (8 ビット文字) またはUnicodeモード プログラムのいずれかを生成できます (他の多くの言語とは異なり、Unicode プログラムと非 Unicode プログラムの間にソースの違いはありません)。テキスト ファイルでは ASCII 上位互換のUTF-8形式が使用され、これらのファイルはプログラム内部の 8 ビットまたは 16 ビット文字との間で読み取られます (ISO 8859-1 の上位 128 文字は、8 ビット文字でエンコードされたプログラムでも、テキスト ファイルで UTF-8 形式との間で変換されます)。

maxint と同様に、Pascaline には maxchr があります。これは、文字セット内に存在する最大文字です (実際にはグラフィカルな表現がない場合があります)。char 型の範囲は 0..maxchr として定義されます。これは、「set of char」などの型を処理するための重要な追加機能であり、さまざまな文字セット オプション (ISO 8859-1 や Unicode など) を処理するときに役立ちます。

IP Pascal は、モジュールに対して独自のスタッキング コンセプトを使用します。各モジュールはメモリ内で積み重ねられ、一番下で実行されます。一番下のモジュールが次のモジュールを呼び出し、そのモジュールが次のモジュールを呼び出し、というように続きます。

ラッパー
セルリブ
プログラム
キャップ

キャップ モジュール (IP Pascal の用語では、集積回路設計の概念にちなんで「セル」と呼ばれることもあります) はスタックを終了し、プログラムが終了するまで下位に波及する戻りプロセスを開始します。各モジュールには、スタックを上る途中で実行されるスタートアップまたはエントリ セクションと、スタックを下る途中で実行されるファイナライズまたは終了セクションがあります。

これは、プログラム内の自然な依存関係と一致します。「serlib」の基本的な I/O サポートなどの最も基本的なモジュールは、スタック内の上位レベルのモジュールの前後で、最初に初期化を実行し、最後に終了処理を実行します。

IP Pascal には、Petit-Ami (フランス語で「小さな友達」) と呼ばれる「移植プラットフォーム」を形成する一連のモジュール (または「ライブラリ」) があります。これらのライブラリは、ファイルや拡張オペレーティング システム機能、グラフィックス、MIDI、サウンドなど、適用される各機能の理想的なAPI を提供します。コレクション全体が、IP Pascal が実行される各オペレーティング システムおよびマシンでの実装の基礎となります。

IP Pascal と、単にポータブル グラフィックス ライブラリと組み合わせた他の多くの言語との 2 つの重要な違いは次のとおりです。

1. IP Pascal は、独自の低レベル コードに独自の移植プラットフォームを使用するため、特定のオペレーティング システムとマシン用にプラットフォームが作成されると、IP システムとそれがコンパイルするプログラムの両方がその上で実行できます。これは、JavaやUCSD Pascalシステムの動作に似ていますが、解釈されたコードや「ジャスト イン タイム」コンパイルされたコードではなく、真に高度に最適化されたコンパイルされたコードです。
2. モジュールは Pascal の「write」ステートメントなどの低レベル関数をオーバーライドできるため、通常の変更されていない ISO 7185 Pascal プログラムでも、移植プラットフォームの高度な側面を使用できます。これは、C、その他の Pascal、Visual Basicなどのウィンドウ グラフィックス システムにアクセスするために、ユーザーにまったく異なる I/O 方法論の使用を強制する、多くの、またはほとんどのポータブル グラフィックス ライブラリとは異なります。

システムに依存しない、移植プラットフォーム モジュールのみに依存する IP モジュールも作成できます。その結果、IP Pascal は移植性が極めて高くなります。

例: 標準の「hello world」プログラムは、グラフィカル ウィンドウへの出力に結合されます。

プログラムHelloWorld(出力);
 begin
    writeln('Hello, World!')
終わり。

例: グラフィカル コマンドが追加された「hello world」。標準の Pascal 出力ステートメントが引き続き使用されることに注意してください。

 プログラムhello (入力、出力) ; gralibを使用します。var er : evtrec ; begin bcolor (出力、緑) ; curvis (出力、偽) ; auto (出力、偽) ; page (出力) ; fcolor (出力、赤) ; frect (出力、50、50 、maxxg (出力) - 50 、maxyg (出力) - 50 ) ; fcolorg (出力、maxint 、maxint - ( maxint div 3 ) 、maxint - maxint div 3 ) ; frect (出力、50、50、53 、maxyg (出力) - 50 ) ; frect (出力、50、50、53 、maxxg (出力) - 50、53 ) ;​​​​​​​fcolorg (出力, maxint div 2 , 0 , 0 ) ; frect (出力, 52 , maxyg (出力) - 53 , maxxg (出力) - 50 , maxyg (出力) - 50 ) ; frect (出力, maxxg (出力) - 53 , 52 , maxxg (出力) - 50 , maxyg  
  
   
 
     
     
     
    
     
        
           
        
        
         
        
        (出力) - 50 ) ; 
font (出力、font_sign ) ; fontsiz (出力、100 ) ; binvis (出力) ; fcolor (出力、シアン) ; cursorg (出力、maxxg (出力) div 2 - strsiz (出力、'hello, world' ) div 2 + 3 、maxyg (出力) div 2 - 100 div 2 + 3 ) ; writeln ( 'hello, world' ) ; fcolor (出力、青) ; cursorg (出力、maxxg (出力) div 2 - strsiz (出力、'hello, world' ) div 2 、maxyg (出力) div 2 - 100 div 2 ) ; writeln ( 'hello, world' ) ; erまでイベント(入力、er )を繰り返します。etype = etterm終了。     
     
    
     
          
                        
    
     
          
                        
    
          
  

IP Pascal モジュールは相互に「オーバーライド」できるため、グラフィカル拡張モジュール (またはその他のタイプのモジュール) は、その下のモジュールに実装されている標準 I/O 呼び出しをオーバーライドできます。したがって、paslib は読み取り、書き込み、およびその他のサポート サービスなどの標準 Pascal ステートメントを実装します。gralib はこれらのサービスをオーバーライドし、すべての標準 Pascal I/O をグラフィカル ウィンドウにリダイレクトします。

このライブラリと他の実装のライブラリとの違いは、通常は標準の I/O ステートメントの使用をやめて、まったく異なる一連の呼び出しとパラダイムに切り替える必要があることです。つまり、シリアル I/O パラダイムで実装されたプログラムをグラフィカル システムに「持ち込む」ことはできません。

IP Pascal とのもう 1 つの重要な違いは、手続き型言語メソッドを使用してウィンドウ グラフィックス ライブラリにアクセスすることです。ほとんどのグラフィックス ツールキットでは、ツールキットにオブジェクト指向プログラミングメソッドの使用が強制されます。その理由の 1 つは、オブジェクト指向プログラミングがグラフィックスに適しているためですが、Windows などの一般的なシステムでは、アプリケーション プログラムをオペレーティング システムへのサービス プログラムとして、つまりオペレーティング システムによって呼び出される関数のコレクションとして表示するように強制するためでもあります。プログラムが自身の実行を制御してオペレーティング システムを呼び出すのではなく、アプリケーション プログラムはオペレーティング システムへのサービス プログラムとして表示されます。これは、一般にコールバック設計と呼ばれます。オブジェクト指向コードは、多くの場合、コールバックでより適切に機能します。これは、オブジェクトのメソッドをコールバックとして呼び出すことができるため、プログラマがイベント処理コードへの関数へのポインタをいくつか登録する必要がなく、それぞれが個別のコールバックになるからです。

IP Pascal では、オブジェクト指向プログラミングは、プログラムを作成するための必須の方法ではなく、オプションの方法になります。IP Pascal では、すべてのグラフィックス機能にアクセスするために手続き型メソッドを使用できるため、古いプログラムに「クリフ効果」は発生しません。最新のプログラミング環境を利用するために、古いプログラムを書き直す必要はありません。

IP 移植プラットフォームは、ピクセル グリッドをオーバーレイする「文字グリッド」を提供することで、グラフィカル環境でも文字モードをサポートします。文字モード呼び出しのみを使用するプログラム (どの端末または Telnet 接続でも動作します) は、グラフィカル環境で自動的に動作します。

このコンパイラは 1980 年にMicropolisディスク オペレーティング システムで開始されましたが、すぐにZ80 で実行されるCP/Mに移行されました。元のシステムは Z80 アセンブリ言語でコーディングされ、 Z80の直接マシン コードを出力しました。これはリンカーのないシングル パス コンパイラで、コンパイラ内にシステム サポート ライブラリが組み込まれ、生成されたコードを再配置して実行可能なディスク ファイルに出力しました。

コンパイラが動作可能になった後、ほぼ 1980 年の新年に、コンパイラの付属アセンブラが Pascal で書かれ、その後リンカーが Z80 アセンブリ言語で書かれました。この奇妙な組み合わせは、計算により、64 KB に制限された Z80 ではリンカー テーブルが問題になることが判明したため、リンカーをできるだけ小さくする必要がありました。その後、これを使用して、コンパイラとリンカーの Z80 ソース コードを Micropolis アセンブラ (単一の出力バイナリを作成するリンカーレス アセンブラ) から新しいアセンブラ リンカー システムに移動しました。

その後、コンパイラはリンカー形式で出力するように改造され、サポート ライブラリは別のファイルに移動されてリンクされました。

1981 年、コンパイラは大幅に作り直され、レジスタ割り当て、ブールジャンプ、デッド コード、定数の折りたたみなどの最適化が追加されました。これにより、既存の Z80 コンパイラやほとんどの 8086 コンパイラよりもベンチマークで優れた Pascal 実装が作成されました。残念ながら、46 KB では使いにくく、数ページのソース コードしかコンパイルできず、テーブルがオーバーフローしました (これは、小さなアドレス プロセッサ上のほとんどの Pascal 実装で共通の問題でした)。システムが使用可能になったのは、主に、これらの小さなオブジェクト ファイルから大規模なシステムを構築できるようにコンパクトなリンカーを作成するという決定があったためです。

それにもかかわらず、オリジナルの IP Pascal 実装は、汎用コンパイラとして 1987 年まで実行されました。この段階では、IP Pascal は C のようなモジュール レイアウトでした。各ソース ファイルはユニットであり、「プログラム」モジュール、型、定数、変数、プロシージャ、または関数の組み合わせで構成されていました。これらは「フリー フォーマット」でした。プロシージャ、関数、型、定数、および変数は、任意のブロックの外側に任意の順序で配置できます。他のファイルのプロシージャ、関数、および変数は、「外部」宣言によって参照され、現在のファイルのプロシージャ、関数、および変数は「グローバル」として宣言されました。各ファイルはオブジェクト ファイルにコンパイルされ、その後リンクされました。オブジェクト ファイル間での型チェックはありませんでした。

元のコンパイラの一部として、デバイスに依存しない端末 I/O モジュールが作成され、任意のシリアル端末 ( Turbo Pascalの CRT ユニットに類似) を使用できるようになりました。これは現在も残っています。

1985 年に、コンパイラを Pascal で書き直す作業が開始されました。新しいコンパイラは中間パスを含む 2 パスで、最初のコンパイラに関連するメモリ問題を解決するように設計されました。コンパイラのフロント エンドは、中間コード生成機能なしで作成され、テストされました (解析のみ)。

1987 年、IP に使用されていた Z80 システムが 80386 IBM-PC に交換され、作業は中止されました。それ以降、いくつかの他の ISO 7185 標準コンパイラが使用され、最終的には 32 ビットDPMIエクステンダー ベースの実装である SVS Pascal コンパイラが使用されました。

1993 年までに、高品質の 32 ビット コードを生成する ISO 7185 互換コンパイラは消滅しつつありました。この時点で、Pascal の使用をやめるか、以前の IP Pascal プロジェクトを復活させて 80386 コンパイラとして近代化するかという選択肢がありました。この時点で、IBM-PC で使用できるのは Pascal パーサーとアセンブラ (Z80 用) だけでした。1993 年から 1994 年にかけて、アセンブラは 80386 を含む複数の CPU を対象とするようにモジュール化され、Z80 アセンブリ言語リンカーを置き換えるリンカーが作成され、中間コードを出力する Pascal コンパイラ フロントエンドが完成しました。最後に、システムを検証するために、中間コード シミュレータが Pascal で構築されました。

1994 年、シミュレーターは ISO 7185 IP Pascal「コア」言語を拡張し、動的配列などの機能を含めるために使用されました。

1995 年に、80386 マシン コードをターゲットとする「チェック エンコーダ」が作成され、出力オブジェクト ファイルを取得して Windows 用の「ポータブル実行可能」ファイルを作成するコンバータ プログラムが作成されました。システム サポート ライブラリは IP Pascal 用に作成されましたが、それ自体は IP Pascal でした。これは、後でライブラリをアセンブリまたは別の Pascal から IP Pascal に再コーディングする必要がないようにするための珍しい手順でしたが、80386 コード ジェネレータとライブラリの両方を一緒にデバッグする必要があるという問題がありました。

1996 年の初めに、Windows NT の当初のターゲットは Windows 95 に変更され、IP Pascal は Windows で 80386 コンパイラとして完全に動作できるようになりました。システムは自動的にブートストラップされ、残りの Pascal コードは SVS Pascal から IP Pascal に移植されてブートストラップが完了しました。このプロセスは、DPMIベースの SVS Pascal が Windows 95 で実行できることによって大幅に促進され、DOS と Windows 95 の間でブートする必要がなくなりました。

2000 年には、テキスト モード専用のLinux (Red Hat) バージョンが作成されました。この実装では、システム コールを直接使用し、 glibcの使用を回避するため、バイナリの移植性が犠牲になりますが、C に必要な完全なサポート システムを使用する場合よりも薄いバイナリが作成されます。

計画としては、termcap 情報を使用するテキスト ライブラリのバージョンと、X11 でのグラフィカル ライブラリを作成することです。

1997 年、1980 年のオリジナルの IP Pascal の端末ライブラリのバージョンが Windows に移植され、80386 用の最終的なエンコーダの開発が開始されました。しかし、改善されたエンコーダを必要とする主な理由である実行速度は、IBM-PC のプロセッサ速度の向上によってほとんど無関係になりました。その結果、新しいエンコーダは 2003 年まで完成しませんでした。

2001 年に、C ヘッダー ファイルを Pascal ヘッダー ファイルに変換する IP Pascal の付属プログラムが作成されました。これは、IP Pascal 用のオペレーティング システム インターフェイスを手動で作成する方法に代わるものでした。

2003 年に、IP Pascal 用に完全にグラフィカルでオペレーティング システムに依存しないモジュールが作成されました。

2005 年には、Windows 管理およびウィジェット キットが追加されました。

2015 年頃、IP Pascal の言語仕様が収集され、拡張されました。その結果、「Pascaline」と呼ばれる言語が生まれました。IP Pascal には、Pascaline 仕様の多くが実装されました。しかし、まず言語の大部分を Pascal-P6 コンパイラ コードベースで構築するという決定が下されました。Pascal-P シリーズは、ETH Zurich の Wirth の学生によって開発されたオリジナルのコンパイラで、現在は Pascal-P4 (Niklaus Wirth が選んだ名前) として存在しています。Pascal-P5 では ISO 7185 Pascal に変換され、Pascal-P6 では Pascaline 言語にアップグレードされています。同時に、Pascal-P6 は、AMD64 プロセッサ モデルのコード生成から始めて、ARM や RISC-V などの他のプロセッサに拡張することを目指して、完全なコンパイラとして調整されています。目標は、Pascaline 仕様が完全に実装されたときに Pascal-P6 1.0 に到達することです。

2019 年頃、IP Pascal のサポート ライブラリが C で再コーディングされました。これには 2 つの目的がありました。1 つ目は、ライブラリを Pascal だけでなくすべての言語で使用できるようにすること、2 つ目は、新しいプラットフォームでのコーディングとデバッグをより簡単かつ迅速にすることです。現在、Petit-Ami は Windows、Linux で利用でき、Mac OS と BSD Unix で部分的に実装されています。

振り返ってみると、Z80 バージョンの最大のエラーはシングル パス構造でした。これには特に理由はありませんでした。著者の以前の (Basic) コンパイラは中間ストレージを備えたマルチ パスでした。唯一の理由は、シングル パス コンパイルの方が高速であるはずだったことです。しかし、シングル パス コンパイルは小型マシンには適していないことが判明し、大型マシンで一般的な高度な最適化には役立ちそうにありません。

さらに、シングル パスという側面により、コンパイラを Z80 アセンブリ言語から Pascal 自体にブートストラップするのに時間がかかったり、妨げられたりしました。コンパイラはモノリシックであったため、Pascal への変換は一度に 1 セクションずつ行うことはできず、全面的な置き換えとして進める必要がありました。置き換えが開始されると、プロジェクトはマシンよりも長く続きました。2 パス コンパイルが I80386 実装に与えた最大のメリットは、コンパイラのフロント エンドとバック エンドの間で通信する中間命令の標準ブックの保守でした。このよく理解されたコンパイルの「段階」により、全体的な複雑さが軽減されました。直感的に、同じサイズの 2 つのプログラムが密接に組み合わされると、複雑さは加算的ではなく乗算的になります。これは、プログラムの半分間の接続が制御不能に増加するためです。

Z80 時代のもう 1 つの教訓は、80386 コンパイラで修正されたものです。それは、サポート ライブラリも含めて、できるだけ多くのコードを Pascal 自体に書き込むことでした。80386 サポート コードをすべて Pascal で書き込むことで、コードは非常にモジュール化され、移植性が高くなり、その大部分がオペレーティング システム固有の領域から「共通コード」ライブラリ セクションに移動されました。このセクションは、マシンやオペレーティング システムごとに変更されないコード用に予約されています。「システム固有の」コードでさえ、実装ごとにわずかな変更しか必要ありません。その結果、システムを移植する際に、実装作業が大幅に削減されます。

最後に、コンパイラをブートストラップする前に 2 回目の最適化に入るのは間違いでした。出力コードはかなり強化されましたが、その結果コンパイラの複雑さが増し、アドレス空間が限られているという問題が発生しました。当時は、より最適化されたコードが Pascal でのコードのブートストラップを可能にすると考えられていました。振り返ってみると、残りのアセンブリ記述セクションが問題であり、早ければ早いほど良いため、削除する必要がありました。別の言い方をすると、スペースの問題は一時的なものかもしれませんが、アセンブリで記述されたプログラムの重要なセクションがあることは深刻で永続的な問題です。

• Kathleen Jansen とNiklaus Wirth : PASCAL – ユーザー マニュアルとレポート。 Springer-Verlag、1974、1985、1991、ISBN  0-387-97649-3、ISBN 0-387-90144-2、およびISBN 3-540-90144-2 ^[1]  
• ニクラウス・ヴィルト：「プログラミング言語 Pascal」。Acta Informatica、1、（1971 年 6 月）35～63 ページ
• ISO/IEC 7185:プログラミング言語 - PASCAL [ ^2]

• 公式サイト
• 標準規格 ISO 7185 Pascal ウェブサイト
• Pascal-P6 メインリポジトリ
• Pascal-P6 ミラーリポジトリ