Introducing Parrot SDL

by chromatic

Related link:

One of the prime advantages of dynamic (or agile) languages — the integrated compile and run phase that handles source code directly — is actually a bit of a drawback in some circumstances. If you're doing very fast low-level bit twiddling, Perl, Python, and Ruby probably aren't for you. It can be difficult to approach the speed of good assembly or optimized C code.

In some applications, such as high-volume number crunching or real-time games, this is a big drawback.

Fortunately, much as you can drop to raw assembly from C code, you can link your favorite dynamic language with C or C++ code. Unfortunately, it's usually tedious. Every newer language improved on things. Perl 5's XS is reasonably easy for the easy things, but can require a downright arcane knowledge of the sometimes-squanmous Perl internals for the complex things. Python is easier. Ruby is easier still.

The Swig project exists to make writing language bindings easier still, but it's still not easy.

If Parrot, the VM for Perl 6 and succeeds and attracts other languages, it may present an easier solution. Because of Parrot's design, it's amazingly easier to write bindings for other libraries. Even better, you can write your bindings once, to Parrot, and then they're available to all languages that run on Parrot.

Imagine that everyone who looked longingly at PyGame from Ruby could actually use that very library from Ruby.

I've been working on just that project (well, not quite a full PyGame port — there are still some details to hash out). At the Portland Perl Mongers meeting on 14 April 2004, I'll present SDL Parrot by introducing Parrot, Parrot's Native Call Interface, object oriented Parrot, and, finally, all of the SDL bindings I can implement by then. See the web page for details.

If things go well, I may show off a custom animation language running atop Parrot in the next couple of months. Here's a snippet of Parrot assembly code (as low-level as I can program productively) that draws a blue square to whet your appetite. Remember, this is an assembly language.

.pcc_sub _main non_prototyped, @MAIN
load_bytecode "library/SDL/App.imc"
load_bytecode "library/SDL/Rect.imc"
load_bytecode "library/SDL/Color.imc"

.local pmc app
.local int app_type

find_type app_type, 'SDL::App'
new app, app_type

.sym pmc args
new args, .PerlHash
set args['height'], 480
set args['width'], 640
set args['bpp'], 0
set args['flags'], 1

app.'new'( args )

.local pmc rect
.local int rect_type

find_type rect_type, 'SDL::Rect'
new rect, rect_type

new args, .PerlHash
set args['height'], 100
set args['width'], 100
set args['x'], 270
set args['y'], 190

rect.'new'( args )

.local pmc color
.local int color_type

find_type color_type, 'SDL::Color'
new color, color_type

new args, .PerlHash
set args['r'], 0
set args['g'], 0
set args['b'], 255

color.'new'( args )

app.'fill_rect'( rect, color )
app.'update_rect'( rect )

sleep 2


This is just one piece of the puzzle for Game Programming with Parrot. Stay tuned.


2004-04-01 12:48:32
Not always hard.
The Critcl package ( makes embedding C in Tcl scripts trivially easy... and of course, Tcl was originally designed to make it easy to add-on new C code.
2004-04-05 07:32:38
Not always hard.
That's great to know. What does that have to do with Parrot or anything in this article? There are C interfaces for just about every scripting language.
2004-04-05 14:10:24
You stated that "Here's a snippet of Parrot assembly code". Isn't your code sample IMCC, which is an intermediate language that is higher-level than PASM?

Anyway, cool stuff! Congrats on doing ANYTHING in Parrot given the state of the documentation :-(

2004-04-05 14:44:22

You're right, this is PIR code that IMCC understands, not raw PASM. I waved my hands a bit in that sentence.

As for the documentation, it's not too bad. Experience does help, as does reading the test files. Two of my goals in this experience are to produce better documentation and to figure out some useful idioms for future projects.

2004-09-24 12:13:43
Swig may still be useful
I agree that the parrot NCI interface is the sweetest I have worked with yet.

However, when wrapping C++ libraries, you still need to generate alot of wrapper code in C, as well as alot of imc code to invoke that C++ code.

Either that, or do the whole thing in C, and use the parrot extension api to create the corresponding parrot objects.

Either way, it seems to be that some code generator should be used to create these wrappers. Then perhaps existing swig interfaces can be easily ported from other scripting langugaes and all can benefit.