GSoC 2011 Proposal: Bytecode Emitters for POST

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


Hello.

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.

-- 
Bacek

On Sun, Apr 3, 2011 at 6:28 PM, Jonathan "Duke" Leto <jonathan at leto.net> 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 bacek.com> 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 silverinsanity.com> wrote:
>>> The following text is also online at https://gist.github.com/899867 and further revisions will updated there.  Comments are welcome via e-mail, gist comments, or IRC.
>>>
>>> --------------------
>>>
>>> **Name:** Brian Gernhardt
>>>
>>> **E-Mail:** benji at silverinsanity.com
>>> **IRC:** benabik on irc.perl.org, irc.freenode.net
>>>
>>> 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](http://docs.parrot.org/parrot/latest/html/docs/pdds/draft/pdd13_bytecode.pod.html)
>>> * POST (parrot.git:compilers/pct/src/POST/)
>>> * IMCC (parrot.git:compilers/imcc/)
>>> * [tree-optimization](https://github.com/parrot/tree-optimization)
>>> * [pir compiler using PCT](https://github.com/parrot/pir)
>>> * [packfile.winxed](http://code.google.com/p/winxed/source/browse/trunk/examples/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]: http://cs.rit.edu/~bcg2784/ (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]: http://github.com/benabik/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.
>>>
>>> _______________________________________________
>>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>>
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
>
>
>
> --
> Jonathan "Duke" Leto
> jonathan at leto.net
> http://leto.net
>


More information about the parrot-dev mailing list