PyPyの翻訳プロセスは、実際には、思ったよりも概念的に再帰的ではありません。
実際には、Python関数/クラス/その他のオブジェクト（ Pythonソースコードではない）を処理し、Cコードを出力するPythonプログラムだけです。ただし、もちろん、 Pythonオブジェクトだけを処理するわけではありません。特定のフォームのみを処理できます。これは、変換対象のコードをRPythonで記述した場合に得られるものです。
翻訳ツールチェーンはPythonプログラムであるため、PyPyのPythonインタープリターを含む任意のPythonインタープリター上で実行できます。だからそれは特別なことではありません。
RPythonオブジェクトを変換するため、RPythonで記述されたPyPyのpythonインタープリターを変換するために使用できます。
ただし、 RPythonではない翻訳フレームワーク自体で実行することはできません。PyPyのPythonインタープリター自体だけがRPythonです。
RPythonコードもPythonコード（逆ではない）であり、RPythonがソースファイルに「実際に存在する」ことはなく、他の非RPythonコードを必然的に含む動作中のPythonプロセス内のメモリにのみ存在するため、物事は興味深いものになります。 （たとえば、トランスレータはすでに定義およびインポートされた関数を操作するため、「純粋なRPython」のインポートや関数定義はありません）。
翻訳ツールチェーンは、メモリ内のPythonコードオブジェクトで動作することに注意してください。Pythonの実行モデルは、一部のPythonコードが実行される前にこれらが存在しないことを意味します。非常に単純化すると、翻訳プロセスの開始は次のようになります。
from my_interpreter import main
from pypy import translate
translate(main)
ご存知のとおり、インポートするだけでmain、他のすべてのモジュールのインポートを含め、多くのPythonコードが実行されますmy_interpreter。しかし、変換プロセスは関数オブジェクト mainの分析を開始します; を思い付くために実行されたコードが何であれ、それは決して認識せず、気にしませんmain。
これを考える1つの方法は、「RPythonでのプログラミング」とは、「RPythonプログラムを生成し、それを翻訳プロセスにフィードするPythonプログラムを作成する」ことを意味します。これは比較的理解しやすく、他のコンパイラの数と似ています（たとえば、Cでのプログラミングを考える1つの方法は、Cプログラムを生成するCプリプロセッサプログラムを作成し、それをCコンパイラ）。
3つのコンポーネント（RPythonプログラムを生成するPythonプログラム、RPythonプログラム、および変換プロセス）がすべて同じPythonインタープリターにロードされるため、PyPyの場合は混乱するだけです。つまり、他の引数で呼び出されたときではなく、いくつかの引数で呼び出されたときにRPythonである関数を使用したり、RPythonプログラムの生成の一部として翻訳フレームワークからヘルパー関数を呼び出したり、その他多くの奇妙なことを行うことができます。そのため、状況はかなりぼやけており、ソース行を「翻訳するRPython」、「PythonがRPythonプログラムを生成する」、「RPythonプログラムを翻訳フレームワークに渡す」に必ずしもきれいに分割できるとは限りません。
CPython上で実行されるPyPyインタープリターは、それ自体を部分的に解釈するために実行されます
ここでほのめかしているのは、PyPyが翻訳中にフローオブジェクトスペースを使用して抽象解釈を行うことです。これでさえ、最初に思われるほどクレイジーで気が遠くなるようなものではありません。私はPyPyのこの部分についてあまり知らされていませんが、私が理解しているように：
PyPyは、Pythonインタープリターのすべての操作を、すべての基本的な組み込み操作の実装を含む「オブジェクトスペース」に委任することによって実装します。ただし、さまざまなオブジェクトスペースをプラグインしてさまざまな効果を得ることができ、それらが同じ「オブジェクトスペース」インターフェイスを実装している限り、インタープリターはPythonコードを「実行」できます。
PyPy変換ツールチェーンが処理するRPythonコードオブジェクトは、インタープリターによって実行される可能性のあるPythonコードです。そのため、PyPyは、フローオブジェクトスペースをプラグインすることにより、Pythonインタープリターの一部を翻訳ツールチェーンの一部として再利用します。このオブジェクトスペースを使用してコードを「実行」する場合、インタープリターは実際にはコードの操作を実行せず、代わりにフローグラフを生成します。これは、他の多くのコンパイラーで使用される一種の中間表現に類似しています。これは、コードを機械で操作できる単純な表現であり、さらに処理する必要があります。これは、通常の（R）Pythonコードオブジェクトが残りの翻訳プロセスの入力に変換される方法です。
変換プロセスで変換される通常のものはPyPyのPythonインタープリターであるため、実際にはフローオブジェクトスペースで「それ自体を解釈」します。しかし、実際に意味するのは、処理を実行する関数を含め、Python関数を処理するPythonプログラムがあるということです。それ自体は、デコレータをそれ自体に適用したり、ラッパークラスにそれ自体のインスタンスをラップさせたり（またはクラス自体をラップさせたり）することほど気が遠くなることはありません。
ええと、それは少しぼんやりしました。とにかく、それがお役に立てば幸いです。不正確なことは何も言っていないことを願っています。もしあれば訂正してください。
免責事項：私はPyPyの専門家ではありません。特に、RPythonの翻訳の詳細を理解していません。私は、以前に読んだものだけを引用しています。RPython変換がどのように機能するかについてのより具体的な投稿については、この回答を確認してください。
答えは、はい、できます（ただし、CPythonを使用して最初にコンパイルされた後でのみ）。
長い説明：
一見、曲がりくねって逆説的だと思いますが、一度理解すれば簡単です。ウィキペディアで答えをチェックしてください。
プログラム開発のブートストラップは、1950年代に、各プログラムが10進数コードまたはバイナリコードで少しずつ（1と0）紙に作成されたときに始まりました。これは、高レベルのコンピューター言語、コンパイラ、アセンブラ、およびリンカ。小さなアセンブラープログラムが新しいコンピューター（IBM 650など）用に手動でコーディングされ、いくつかの命令が2進または10進コードに変換されました：A1。次に、この単純なアセンブラプログラムは、定義されたばかりのアセンブリ言語で書き直されましたが、より複雑な操作コードにいくつかの追加のニーモニックを使用できるようにする拡張機能があります。
このプロセスは、ソフトウェアブートストラップと呼ばれます。基本的には、すでに作成されている低言語で1つのツール（C ++コンパイラなど）を構築します（ある時点ではすべてをバイナリからコーディングする必要がありました）。たとえば、ASMです。C ++が存在するので、C++コンパイラをC++でコーディングし、ASMC++コンパイラを使用して新しいコンパイラをコンパイルできます。新しいコンパイラをコンパイルしたら、それを使用して自分自身をコンパイルできます。
つまり、基本的には、手作業でコーディングして最初のコンピューターツールを作成し、そのインタープリターを使用して別の少し優れたツールを作成し、そのインタープリターを使用してより優れたツールを作成します。:)
もう1つの興味深いケースは、CoffeeScript言語です。これは...CoffeeScriptで記述されています。（ただし、このユースケースでは、外部インタープリター、つまりNode.jsを使用する必要があります）
CPython上で実行されるPyPyインタープリターは、それ自体を部分的に解釈するために実行され、その時点で、変換を実行するRPythonの半分に制御を渡しますか？
コンパイル済みのPyPyインタープリターを使用してPyPyをコンパイルするか、代わりにCPythonを使用してコンパイルすることができます。ただし、PyPyには現在JITがあるため、CPythonではなくそれ自体を使用してPyPyをコンパイルする方が高速です。（ほとんどの場合、PyPyはCPythonよりも高速になりました）