GSoC 2011 Proposal: Bytecode Emitters for POST

Vasily Chekalkin bacek at
Sun Apr 3 09:41:14 UTC 2011


Actually, there is next good proposal for emitting PBC from POST -
make PAST emit "newPOST" and finally glue everyting together. In the
perfect world - including PIRATE for parsing <inline> nodes on fly.


On Sun, Apr 3, 2011 at 6:28 PM, Jonathan "Duke" Leto <jonathan at> wrote:
> Howdy,
> Don't let this discourage you. I still highly recommend that you
> submit another proposal idea.
> Duke
> On Sun, Apr 3, 2011 at 12:11 AM, Vasily Chekalkin <bacek at> wrote:
>> Hello.
>> 1. It's really good plan.
>> 2. Unfortunatelly all of this is already implemented (mostly) in
>> PIRATE (parsing and emitting newPOST for PIR)  and pct_pbc branch (for
>> "library to emit PBC from POST directly").
>> --
>> Bacek
>> On Sun, Apr 3, 2011 at 6:48 AM, Brian Gernhardt
>> <benji at> wrote:
>>> The following text is also online at and further revisions will updated there.  Comments are welcome via e-mail, gist comments, or IRC.
>>> --------------------
>>> **Name:** Brian Gernhardt
>>> **E-Mail:** benji at
>>> **IRC:** benabik on,
>>> Bytecode Emitters for POST
>>> ==========================
>>> Abstract
>>> --------
>>> Create an extension to PCT that generates bytecode directly from POST.
>>> Benefits to the Parrot VM and Open Source Community
>>> ---------------------------------------------------
>>> While initially this project would make little difference in the day to day
>>> usage of Parrot, it should provide a minor speed improvement and lay the
>>> groundwork for further projects.  With direct bytecode generation, parrot
>>> does not have to spend time parsing PIR that was generated by a language
>>> using PCT.  Removing the PIR dependency from PCT also means that PIR could
>>> be removed from parrot or even implemented using PCT.
>>> Deliverables
>>> ------------
>>> The main deliverable would be a library that can convert POST trees to
>>> Parrot bytecode.  This library should have an interface similar (but not
>>> identical to) the existing POST::Compiler and will walk the POST tree and
>>> use the Packfile and related PMCs to generate a PBC file.
>>> Along side this library should be both technical and user documentation.
>>> The technical documentation will be written as POD comments among the code
>>> describing both the API and the algorithms involved in detail.  The user
>>> documentation should be a step by step guide for HLL languages to use the
>>> library.
>>> In addition, a test suite needs to be written to ensure that the library
>>> performs as required.  The principles of Test-Driven Development will be
>>> used so that the test suite is constantly up to date with the current
>>> status of the project.
>>> Project Details
>>> ---------------
>>> The bytecode generator should be implemented as an external library that
>>> takes in a POST tree and outputs a PBC file.  This should be possible
>>> without any alterations to the parrot source, since any changes can be
>>> handled either by subclassing or creating custom PMCs.  The library itself
>>> will be written in Winxed as it provides a good balance between power and
>>> ease of use.  For testing, Rosella will be used for similar reasons.
>>> This project will borrow heavily on the design of POST::Compiler and IMCC,
>>> as to some extent it will need to perform tasks done by both.  It needs to
>>> walk the tree and perform similar translations tasks as POST::Compiler, but
>>> instead of outputting text it will need to translate the opcode names to
>>> raw binary as IMCC does.  If simple tree traversal is insufficient, then
>>> the tree-optimization library will provide more complex pattern matching.
>>> The week prior to each evaluation will be dedicated to bugfixes and other
>>> issues.  This extra time should help to both produce a high quality result
>>> and absorb any excess time caused by unforeseen issues.  Also, while this
>>> proposal describes the project as an external library the intention is
>>> that the code could be integrated into the main PCT library under
>>> `compilers/pct`.  A week at the very end of GSoC will be allocated to code
>>> cleanup to address any issues that could prevent such a merge.
>>> There is one major gap in this proposal: `POST::Op` nodes of type `inline`.
>>> Unfortunately, completely implementing such nodes requires a full PIR
>>> parser.  Such handling is outside the scope of this project, but all such
>>> nodes should route through a single place in the code for easy extension.
>>> Project Schedule
>>> ----------------
>>> This schedule is written in terms of milestones, so the work listed on each
>>> date will be done in the week(s) prior.
>>> **May 16**: My course-load for this quarter is heavy, but I intend to
>>> spend as much time as possible on IRC and reading existing sources and
>>> documentation.  If time allows, I will create at least the skeleton of the
>>> library with the outline of code, tests and documentation.
>>> **May 16 - 20**: Finals week at RIT.  No GSoC work is likely during this
>>> time.
>>> **May 24** _GSoC Start Date_
>>> **May 30** _Basic Library Structure_:  Functional build and test system.
>>> Documentation describing the main API of the library should be included.
>>> **June 6** _Empty Output_: Library can accept a (TBD) minimal POST tree and
>>> output a PBC file that can be loaded and run but performs no real work.
>>> **June 13** _Opcode Handling_: The framework to handle processing `POST::Op`
>>> nodes will be in place, although it will only handle a small set of opcodes
>>> such as "add" and "say".
>>> **June 20** _Constant Loading_: The ability to load arbitrary constants into
>>> the constants segment will be implemented.
>>> **June 27** _Opcode Lookup_: Full access to core Parrot opcodes via the
>>> information available in the OpLib PMC.
>>> **July 4** _Label Handling_: Populate the Fixup segment and arrange for it to
>>> be used whenever labels are needed.
>>> **July 11** _Midterm Evaluation_: Bugfixes.  At this point the library
>>> should be able to compile simple programs that lack subroutines.
>>> **July 18** _Basic Subroutines_: Basic handling of `POST::Sub` nodes,
>>> including subroutine names and simple parameters.
>>> **July 25** _Subroutine Attributes_: Handling of subroutine attributes such
>>> as name, init, method, etc.
>>> **August 1** _Parameter Attributes_: Handling of :slurpy, :named, optional,
>>> etc.
>>> **August 6** _Dynops_: Handle loading dynamic opcode libraries and parsing
>>> their opcodes.
>>> **August 16** _Suggested 'Pencils down'_: Bugfixes
>>> **August 22** _Final 'Pencils down', evaluation_: Cleanup for possible merge
>>> to parrot.git
>>> References and Likely Mentors
>>> -----------------------------
>>> Trac listed cotto and bacek as possible mentors for this project, but I
>>> have not personally spoken to them about it.
>>> * [PDD 13: Bytecode](
>>> * POST (parrot.git:compilers/pct/src/POST/)
>>> * IMCC (parrot.git:compilers/imcc/)
>>> * [tree-optimization](
>>> * [pir compiler using PCT](
>>> * [packfile.winxed](
>>> License
>>> -------
>>> I whole-heartedly support open source licenses and will be more than happy to
>>> use the Artistic 2.0 license suggested by Parrot.
>>> Bio
>>> ---
>>> My name is Brian C Gernhardt and I'm currently attending the Rochester
>>> Institute of Technology to obtain my Masters in Computer Science.  I did
>>> contracting for 4 years after getting my bachelor's degree (in CS from
>>> RIT).  My current focus has been language design, and I just completed a
>>> project where I implemented a [compiler on the JVM][rit-cs].
>>> [rit-cs]: (My RIT webpage)
>>> I've been following Parrot for a couple years due to my interest in Perl 6
>>> and Rakudo.  I try to regularly produce smoke reports, which has already
>>> resulted in a couple of Trac tickets (#1544 & #2001).  For my compiler
>>> class, I wrote an [introduction to the Parrot Compiler Toolkit][cish].
>>> I've also worked on other open source projects.  I've worked the most on
>>> git but have also worked on Ruby on Rails, Radiant and fink.
>>> [cish]: (PCT Introduction)
>>> I've also been interested in a bytecode generator since I read the entry
>>> for it in the Parrot glossary:
>>>> **bcg**
>>>> Bytecode Generation: bcg will be part of the Parrot Compiler tools. It will
>>>> aid in converting POST to bytecode.
>>> Since my initials and the initials of the library match, I thought it would
>>> be an appropriate section of Parrot for me to work on.
>>> Eligibility
>>> -----------
>>> I am 29 and currently attending the Rochester Institute of Technology to obtain
>>> my Master's in Computer Science.  I have completed a quarter of graduate
>>> classes and can produce a transcript to prove such.
>>> _______________________________________________
>> _______________________________________________
> --
> Jonathan "Duke" Leto
> jonathan at

More information about the parrot-dev mailing list