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 <[email protected]> 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 <[email protected]> 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 >> <[email protected]> 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:** [email protected] >>> **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 > [email protected] > http://leto.net > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
