Re: First victim, er SV type

[email protected] (Arthur Bergman) Mon, 17 May 2004 09:13:39 +0100
Newsgroups perl.ponie.dev
Message-ID <[email protected]>
Nicholas deferred to me to answer and I have as always been my slacking 
self.

On 7 May 2004, at 21:12, Dave Mitchell wrote:

> On Fri, May 07, 2004 at 01:50:32PM +0100, Nicholas Clark wrote:
> (lots of stuff about morphing SVs into PMCs).
>
> When I read this, and started to try and think about it and understand 
> it,
> I realised that my current mental picture of Ponie wasn't good enough 
> to
> be able to reply meaningfully. So if I might be permitted, I'd like to
> digress for a moment with some questions - not just addressed to Nick, 
> but
> to the whole list.
>
> My understanding is that in Perl5, "ops are smart, SVs are dumb", while
> in Perl6/Parrot, it's the reverse: "bytecode is dumb, PMCs are smart".
> For example in Perl5, an SV is really little more than a storage vessel
> that can hold various items of data such as an IV, an NV or a string,
> plus some flags that indiciate what's stored in it. On the other hand,
> the Perl5 'int' opcode 'knows' about all the possible things that 
> could be
> stored in an SV, and has full responsibility for doing all the work
> involved in coercing the SV's value into an integer (such as 
> converting a
> string into an int, or using the address of of the thing pointed to by 
> an
> RV as as int). With parrot, the 'int' byte code just calls the get_int 
> method
> on the PMC, and the PMC holds all the intelligence as to how to 
> extract an
> integer value out of itself.  Actually I'm oversimplifiying slightly,
> since SVs can have magic attached, which is a half-assed attempt to 
> make
> them intelligent like PMCs.
>

Yes you are correct, even if the opcodes are dubm in perl5 too, it is 
just the SvIV macro which calls various functions and checks flags and 
then gets the int. An ever increasing number of if branches that are to 
be replaced by a single little vtable call ;)

> Anyway - what, philosophically speaking, is Ponie's intentions in this
> area? Does it just want to use PMCs as dumb storable vessels, or does 
> it
> want to transfer the intelligence into them? And are we intending to 
> use
> off-the-shelf parrot/Perl6 PMCs, or a whole bunch of Ponie-specific 
> PMCs
> that ape all the Perl5 SV types?
>

I want to transfer as much intelligence into them as possible. the only 
exception will be some internally used PMCs for things like the pad and 
the stack which are too incesteous with the AV type, as I am sure you 
are well aware. However for speed reasons it might be a good thing to 
give the stack and the pads it's own data types optimized for that kind 
of access (in pads case,  never extend after completion for example).

This will let the normal hashes for example get rid of the garbage it 
carries around because of the stashes. (There is an potential for 
optimizing memory usage in perl5), at least when someone relies  on 
hashes for OO).

> Also, what actually is the final purpose of Ponie? Is it intended to be
> an integrated part of Perl6+Parrot, so that when someone compiles a 
> Perl
> program, the parts of it that are Perl5 syntax get compiled using a 
> bunch
> of Perl5 byte codes, but apart from that its one big happy executable,
> with perl5 bits of code calling into perl6 bits of code and vice-versa,
> with PMCs being happily passed between them? And running as least as 
> fast
> as the current Perl 5 interpreter? Or is the goal less ambitious?
>

The original idea was due to a lack of satisfaction with magic and the 
enormous speed penalty it imposes on threads in perl 5. So I wanted to 
rip out all SVs and use vtables, and since PMCs already existed. (This 
is an age old debate on p5p that I guess we neatly went around by doing 
ponie). I am the firm believer that this needs to happen to the perl5 
core. I would say that.

Run 100% of all pure perl code
Run 95% of all XS code
Run along side perl 6 (other parrot) applications allowing data 
interchange
Allow parrot languages to access XS code
Someday be released as perl 5.42 which of course will be the answer too 
....

So hopefully you will be able to load in ponie as a shared library + a 
set of shared library PMClasses in parrot.

Cheers
Arthur