1 / 92

An Introduction to Parrot

An Introduction to Parrot. Dan Sugalski dan@sidhe.org. January 28,2004. Overview. What’s it all about. Purpose. Optimized for Dynamic Languages Perl 5, Python, Ruby specifically Run really, really fast Or at least as fast as reasonable under the circumstances Easily extendable

elan
Download Presentation

An Introduction to Parrot

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An Introductionto Parrot Dan Sugalski dan@sidhe.org January 28,2004

  2. Overview What’s it all about

  3. Purpose • Optimized for Dynamic Languages • Perl 5, Python, Ruby specifically • Run really, really fast • Or at least as fast as reasonable under the circumstances • Easily extendable • Easily embeddable • Play Zork

  4. History How we got where we are

  5. OSCON 2000 • Infamous mug pitching incident • Perl 6 started • Language and software developed separately

  6. Perl 6 -- not too much bigger • That hasn’t lasted • Allison’s talking about that one • The start was smallish, though • Fix the annoyances • Amazing how many things turned out to be annoying

  7. Big language umbrella • Not much semantic difference between Perl 5, Python, and Ruby • Perl 6 was obviously going to borg them and a bit more • Even ML and Haskell haven’t been safe • More concepts have gone in as time has progressed

  8. Parrot went for them all • Yeah, we were getting bored • Had to do something • We liked Ruby and even Python • We hated having multiple interpreters around

  9. Parrot and the Parrot Prank • 2001 April Fools Joke • Perpetrated by Simon Cozens • Parrot -- New language • Perl & Python Amalgam • Pretty funny as these things go

  10. Timeline • The project came first • Then, the Parrot Joke • We grabbed the name

  11. Non-Purpose • Don’t care about non-dynamic languages • Not much, at least • Other people can worry • Engineering tradeoffs favor dynamic languages

  12. True language neutrality is impossible • Vicious sham • All engines have a bias • Even the hardware ones • Processors these days really like C

  13. Architecture How it’s supposed to look

  14. Buzzwords • Register based, object-oriented, language agnostic, threaded, event-driven, async I/O capable virtual machine • No, really

  15. Software goals • Fast • Safe • Extendable • Embeddable • Maintainable

  16. Administrative goals • Resource Efficient • Controllable • Not suck when used as an apache module • Cautious about whole-system impact

  17. Driving assumptions • C function calls are inexpensive • L1 & L2 caches are large • Memory bandwidth is limited • CPU pipeline flushes are expensive • Interpreter must be fast • JIT a bonus, not a given

  18. User Stack Interpreter Core String registers Integer registers Lexicals Globals Float registers PMC registers Control Stack Frame Stack Frame Stack Frame Stack Frame Stack Interpreter Core in Pictures

  19. Parser • Source goes in, AST comes out • Built in part on perl 6 rules engine • Pluggable parser architecture

  20. Compile and optimize (IMCC) • Turns the output of the parser into executable code • Optional optimizing step • Register coloring algorithms provided here

  21. Execution • Interpreter • JIT • C code • Native executables

  22. Base Engine • Bytecode driven • Platform-neutral bytecode • Register-based system • Stacks • Continuation-passing style

  23. Bytecode • Directly executable • Resembles native executable format • Code • Constants • Metadata • No BSS, though

  24. Designed for efficiency • Directly executable • mmap()ped in • Only complex constants (strings, PMCs) need fixup • Converts on size and/or endian mismatch

  25. Platform Neutrality • If native format, used directly • Otherwise endian-swapped • Off-line utlity to convert • Only difference is speed hit on startup

  26. Registers • All operations revolve around VM registers • Essentially CPU registers • Four types • Integer • Float • String • PMC • 32 of each

  27. Registers • Parrot’s one RISC concession • Non-load/store must operate on registers or constants • JIT maps VM registers to platform registers if there are some • Otherwise pure (and absolute) memory addressing to VM registers

  28. Stacks • Six stacks • One general purpose typed stack • Four register backing stacks • Push/pop half register frames in one go • Faster than push/pop of frames to general stack • One control stack

  29. Stacks • Bit of a misnomer • Really tree of stack frames • Confusing, though

  30. Continuation Passing Style • Used for calling conventions • Parrot makes heavy use of continuations • If you don’t know they’re there you’ll not care • All Ruby’s fault, really • Hidden from HLL code

  31. Parrot’s data Where the magic lives

  32. Data isn’t passive • Lots of functionality hidden in data • Partly OO • Or as OO as you get in C

  33. Strings • Language neutral • Encapsulate language behavior, encoding, and character set • Annoyingly complex

  34. Basic String Diagram Buffer Info Encoding Charset Language Flags

  35. Encoding • Represents how the bits are turned into ‘characters’ • Code points, really • Even for non-unicode encodings • Handles transformations from/to storage

  36. Character Set • Which characters the code points represent • Basic character manipulation happens here • Case mangling, substrings • Transformations to other character sets

  37. Language • Nuances of sorting and case mangling • Interpretation of most asian text when using Unicode • Ignorable if you don’t care

  38. Unicode • Parrot does Unicode • Used as pivot encoding/charset • IBM’s ICU library • Didn’t want to write another badly done unicode library

  39. Efficiency concerns • Multiple encodings/charsets means less conversion • Transform data only when needed • Strings are mutable • COW system for space/speed efficiency

  40. The PMC • Represents a HLL variable • Language agnostic • Everything pivots off PMCs

  41. Vtable Flags Cache Data Pointer Metadata GC handle Synchronization PMC diagram

  42. The Vtable • How all the functionality is implemented • Almost everything defers to PMCs • Large part of interpreter logic in PMCs • Allows fast operator overloading and tying

  43. Addition Subtraction Multiplication Division Bitwise operations Loading Storing Comparison Truth Type conversion Logical operations Finalization Some vtable operations

  44. Vtable functions may be Parrot • How languages implement user operator overloading • Used for perl-style tying • Usable for operator wrapping

  45. PMCs are typed • Types can change • Allows customized behavior • Cuts out some overhead

  46. All PMCs indexable • As array or hash • Operations may be delegated • PMC may be both hash and array • Scalar as well

  47. Multimethod dispatch • Core interpreter functionality • Used for many PMC operations • Beats hand-rolling it • Dispatch surprisingly fast

  48. Magic all hidden • User code never knows about magic • Allows transparent behaviour changes • One big pivot point for dispatch

  49. Objects • Standard but optional object system • Standard object protocols • Standard object opcodes

  50. Everything can be an object • Objects have attributes • Objects can have methods call on them • All PMCs have get/set attribute vtable entries • All PMCs have a method call entry • Therefore, all PMCs are objects

More Related