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