Mailing List Archive: Suggestion for a project

Suggestion for a project

Aug 29, 1995, 11:22 AM

Post #1 of 4 (1117 views)

Here's an idea which may suit someone who wants to spend some time
doing something helpful with the perl internals while not having to
understand a great deal about them. Maybe there's a lurker out there
itching to get started but not knowing what to do (we can but hope :-)

Take a look at dump.c, in particular dump_op. The -Dx debugging
option to perl uses this to dump information about the op tree.
The format is human-readable.

Your mission, should you choose to accept it, is to tweak this
(or write corresponding functions) which produce output in a more
machine-readable format and then write a parser for it. Why? Once
that's done, it shouldn't be too hard to create an "undumper"
backend which reconstructs ops and SVs as it goes along (in which
case we have a compiler of sorts) or to to do post-processing of
the op tree (which paves the way for some high-level optimisations).
This suggestion will self-destruct in 5 seconds.

--Malcolm

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

Re: Suggestion for a project [ In reply to ]

Tim.Bunce at ig

Aug 30, 1995, 4:13 AM

Post #2 of 4 (1098 views)

Permalink

> From: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
>
> Here's an idea which may suit someone who wants to spend some time
> doing something helpful with the perl internals while not having to
> understand a great deal about them. Maybe there's a lurker out there
> itching to get started but not knowing what to do (we can but hope :-)
>
> Take a look at dump.c, in particular dump_op. The -Dx debugging
> option to perl uses this to dump information about the op tree.
> The format is human-readable.
>
> Your mission, should you choose to accept it, is to tweak this
> (or write corresponding functions) which produce output in a more
> machine-readable format and then write a parser for it. Why? Once
> that's done, it shouldn't be too hard to create an "undumper"
> backend which reconstructs ops and SVs as it goes along (in which
> case we have a compiler of sorts) or to to do post-processing of
> the op tree (which paves the way for some high-level optimisations).
> This suggestion will self-destruct in 5 seconds.
>
:-) [have they shown the "Mission Impossible" TV series outside the UK?]

I think the writing and reading of OP's is easy (the pointer broking
could be fun though) and I'd certainly be happy to do it. But ...

What I'm not sure of is how to traverse an OP tree and be sure of
getting all the OPs needed.

If you, or Larry (or anyone else familiar with the OP's for that matter)
could list which OP*'s to follow, and how, for each OP type then we'd be
half way home.

> --Malcolm
>
Tim.

Re: Suggestion for a project [ In reply to ]

aburlison at cix

Aug 30, 1995, 7:06 PM

Post #3 of 4 (1093 views)

Permalink

In-Reply-To: <199508291722.SAA10086@sable.ox.ac.uk>
> Here's an idea which may suit someone who wants to spend some time
> doing something helpful with the perl internals while not having to
> understand a great deal about them. Maybe there's a lurker out there
> itching to get started but not knowing what to do (we can but hope :-)

[.fx: rustling of leaves as I appear out of the undergrowth]

I'd be willing to have a crack at this. I have done something vaguely
similar in the past - I wrote a compiler for an AI language called OPS5,
which used an optimised pattern matching network - effectively a parse
tree. This was output as machine code for a 'virtual machine', and was
read in and interpreted at run time. I'll have to do it very part-time,
as I am very busy with 'real' (?) work at the present.

Alan Burlison aburlison@cix.compulink.co.uk

Re: Suggestion for a project [ In reply to ]

js at biu

Aug 31, 1995, 5:13 PM

Post #4 of 4 (1095 views)

Permalink

> Take a look at dump.c, in particular dump_op. The -Dx debugging
> option to perl uses this to dump information about the op tree.
> The format is human-readable.
>
> Your mission, should you choose to accept it, is to tweak this
> (or write corresponding functions) which produce output in a more
> machine-readable format and then write a parser for it. Why? Once
> that's done, it shouldn't be too hard to create an "undumper"
> backend which reconstructs ops and SVs as it goes along (in which
> case we have a compiler of sorts) or to to do post-processing of
> the op tree (which paves the way for some high-level optimisations).
> This suggestion will self-destruct in 5 seconds.

I stole some time and had a quick look see. As a first pass, I
moved dump.c into an extension. But when I run, say,
'dump_packsubs(defstash)', I get garbage in places:

(I changed the op_name array access to print out the
op_type as a number - here its 72025089, which is plain
garbage as this should be an enumerated value and so
quite small.)

------------------------------------
SUB AutoLoader::croak = {
13 TYPE = 72025089 ===> DONE
FLAGS = (SCALAR,KIDS,PARENS,STACKED)
{
Segmentation fault (core dumped)
------------------------------------

By checking to see where its dumping, it is following the kid
and trying to dump that, but there should be no kid - again
must be garbage in 'op_flags'. Anyone tell me whats missing
to move dump.c to extension?