HTTP/1.1 -1 Read error in cache disk data: SuccessContent-Type: text/plain; charset="utf-8" Last-Modified: Sat, 22 Jan 2022 07:05:43 GMT Content-length: 3082 Connection: Close Proxy-Connection: Close X-Cache: HIT from web1.osuosl.org Server: ProxyTrack 0.5 (HTTrack 3.49.2) There is a lack of clarity about the path that we plan on taking to implement and use Lorito. This page exists as a roadmap to document what we Parrot developers plan on doing with Lorito and how we expect to get there. I'm dividing the road to Lorito into several stages. Most of the tasks during a given stage can happen independently, making it easy to parallelize. == Stage 0: Preparation == === ~~opsc (C mangling)~~ === * ~~Implement an nqp-based ops compiler ("opsc") capable of generating C code equivalent to what the perl-based ops2c generates.~~ * ~~Check the generated C code for ops into version control to allow bootstrapping and reduce the need for rebuilding ops.~~ === Lorito Design === * Define Lorito ops and semantics (ffi, arg format, binary format, registers, ops, syscalls, text format, etc). * Implement some PMCs, ops and library bindings in Lorito to demonstrate that Lorito is sufficiently powerful. Because Lorito is not intended to be written directly, this stage may involve some annoyance on the part of the implementors. * Identify and deal with blockers to implementing core PMCs and systems in Lorito. * Get a rough idea of how PIR -> Lorito translation will work. The same goes for Lorito -> C code and Lorito -> C functions. == Stage 1: Prototype == === Lorito Prototype === * Implement Lorito as PIR dynops, allowing them to be processed by the imcc and other existing tools. * Modify nqp-based compilers to emit Lorito dynops. Once these are usable, start running them. * Figure out how to make user-defined ops (i.e. ops defined in Lorito) work. * Define PIR -> Lorito translation. * Define Lorito -> C code translation (this is a JIT, among other things) * Define Lorito -> C function translation (similar to the current function-based runcore). === opsc (full HLLs) === * Make opsc able to process HLLs and spit out Lorito ops. Implement some ops in terms of a HLL. [ANR: by "HLLs" you don't mean Perl/Python, but the mini-language that compiles down to Lorito ops?] === Lorito PMCs === * Start implementing core PMCs in something that compiles to Lorito. == Stage 2: Implement and Bootstrap == === Pervasive Lorito === * Modify the current PIR compiler to emit Lorito. * Implement core PIR ops in Lorito. * Change the PBC to be Lorito-based instead of PIR-based. [ANR: this will hugely bloat our bytecode, a higher-level of abstraction has advantages here] * Make the final switch. All ops and PMCs get compiled into L1 during the normal build process (possibly using a bootstrapping step). == Stage 3: Convert and Optimize == === Core Functionality Implemented in Lorito === * Start rewriting core systems in Lorito (strings, mmd, packfiles, pcc, whatever's feasible). * When you see a bottleneck, kill it. === Lorito Translations === * Implement translation from Lorito to LLVM IR, libjit, GNU Lightning, LOLCODE, etc. Lorito to C will be the default fallback. * Work in earnest on Lorito-level optimizations. == See also == * [wiki:Lorito]gian SSR). The SSR Abkhazia was largely similar to