ＥＣＯでのシミュレータ＆ゼネレータの開発の流れは以下のようになる。

シミュレータ：
　　その動きや値が正しいかをＣ＋＋のみで試す。

ゼネレータ：
　　最終目的であるアセンブラコードをゼネレートする。

//////////////////////////////////////////////////////////////////////////////////
シミュレータ用のクラスを書く（※１）＜＝フィードバック

ゼネレータ用のクラスを書く（※２）＜＝フィードバック

ソースを書く（※３）＜＝フィードバック
　　↓
シミュレータでビルド
　　↓
試す

ソースを書く（※３に同じ）
　　↓
ゼネレータ用のビルド
　　↓
アセンブラコードをゼネレート
　　↓
アセンブラによるビルド
　　↓
試す

//////////////////////////////////////////////////////////////////////////////////
以下、関連する開発の場面場面をリストアップ

■シミュレータ不要の場合
　シミュレータ要らないならば、灰色部分は割愛できる。

■当初の開発
最初のうち、フィードバック、変更は※１、※２、※３の部分に入る。

■終盤の開発
※１、※２ができあがってくると、※３のソースだけ＝上位のアルゴリズムだけを吟味できる。

■別開発へ
　※１、※２は似た他のルーチンを書くときに流用できる。

■プラットフォームが変わった場合
　※１、※３残しで、※２のジェネレータ部分だけ書き足せばよい。
（場合によっては※１、※３にも修正を加える）

//////////////////////////////////////////////////////////////////////////////////

ECOの利点は何かというと特に上のピンク色の部分

プラットフォームが変わったときに、上位の論理的な部分（※３）に影響することなく、※２の用意に集中すればよいということ。

また、プラットフォームが変わらないとしても、その上位の論理的な部分と下位のアセンブラへの落とし部分の分離は
安定した開発ができることにつながる。