Parrot in a Nutshell. Dan Sugalski Parrot in a nutshell 1

(1)

Parrot in a Nutshell

Dan Sugalski

(2)

What is Parrot

•

The interpreter for perl 6

•

A multi-language virtual machine

(3)

The official point of Parrot

• _{Build something to support perl 6} • _{Build a faster perl}

(4)

The Unofficial point of Parrot

• _{Generic fast interpreter engine} • _{Annoy the Mono folks}

• _{Really annoy the python people} • _{Try and take over the world}

(5)

Parrot’s guiding goals

• _Speed

• _{Maintainability} • _Longevity

• _{Extensibility} • _Flexibility

(6)

Speed

• _{Faster is good}

• _{A slow interpreter is of little use} • _{Things almost never get any faster} • _{Parrot sets the maximum speed}

(7)

Maintainability

• _{Try and keep things black-box}

• _{Try and enforce a coding standard} • _{Open Source projects have limited}

engineering resources

• Things rarely get more maintainable

• _{Maintenance always consumes the most}

(8)

Longevity

• _{Software always lives on well past the point}

you think it should

• _{Designing for long-term expandability puts}

off the inevitable rewrites

• _{We’re going to be looking at this code for}

the better part of a decade, so we’d best make sure we want to look at it

(9)

Extensibility

• _{Everyone wants to add on with C} • _{Things are never quite fast enough}

• _{There are lots of external libraries worth}

using

• A good extension mechanism is a great thing

(10)

Flexibility

• _{General solutions have more long-term}

potential than specific ones

• _{People always do things you don’t expect} • If you plan for it now, it doesn’t cost more

later

(11)

Multi-language capabilities

• _{Support perl}

• _{Support Dynamic Languages in general} • _{Nice target for language designers}

(12)

Support perl

• _{Perl 6 was the reason this all started}

• _{Perl has the most complex semantics of all}

the dynamic languages in common use

• Perl is a major pain to implement, as languages go

(13)

Support Dynamic Languages in general

• _{Includes Ruby and Python, for example} • _{Languages that have some compile-time}

uncertainty

• Actually trivial, just a matter of thinking about it

(14)

Nice Target

• _{If we express all the semantics, it makes it}

easier for language designers

• _{Many now target C, or GCC}

• Impedance mismatch lower for many languages

(15)

Play Zork natively

• _{Yep, that’s right}

• parrot -b:zmachine zork.dat • _{Doing this right is harder than doing Java,}

Python, or .NET bytecode

• If we can do this, we can do anyone’s bytecode

(16)

Interpreter basics

• _{Chunk of software that executes other}

software

• A CPU in software

• Generally flexible

• _{Generally slow} • _{Easy to write for} • _{Easy to write}

(17)

CPU in software

• _{It’s the “V” in VM}

• _{The compiler writer can treat the interpreter}

as a form of CPU chip

• Allows much easier customization of ‘core’ behavior

• _{Sometimes software does become hardware} • _{But often it shouldn’t}

(18)

Generally flexible

• _{Since the core functionality is in software,}

it’s changeable

• _{Software generally has fewer limits to it}

than hardware

• _{It’s easier to think about software than}

hardware, so more people can

(19)

Generally slow

• _{It’s a layer of indirection between the user’s}

program and the hardware that executes it

• _{It’s very easy to have impedance mismatch}

problems

(20)

Easy to write for

• _{It’s easy to gloss over the tough parts}

• _{The interpreter should express itself in ways}

that are easy to use

• You built it as the target, so if it isn’t, you’ve done something wrong

(21)

Easy to write

• _{Interpreters are pure semantics, and}

semantics aren’t that difficult to express

• _{Though defining the semantics can take}

much longer

• _{A simple interpreter can be put together in}

a week

(22)

Portable

• _{Generally the expressed semantics are}

mostly platform-neutral

• _{Means the platform-specific stuff can be}

isolated

• _{Platform specific but unimplemented things}

can be emulated

(23)

Core Parrot Concepts

• _{Register based}

• _{Language Neutral} • _{Very high level}

• _{Introspective} • _Mutable

(24)

Register Based

• _{32 each Integer, String, Float, and PMC} • _{Registers are a kind of named temporary}

slot for the interpreter

• Modeled on hardware CPUs

• Generally more efficient than a pure stack-based model

(25)

Language Neutral

• _{In the}_human_sense

• _{We don’t force ASCII, Unicode, Latin-1,}

or EBCDIC on the user

• The engine has facilities to deal with data regardless of its encoding

• _{Important when dealing with}

(26)

Very high level

• _{Threads, closures, continuations, aggregate}

operations, multimethod dispatch all core elements

• _{Don’t relegate the hard stuff to libraries} • _{Easier on compiler writers}

• _{Bit more of a pain for the interpreter}

(27)

Introspective

• _{Code can inspect the current state of the}

interpreter

• _{Most, if not all, the core data structures are}

accessible

• _{Includes stack entries, symbol tables, lexical}

variables

(28)

Mutable

• _{Code can be created on the fly}

• _{Libraries can be dynamically loaded} • _{Opcodes can be redefined on the fly}

• _{Base variable methods can be overridden at}

(29)

Threaded

• _{Threads are a core element of Parrot}

• _{Threading interpreters is an interesting task} • _{For nasty values of “interesting”}

(30)

With Continuations

• _{Really odd Lisp thing}

• _{Sort of like a closure for control flow}

• _{For reference, exceptions are a simplified}

kind of continuation

• They will rot your brain

(31)

Quick benchmark numbers

Simple MOPS benchmark

Ruby 1.6.6: 207 Sec Perl 5.6.0: 165 Sec Python 2.2: 136 Sec Parrot: 18.75 Sec Parrot (faster): 9 Sec

(32)

Fetching Parrot

• _{http://dev.perl.org} • _{Anon CVS} :pserver:[email protected]:/cvs/public • _{http://www.parrotcode.org}