A Proposal: The Parrot Virtual Machine Specification
Abstract: This document, briefly, sets out a proposal for the Parrot Development
Team's adoption of a Parrot Virtual Machine Specification.
The purpose of a virtual machine specification [hereinafter VM Spec] is to
document, clearly, the design of a virtual machine. The goals of a VM Spec --
that is, the things at which it aims -- are two-fold: (1) to serve as a
reference document for compiler writers, who wish to target the virtual machine,
and (2) to serve as the definitive source of documentation on the implementation
of a virtual machine [hereinafter vm]. It is with this purpose and these
twin-objectives in mind that I am propose the adoption of a Parrot Virtual
Machine Specification [hereinafter PVM Spec].
Unfortunately, in and of themselves, specifications tend towards the
abstract,[1] often failing to provide important particulars, for example,
concrete code examples sufficient to enable a compiler writer to accomplish his
or her aim.[2] I propose to correct this liability with the inclusion of
something akin to an implementation reference of Parrot.[3] Specifically, I
envision the inclusion of concrete code examples throughout the VM Spec. For
example, where the PVM Spec addresses the structure of Parrot, it will also
include relevant snippets of 'C' code to elucidate the material at-hand and,
where it covers how to load parrot bytecode, it will include specific code
examples, in the 'Winxed Programming Language,'[4] on how to accomplish this
feat.
In an effort to provide some detail, I propose the following tentative
organization of the PVM Spec:[5]
Preface
Table of Contents
Chapter 1: Introduction
Chapter 2: The Winxed Programming Language Concepts
Chapter 3: The Structure of the Parrot Virtual Machine
Chapter 4: The bytecode File Format
Chapter 5: Loading, Linking, and Initializing
Chapter 6: The Parrot Virtual Machine Instruction Set
Chapter 7: Compiling for the Parrot Virtual Machine
Chapter 8: The Memory Internals
Chapter 9: The Parrot Virtual Machine Threading System
Chapter 10: Opcode Mnemonics by Opcode
Appendix A: The NQP (Not Quite Perl) Programming Language
Appendix B: The Parrot Intermediate Representation Language
Glossary
Bibliography
Index[6]
Other than as an effort to bring a certain clarity to Parrot's
documentation,[7] there is one other, sensible rationale for adopting a
specification: Industry standards and practices. That is to say, it is now a
well-established, industry practice for a premier vm to include a specification
among its documentation set. And, while it is certainly true, much of Parrot is
still in active development, much of this development will take place,
"under-the-hood," so-to-speak. Most, if not all, of the user visible features
are, I think, sufficiently stable.[8] Sufficient, I believe, to allow for the
writing of a PVM Spec.
Finally, other than its lack of stability, I can think of only one, major
objection to the adoption of a PVM Spec[9]: Parrot Design Documents
[hereinafter PDDs].[10] Parrot's PDDs have, for good and occasionally for
ill,[11] well-served the Parrot community over the past (almost) decade. But a
PVM Spec is not, necessarily, at variance with the PDDs. A PVM Spec does not
necessarily need to displace or to supplant the PDDs;[12] instead, we merely
add a
PVM Spec, while, at the same time, continue to maintain and to enrich the PDDs.
In sum, there is room and reason for both.
In closing, please let me take a moment to say, "thank you," both for your time
and for your attention to this matter. I look forward to your comments and your
criticisms.
Alvis
---------------
[1] See, e.g., Tim Lindholm & Frank Yellin, "The Java Virtual Machine
Specification" (2d ed. 1999) at
http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html.
[2] The consequence of which is, a compiler writer is forced to learn (or even
to discover) all manner of things -- in which, on-the-whole, they are
uninterested -- in order to accomplish their aim, that is, writing a compiler
for a particular target.
[3] I think it necessary to emphasize one, important qualification: This
proposal is limited in scope to a documentation project. That is to say,
nothing in this proposal should be construed as suggesting a PVM should somehow
drive the development of or dictate to the "core" development team how to best
implement any aspect of Parrot. That is exclusively the purview of the "core"
development team.
[4] Or 'NQP' or 'PIR', as the case may be.
[5] Please note: I, for one, am NOT wedded to this organization. And I am very
interested in reading any countervailing viewpoints about how best to organize
or to present the material in the PVM Spec.
[6] The format of the PVM Spec will, of course, be in multiple POD files,
something like,
preface.pod
acknowledgments.pod
toc.pod
ch01_introduction.pod
ch02_winxed_programming_language.pod
ch03_structure_of_PVM.pod
ch04_parrot_bytecode_format.pod
ch05_loading_linking_initializing.pod
ch06_PVM_instruction_set.pod
ch07_compiling_for_PVM.pod
ch08_memory_internals.pod
ch09_thread_system.pod
ch10_opcode_mnemonics_by_opcode.pod
appa_nqp_programming_language.pod
appb_PIR_language.pod
bibliography.pod
glossary.pod
index.pod
Which we can readily convert into html or pdf (or any other relevant formats).
[7] See infra text accompanying footnote 2.
[8] See, e.g., Andrew Whitworth Advent 1 - Parrot at
http://planet.parrotcode.org/ (entry for December 10, 2011).
Please note: The above is just *my* best assessment given my current state
of understanding of the Parrot's future development. 'course, I could be
wrong.
[9] Other than the rather substantial commitment of time and of effort, of
course.
[10] In short, we don't need no stinking vm specification. We got PDDs! This
was an objection -- along with the lack of stability and the uncertainty of the
direction Parrot's design was likely to take -- when the Parrot project first
"kicked off," so-to-speak. At the time, Larry's Apocalypses, along with the
opinion of a majority of the Perl5porters, held a great deal of sway over the
original design goals of Parrot. This, in conjunction with a general disdain
both Java and for the JVM, militated against the adoption of a PVM Spec in favor
of PDDs.
[11] For example, even now, nine and one-half years later, fully one-third of
the PDDs are still in draft form. Not to mention the rather blatant
contradictions between the PDDS and the actual implementation or the lack
thereof. Compare, e.g., 'docs/parrotbyte.pod' and
'docs/pdds/draft/pdd13_bytecode.pod' and 'docs/pdds/draft/pdd31_hll.pod' and the
lack of HLL-interoperability in Parrot.
Please note: Neither of these are negative criticisms, especially on this
later point. HLL-interoperability is clearly a hard problem; it is one of
the primary drivers of m0.
[12] Though, of course, it may. Regardless, this is a question best left for
another day, *after* the completion of a PVM.
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
