Given that that's the intent, it seems to make sense for the platform-agnostic part of PCT to live as part of nqp and be bundled with Parrot and for Parrot to include its own extensions in parrot.git or a parrot-owned submodule.

even in the current world view, I would expect that things like pir:: and Q:PIR in Rakudo would need to be exposed by a "use Parrot;", that would need emulation if a Perl 6 program expects to run on a backend other than Parrot.

I should have qualified that to "Parrot-specific" semantics, I guess. NQP of course has semantics that it seeks to provide regardless of VM backend (and regardless of whether each VM supports them natively or not).

I might be overstating this, but I think that for the majority of items in that list they've been implemented in Rakudo by working around core Parrot, not as a result of it. (Modulo PGE and PCT being considered part of "core Parrot".)

Hypothetically speaking, if Parrot included new NQP in a tarball as the One Good Default Option for building languages with PCT, we would tell users "To use Parrot specific features, use 'use parrot' in the appropriate scope"?

or, it could be enabled by default, but if you expect to your language to run on another backend, you want to avoid those features or make sure that the parrot features are emulated for that other backend somewhere.

The underlying match object is now available via the $/ variable, which is implicitly lexically scoped. All user access to the most recent match is through this variable, even when it doesn't look like it. The individual capture variables (such as $0, $1, etc.) are just elements of $/.

I have this vision in my head of an editor written in Go with modules written in everything imaginable, compiled to PBC, or perhaps even communicating over CGI or something, but all usable from any language

my point is only this: For a low-level parrot language, I would be able to specify the :outer relations where necessary, and I should be able to avoid storing values in LexPads for values that I don't want stored that way.

with PIRATE in the wings, it may be possible to improve PIR in-place over time. This is especially good if most people use something higher up (NQP or other HLL) and aren't relying on PIR syntax directly

because like I said, registers in PIR are integer indices into an array. If we change them to possibly be pointer-aliases, we pay a performance hit by having to ask whether a register is a value or a reference, or we have to always dereference and store a second array of register pointers

whiteknight: (re: pirate might make PIR nicer) PIR is a declarative syntax, which is inherantly limiting. we need an imperative means of constructing PBC if we want to get more general, which is a better approach in my mind than adding yet another special case syntax.

so, if a P-register was used as a temporary in an outer sub that has to continue to stick around, its PMC (and all of that PMC's children) are kept alive, even though they are in fact totally inaccessible

whiteknight: a register allocator has to know about the lifetime of registers anyways. it knows that null is a write-only, pure operation and therefore, nulling will not interfere with a register allocator

pmichaud: also, does that mean that this hypothetic 5th bank of registers is special as compared with the others? e.g., when you "save context", you're really only concerned with the 5th bank and not the others (the INSP are all assumed temporaries)?

I don't think it is worth making this change unless and until it can be demonstrated to have improvements in benchmarks. It may be intuitive (at least to you) that it would improve performace, but I want proof for such a large change.

PerlJam: (what would that look like?) Same as what we do now. In PAST, whenever I need a new register, I just generate $Pxxx where 'xxx' is some unique number that hasn't been used before. IMCC takes care of allocating a unique register for it.

then, I could mark big PMC structures (like the parse tree) with the flag when I think they're no longer needed, and if they show up as alive in a later mark+sweep I can at least have some clue of the PMCs that led to it

I just thought of a horribly inefficient algorithm that would give what you asked. Tell the GC to give you a list of all objects that reference another object, run GC, update searched-for object, repeat.

parrot/whiteknight/imcc_compreg_pmc: This should preserve current PIR-facing behavior of this method, which we don't need to do since it's deprecated. I'll tackle that beast in a different branch. segfaulting in nci thunk generator

In nqpclr, if you try to hit an outer that's never been invoked, it doesnt magically create a lexpad. It just uses the static one. And the stuff bound into that is the basis of the lexpad for all future invocations.

noob question: i want to test Parrot_hires_get_time(), which lives in src/platform/generic/hires_timer.c and has its prototype in include/platform/platform_interface.h . when i write a quick test program to fiddle with it, gcc blows up when it encounters UHUGEINTVAL, which is defined in /include/parrot/config.h. is there an easymode solution to this?