Posts in RPython
Before implementing an RPython backend, a short study of RPython is made, including implementing The Sieve demo (start/DRAFT) in RPython. It’s like a hand-compiled RPython variant, following the approach as described in the Jinja rendering study), for the CC2CPy backend.
Writing RPython isn’t too complicated for someone with a C-background. But making the code pass the RPython compiler
can be tricky, however. Both, as just added statements can interfere with existing code – when that isn’t “static
enough”, new code can trigger compile errors in old, tested code! And, because the RPython compiler isn’t that great
in giving helpful info.
It feels like old-style debugging: try-and-error, remove-and-enable-lines, one-at-a-time until one understands and it becomes easy to fix…
This blog is both to share some RPython experience and to study the patterns that are needed to generate RPython code to implement the Castle-Compiler.
When designing a Castle-Compiler with a C-backend, we found some nasty details unrelated to CCastle
but to the C-language. For example, C has no namespaces (see No Name Collisions); we can simulate them, but
that is extra work. Likewise, we need to generate many (data)classes that are very similar. Again, it is
possible, but it takes a lot of work: to write the code that generates those almost codes.
Therefore, I started to think about how we can automate that. Or: who has done it before, and what can we borrow?
PyPy –an alternative Python implementation– has developed a concept for
that! They have built a translator to convert (r)Python into C and
compile that into native machine code.
Can we re-use that? And can it help to realize the “first (bootstrap) compiler” faster?