Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Perl>
  3. porters
Re: Perl Compiler
Tim.Bunce at ig
Dec 12, 1995, 7:00 AM
Post #1 of 7 (211 views)
Permalink
Newsgroups: comp.lang.perl.misc
Message-ID: <DJH7o1.5Lx@ig.co.uk>
References: <4ahoti$j7g@camelot.ccs.neu.edu>

In article <4ahoti$j7g@camelot.ccs.neu.edu>,
durgaprasad ayyalasomayajula <saibaba@ccs.neu.edu> wrote:
> Hello world,
> I am thinking of writing PERL(a pearl indeed) compiler as my Master's thesis.
> I would like the net to help me in the following feilds.
> 1. Guide me whenever I get stuck.
> 2. Give your Invaluable advices during the design Phase.
> 3. Any People who had designed compliers earlier should give their experiences
> and the critical sections where they were burnt down.
> The Goal should be
> a)It should run atleast as fast as a C complier
> b)Address perl 5
> Also Please give an estimate of the amount of time I need to spend if a good
> Perl/C/C++ programmer has to spend with 3 years of company experience.
>
> do you think that I can code it in Perl itself?
> (some of the IPC sections s (semaphores) failed when I used them).
> All suggestions and comments are welcome.
> --Prasad.

Here are some relevant comments from the Module List (which you've
probably already seen):

--
Part 3 - Big Projects Registry
==============================

1) Introduction

This section of the Module List is devoted to listing "Big Projects".
I don't want to define Big (or even Project) here. I hope the items
below speak for themselves. Almost all are just ideas, though some have
been dabbled with.

These are ideas for people with very strong skills and lots of time.
Please talk, and listen, to Larry _before_ starting to do any work on
projects which relate to the core implementation of Perl.

3) Perl Compiler

Part of the design of Perl 5 was to make it possible to write a
compiler for it. It's a possible master's thesis topic.

Related to this is the ability to save and load a 'flat' byte-code
representation of the compiled perl code. It would be translated back
into Perl's own internal form for speed.

Note that three different prototype Tcl compilers have been announced
in the comp.lang.tcl group! Anyone interested in this should also take
a good look at the Java language from Sun http://java.sun.com/.

Contacts: LWALL P5P
--

Note the "Please talk, and listen, to Larry _before_ starting"!

You will need a very strong understanding of how perl internals work.
Not simple SV's HV's etc but how things like closures are implemented.

I would suggest that you don't even try to parse perl but treat the OP
trees currently generated as an intermediate language to be fed to your
backend.

I would recommend that you start by writing a module which allows you
to manipulate OP structs and traverse trees of OP structs in perl.
You could then write a perl script to write out C code which
corresponds to those structs.

The much enhanced xsubpp that will come with 5.002 (thanks to Paul
Marquess) now supports structs which sould make implementing this
module *much* easier.

This approach would make prototyping a perl compiler in perl practical.

The Perl::OP module would also be a *very* handy start to the other
'compiler' approach mentioned in the module list text above. And for
that I'd be very grateful.

Good luck - and please keep in touch (perl5-porters is by far the best
place for this kind of internals work).

Tim.
Re: Perl Compiler [ In reply to ]
tom at amber
Dec 12, 1995, 11:59 AM
Post #2 of 7 (212 views)
Permalink
>The much enhanced xsubpp that will come with 5.002 (thanks to Paul
>Marquess) now supports structs which sould make implementing this
>module *much* easier.
>
>This approach would make prototyping a perl compiler in perl practical.
>
>The Perl::OP module would also be a *very* handy start to the other
>'compiler' approach mentioned in the module list text above. And for
>that I'd be very grateful.

You know, putting all these concepts together in one note like this has
caused my mind to boggle at the degree of incestuous relationships that
might be possible here.

You use perl5 do do the parsing into OP trees.

You write the compiler in perl, using a C module to gain access to
the OP trees so they can be compiled.

You generate C code as the target of your compiler (rather than
targetting a specific machine).

In fact, you don't just generate any old C code, you generate
an XSUB module as the target of your compiler (that way, you
are sure to have access to any of the runtime support routines
you need from perl).

Once you write the XSUB out of the compiler, you might as well
go ahead and run make to build the module so you can then dynamically
load it :-).

But don't stop there! Write a filter module you can use that
automatically compiles and loads everything else in your program.
Throw in a "use compile;" and your code is 10 times faster :-).

Aaaiiieeee! Its not perl! Its a common lisp environment!

I hope everyone else's brain now hurts as much as mine :-).
--
Tom.Horsley@mail.hcsc.com
Home: 511 Kingbird Circle Delray Beach FL 33444
Work: Harris Computers, 2101 W. Cypress Creek Rd. Ft. Lauderdale FL 33309
Support Project Vote Smart! They need your support in non-election years too!
(email pvs@neu.edu, 1-800-622-SMART, http://www.vote-smart.org)
Re: Perl Compiler [ In reply to ]
tom at amber
Dec 12, 1995, 11:59 AM
Post #3 of 7 (208 views)
Permalink
>The much enhanced xsubpp that will come with 5.002 (thanks to Paul
>Marquess) now supports structs which sould make implementing this
>module *much* easier.
>
>This approach would make prototyping a perl compiler in perl practical.
>
>The Perl::OP module would also be a *very* handy start to the other
>'compiler' approach mentioned in the module list text above. And for
>that I'd be very grateful.

You know, putting all these concepts together in one note like this has
caused my mind to boggle at the degree of incestuous relationships that
might be possible here.

You use perl5 do do the parsing into OP trees.

You write the compiler in perl, using a C module to gain access to
the OP trees so they can be compiled.

You generate C code as the target of your compiler (rather than
targetting a specific machine).

In fact, you don't just generate any old C code, you generate
an XSUB module as the target of your compiler (that way, you
are sure to have access to any of the runtime support routines
you need from perl).

Once you write the XSUB out of the compiler, you might as well
go ahead and run make to build the module so you can then dynamically
load it :-).

But don't stop there! Write a filter module you can use that
automatically compiles and loads everything else in your program.
Throw in a "use compile;" and your code is 10 times faster :-).

Aaaiiieeee! Its not perl! Its a common lisp environment!

I hope everyone else's brain now hurts as much as mine :-).
--
Tom.Horsley@mail.hcsc.com
Home: 511 Kingbird Circle Delray Beach FL 33444
Work: Harris Computers, 2101 W. Cypress Creek Rd. Ft. Lauderdale FL 33309
Support Project Vote Smart! They need your support in non-election years too!
(email pvs@neu.edu, 1-800-622-SMART, http://www.vote-smart.org)
Re: Perl Compiler [ In reply to ]
tom at amber
Dec 12, 1995, 11:59 AM
Post #4 of 7 (210 views)
Permalink
>The much enhanced xsubpp that will come with 5.002 (thanks to Paul
>Marquess) now supports structs which sould make implementing this
>module *much* easier.
>
>This approach would make prototyping a perl compiler in perl practical.
>
>The Perl::OP module would also be a *very* handy start to the other
>'compiler' approach mentioned in the module list text above. And for
>that I'd be very grateful.

You know, putting all these concepts together in one note like this has
caused my mind to boggle at the degree of incestuous relationships that
might be possible here.

You use perl5 do do the parsing into OP trees.

You write the compiler in perl, using a C module to gain access to
the OP trees so they can be compiled.

You generate C code as the target of your compiler (rather than
targetting a specific machine).

In fact, you don't just generate any old C code, you generate
an XSUB module as the target of your compiler (that way, you
are sure to have access to any of the runtime support routines
you need from perl).

Once you write the XSUB out of the compiler, you might as well
go ahead and run make to build the module so you can then dynamically
load it :-).

But don't stop there! Write a filter module you can use that
automatically compiles and loads everything else in your program.
Throw in a "use compile;" and your code is 10 times faster :-).

Aaaiiieeee! Its not perl! Its a common lisp environment!

I hope everyone else's brain now hurts as much as mine :-).
--
Tom.Horsley@mail.hcsc.com
Home: 511 Kingbird Circle Delray Beach FL 33444
Work: Harris Computers, 2101 W. Cypress Creek Rd. Ft. Lauderdale FL 33309
Support Project Vote Smart! They need your support in non-election years too!
(email pvs@neu.edu, 1-800-622-SMART, http://www.vote-smart.org)
Re: Perl Compiler [ In reply to ]
tom at amber
Dec 12, 1995, 11:59 AM
Post #5 of 7 (208 views)
Permalink
>The much enhanced xsubpp that will come with 5.002 (thanks to Paul
>Marquess) now supports structs which sould make implementing this
>module *much* easier.
>
>This approach would make prototyping a perl compiler in perl practical.
>
>The Perl::OP module would also be a *very* handy start to the other
>'compiler' approach mentioned in the module list text above. And for
>that I'd be very grateful.

You know, putting all these concepts together in one note like this has
caused my mind to boggle at the degree of incestuous relationships that
might be possible here.

You use perl5 do do the parsing into OP trees.

You write the compiler in perl, using a C module to gain access to
the OP trees so they can be compiled.

You generate C code as the target of your compiler (rather than
targetting a specific machine).

In fact, you don't just generate any old C code, you generate
an XSUB module as the target of your compiler (that way, you
are sure to have access to any of the runtime support routines
you need from perl).

Once you write the XSUB out of the compiler, you might as well
go ahead and run make to build the module so you can then dynamically
load it :-).

But don't stop there! Write a filter module you can use that
automatically compiles and loads everything else in your program.
Throw in a "use compile;" and your code is 10 times faster :-).

Aaaiiieeee! Its not perl! Its a common lisp environment!

I hope everyone else's brain now hurts as much as mine :-).
--
Tom.Horsley@mail.hcsc.com
Home: 511 Kingbird Circle Delray Beach FL 33444
Work: Harris Computers, 2101 W. Cypress Creek Rd. Ft. Lauderdale FL 33309
Support Project Vote Smart! They need your support in non-election years too!
(email pvs@neu.edu, 1-800-622-SMART, http://www.vote-smart.org)
Re: Perl Compiler [ In reply to ]
pmarquess at bfsec
Dec 12, 1995, 5:49 PM
Post #6 of 7 (207 views)
Permalink
From: Tim Bunce <Tim.Bunce@ig.co.uk>
>
...
>
> The much enhanced xsubpp that will come with 5.002 (thanks to Paul
> Marquess) now supports structs which sould make implementing this
> module *much* easier.

I think that should read, "the much enhanced xsubpp which will come
with a future version of Perl. An alpa version is available which now
supports structs...".

I don't think the struct stuff is likely to make it into 5.002, unless
its release is delayed for another few months.

Paul
Re: Perl Compiler [ In reply to ]
epeschko at animas
Dec 12, 1995, 7:48 PM
Post #7 of 7 (208 views)
Permalink

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal