PMCs: Should We Use Them?

4 views
Skip to first unread message

Matt Diephouse

unread,
Jul 7, 2005, 11:29:35 AM7/7/05
to Chip Salzenberg, Perl 6 Internals
Dan wrote an entry on his blog yesterday entitled "WWIT: Universal bytecode":

http://www.sidhe.org/~dan/blog/archives/000421.html

In it, he talks (surprise, surprise) about being able to run bytecode
across machines without the need of a compiler. If you look at the
comments, I asked what this meant for PMCs. As it currently stands,
many of the languages currently targeting Parrot would need their PMCs
distributed in order to run any programs written in that language.

Are there any thoughts from the new powers that be? Should PMCs be
avoided when possible? Should there be PIR versions of the PMCs
available for distributing bytecode? Should as much functionality as
possible be put into the core PMCs?

I'd like the ability to distribute bytecode without PMCs; I think it's
something worth working for. What's the best way to make this work in
light of PMCs?

--
matt diephouse
http://matt.diephouse.com

Leopold Toetsch

unread,
Jul 7, 2005, 11:57:16 AM7/7/05
to ma...@diephouse.com, Chip Salzenberg, Perl 6 Internals
Matt Diephouse wrote:
> Dan wrote an entry on his blog yesterday entitled "WWIT: Universal bytecode":
>
> http://www.sidhe.org/~dan/blog/archives/000421.html
>
> In it, he talks (surprise, surprise) about being able to run bytecode
> across machines without the need of a compiler. If you look at the
> comments, I asked what this meant for PMCs. As it currently stands,
> many of the languages currently targeting Parrot would need their PMCs
> distributed in order to run any programs written in that language.

Well, if you have some mixed environment, you'd probably build parrot on
all machines with the PMC's needed. Something like:

perl Configure.pl --with-tcl --with-python

to get these PMCs built on it.

> Are there any thoughts from the new powers that be? Should PMCs be
> avoided when possible? Should there be PIR versions of the PMCs
> available for distributing bytecode? Should as much functionality as
> possible be put into the core PMCs?
>
> I'd like the ability to distribute bytecode without PMCs; I think it's
> something worth working for. What's the best way to make this work in
> light of PMCs?

I still like to unify ParrotObjects and PMCs more. An Integer PMC
shouldn't really be much different then a instantiated object of a
closed ParrotClass with one attribute - the native int value.
When that is done, there is no physical difference between a builtin PMC
and a class built in a PIR module, so that you can mix these two
depending on their availability.

leo

Roger Browne

unread,
Jul 7, 2005, 12:40:10 PM7/7/05
to Perl 6 Internals
Leopold Toetsch wrote:
> Well, if you have some mixed environment, you'd probably build parrot on
> all machines with the PMC's needed. Something like:
>
> perl Configure.pl --with-tcl --with-python
>
> to get these PMCs built on it.

I'm thinking of situations like web hosting, where the provider will in
future offer parrot alongside php etc. But you probably won't be able to
convince the average web hosting provider to reconfigure their parrot
installation to include PMCs that support your preferred niche language.

Dan wrote:
> I was hoping we'd see hybrid PMCs -- that is, language specific
> PMCs that were fully implemented both in pure bytecode and in C.
> You'd use the C version if you could, otherwise you'd use the
> bytecode version ... There probably ought to be facilities in
> parrot itself, or in its library loading and management code,
> to handle this.

That would be excellent.

Matt Diephouse wrote:
> Should as much functionality as possible be put into the core PMCs?

I'd like to see parrot include a set of core PMCs that implement fairly
pure abstractions, without any language-specific stuff (such as
automatic conversions, preconceived notions of which string values are
true/false etc). It would be easier for a language implementor to add
functionality to these, than to modify PMCs that include some perl-isms
or python-isms.

> > I'd like the ability to distribute bytecode without PMCs; I think it's
> > something worth working for.

I agree. I'm currently using the existing parrot core PMCs for the amber
language. But I can see that I could get much better performance and the
precise semantics that I want by writing my own PMCs instead - and I may
yet have to do this.

Leo:


> I still like to unify ParrotObjects and PMCs more.

I second that. I liked the directions in which that was moving.

Regards,
Roger Browne


Matt Diephouse

unread,
Jul 7, 2005, 12:16:50 PM7/7/05
to Leopold Toetsch, Chip Salzenberg, Perl 6 Internals
Leopold Toetsch <l...@toetsch.at> wrote:
> Matt Diephouse wrote:
> > Dan wrote an entry on his blog yesterday entitled "WWIT: Universal bytecode":
> >
> > http://www.sidhe.org/~dan/blog/archives/000421.html
> >
> > In it, he talks (surprise, surprise) about being able to run bytecode
> > across machines without the need of a compiler. If you look at the
> > comments, I asked what this meant for PMCs. As it currently stands,
> > many of the languages currently targeting Parrot would need their PMCs
> > distributed in order to run any programs written in that language.
>
> Well, if you have some mixed environment, you'd probably build parrot on
> all machines with the PMC's needed. Something like:
>
> perl Configure.pl --with-tcl --with-python
>
> to get these PMCs built on it.

Yes, but the point is that sometimes you don't have that power. In
some cases you aren't able to configure Parrot, or install additional
PMCs. That's when it matters. In those cases, you need to be able to
create standalone bytecode.

Chip Salzenberg

unread,
Jul 7, 2005, 12:51:18 PM7/7/05
to Roger Browne, Perl 6 Internals
Dan wrote:
> I was hoping we'd see hybrid PMCs -- that is, language specific
> PMCs that were fully implemented both in pure bytecode and in C.

Huh? Parallel maintenance of duplicate complex implementations?
On _purpose_?

"That trick *never* works!"

> I'd like to see parrot include a set of core PMCs that implement fairly
> pure abstractions, without any language-specific stuff (such as
> automatic conversions, preconceived notions of which string values are
> true/false etc).

Well, we're going to (continue to) have string<->integer and
string<->double conversions built in, because integer, double, and
string registers are built in; they're fundamental VM concepts for
Parrot.

String true/false value, though, I agree; Parrot core PMCs and opcodes
shouldn't have any opinion on that.
--
Chip Salzenberg <ch...@pobox.com>

Leopold Toetsch

unread,
Jul 7, 2005, 2:33:06 PM7/7/05
to ma...@diephouse.com, Chip Salzenberg, Perl 6 Internals

On Jul 7, 2005, at 18:16, Matt Diephouse wrote:
>
> Leopold Toetsch <l...@toetsch.at> wrote:
>> Matt Diephouse wrote:
>>>

>>
>> perl Configure.pl --with-tcl --with-python
>>
>> to get these PMCs built on it.
>
> Yes, but the point is that sometimes you don't have that power.

Err, and that was answered in the part below, you seemed to have
snipped.

leo

John Lenz

unread,
Jul 7, 2005, 8:42:08 PM7/7/05
to Perl 6 Internals
On Thu, July 7, 2005 11:40 am, Roger Browne said:
> Matt Diephouse wrote:
>> Should as much functionality as possible be put into the core PMCs?
>
> I'd like to see parrot include a set of core PMCs that implement fairly
> pure abstractions, without any language-specific stuff (such as
> automatic conversions, preconceived notions of which string values are
> true/false etc). It would be easier for a language implementor to add
> functionality to these, than to modify PMCs that include some perl-isms
> or python-isms.
>

One specific issue this brought to mind is the Pair PMC. The pair pmc is
not really a pair. It is what I would call a dictionary entry. The
design and writing of the pair assumes the pair will be used for a
key->value type entry. But I just want to have a pair that stores two
PMCs. Thus, I currently have the option of using FixedPMCArray and
setting the size to 2, or writing a "real" pair pmc. Using the
FixedPMCArray has a performance hit, so I would like to use a "real" pair
pmc.

The problem with the pair pmc is the inability to change the key. So the
existing pair PMC should be modified to use indexing to access elements 0
and 1 (get_pmc_keyed_int and set_pmc_keyed_int). This is what you think
of when you think of a pair. Then a DictionaryEntry PMC can be derived
from this that protects the key from changing and also includes the
set_pmc_keyed and is_equal functions.

John

Michal Wallace

unread,
Jul 7, 2005, 9:28:04 PM7/7/05
to Roger Browne, Perl 6 Internals
On Thu, 7 Jul 2005, Roger Browne wrote:

> Leopold Toetsch wrote:
>> Well, if you have some mixed environment, you'd probably build parrot on
>> all machines with the PMC's needed. Something like:
>>
>> perl Configure.pl --with-tcl --with-python
>>
>> to get these PMCs built on it.
>
> I'm thinking of situations like web hosting, where the provider will in
> future offer parrot alongside php etc. But you probably won't be able to
> convince the average web hosting provider to reconfigure their parrot
> installation to include PMCs that support your preferred niche language.


Speaking as someone who runs a web hosting company:
you're absolutely right. This would be a nightmare.

What I'd want is to be able to download the language
specific extensions as a library from cpan. Better
yet if users can do it themselves without having
to bug me.

Sure, I'd probably install as much as I could, but
there's always someone who wants the version you're
not running. :)

- Michal
http://withoutane.com/

Larry Wall

unread,
Jul 7, 2005, 11:28:01 PM7/7/05
to Perl 6 Internals
On Thu, Jul 07, 2005 at 09:28:04PM -0400, Michal Wallace wrote:
: What I'd want is to be able to download the language

: specific extensions as a library from cpan. Better
: yet if users can do it themselves without having
: to bug me.

Hmm...

: Sure, I'd probably install as much as I could, but


: there's always someone who wants the version you're
: not running. :)

My new language has several additional instruction:

break_out_of_sandbox
be_a_zombie
rm_minusrf
melt_cpu

:-)

Larry

Joshua Juran

unread,
Jul 8, 2005, 12:03:23 AM7/8/05
to Perl 6 Internals
On Jul 7, 2005, at 11:28 PM, Larry Wall wrote:

> On Thu, Jul 07, 2005 at 09:28:04PM -0400, Michal Wallace wrote:
> : What I'd want is to be able to download the language
> : specific extensions as a library from cpan. Better
> : yet if users can do it themselves without having
> : to bug me.
>
> Hmm...

> My new language has several additional instruction:
>
> break_out_of_sandbox
> be_a_zombie
> rm_minusrf
> melt_cpu
>
> :-)

I would expect these to be privileged instructions. For example, only
root should be entitled to melt the CPU.

Josh

Nicholas Clark

unread,
Jul 8, 2005, 6:26:42 AM7/8/05
to Joshua Juran, Perl 6 Internals

Yes. Quite. For example, they seem to have added a "halt and catch fire"
instruction to the engine management firmware on London's bendy buses, and
what do you expect? End users decide to use it:

http://news.bbc.co.uk/1/hi/england/london/4343555.stm
http://news.bbc.co.uk/1/hi/england/london/3557309.stm
http://news.bbc.co.uk/1/hi/england/london/3287167.stm

Nicholas Clark

Michal Wallace

unread,
Jul 8, 2005, 3:41:23 PM7/8/05
to Larry Wall, Perl 6 Internals

Cool! It's still not as dangerous as letting
users run PHP. :)

Dangerous or runaway user programs are just part
of what you have to deal with when running a hosting
company. You set up scripts and monitors to catch
most of the problems, and if something slips through
the cracks, you address it. That's how I do things
anyway, and it seems to keep my customers happy. :)

In any case, my understanding is that right now
parrot requires all the dynclasses to be built
as part of the parrot source tree, so they might
as well not by dynamic after all. At some point
that's supposed to change, so we'd be able to
bundle each set of PMC's separately anyway.

I also really like Dan's idea about using the built-in
pmc's as the base for other languages. I'll see what
I can do about python. A year and a half ago, I read
the specs and didn't think this would be possible...
but maybe things have changed enough that we can do
it now.

- Michal
http://withoutane.com/

Reply all
Reply to author
Forward
0 new messages