Re^2: Pad variables without sigils?

Hmmm. If you or anyone knows of any constructions that access these things I'd be interested. I'm still not sure there's anything that I'll encounter in the optree that touches them.

Comment on Re^2: Pad variables without sigils?

Replies are listed 'Best First'.
Re: Re^2: Pad variables without sigils? by jand (Friar) on Mar 21, 2003 at 09:56 UTC
I don't remember the details, but some ops store state data in the TARG field (e.g. regex opcodes). When Perl is compiled with ithreads support, the opcode tree is shared between interpreters, so storing data in the optree creates concurrency problems. In that case the SV* is moved to an unnamed scratchpad entry and the TARG field contains an index into the pad instead of the SV* itself.	[reply]
Re: Re^2: Pad variables without sigils? by shotgunefx (Parson) on Mar 20, 2003 at 21:05 UTC
No idea what is put there. I believe it's just scratch space for certain operation but what makes or uses those SVs I have no idea. Update I went looking through my poke_my notes and refreshed my memory. My understanding is that the other stuff in the pad is indeed scratch space for opcodes. From perlguts A scratchpad keeps SVs which are lexicals for the current unit and are targets for opcodes. One can deduce that an SV lives on a scratchpad by looking on its flags: lexicals have SVs_PADMY set, and targets have SVs_PADTMP set. -Lee "To be civilized is to deny one's nature."	[reply]