Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[perl #41955] [PATCH] Yet Another PIR -- in C

1 view
Skip to first unread message

Klaas-Jan Stol

unread,
Mar 21, 2007, 5:53:24 PM3/21/07
to bugs-bi...@rt.perl.org
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #41955]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41955 >


hi,

as requested by particle to send this to the list, attached a patch of
an implementation of PIR in C. Instead of using a bottom-up parser
(using Yacc), this is a pure-C top-down approach.

It is explicitly not my goal to do superfluous work, or to distract you
from working on More Important Things, but I send this, as mentioned on
request.
Of course, it's not finished yet, but a lot is working already (please
note it's only parsing).

THe current implementation of PIR, IMCC, is a bit hacky and not very
clean. Moreover, it's not reentrant. This patch tries to resolve this,
and tries to define what PIR should look like (no hacky things allowed
anymore).

Also, I wrote it to see how far I would come, and whether a top-down
approach was feasible. Also, considering that IMCC's parser's object
file is about 180 KB, and this one only about 35 KB (not the executable,
which includes the C lib.) is a good sign. (I know, IMCC does a lot more...)

Anyway, comments are most certainly welcome.
regards,
klaas-jan

PIRC.patch

Joshua Isom

unread,
Mar 22, 2007, 3:55:27 AM3/22/07
to perl6-i...@perl.org, bugs-bi...@rt.perl.org
Two quick questions, what "hackish" things in pir are you refering to,
and how much more do you think it would take to get bytecode working?
Also, consider that file size alone is not the best indicator of how
well something is programmed, as sometimes a bigger object file is
faster than a smaller one(the difference between macros and functions
is an example).

PIR does have an unimplemented #line operator as does c and perl. If
you include support for it as well, you could consider doing macros and
includes with a preprocessor instead of in the parser itself. It might
make support for certain things easier. But a caveat of that is
handling something like '.Foo(")")' which requires an understanding of
PIR.

Klaas-Jan Stol

unread,
Mar 22, 2007, 5:57:27 AM3/22/07
to Joshua Isom, perl6-i...@perl.org, bugs-bi...@netlabs.develooper.com
Hi,

Joshua Isom wrote:
> Two quick questions, what "hackish" things in pir are you refering to,
> and how much more do you think it would take to get bytecode working?

First of all, my words might have been to harsh. It is certainly not my
goal to step any toes and criticize IMCC. So my apologies if I sound too
critical. However, the sourcefiles of IMCC contain several TODOs, FIXMEs
and Notes indicating that things should be changed in the future.

Working bytecode: I don't know exactly. I guess it shouldn't be too hard
to put in the actions from the yacc file into a new parser, but it's not
trivial I think.


> Also, consider that file size alone is not the best indicator of how
> well something is programmed, as sometimes a bigger object file is
> faster than a smaller one(the difference between macros and functions
> is an example).

That's true. (I was thinking a bit of cache memory, but I'm no expert on
that kind of things)

An example of some code not accepted by IMCC, but something that would
be very useful is this:

foo(<<'CODE', <<'OUTPUT')
...
CODE
...
OUTPUT

because IMCC can only parse 1 heredoc per statement. Of course, the docs
indicate this, so it is "according to spec.", but that does not mean
"according to the user's wishes".

Again, it's not my goal to criticize imcc, but it does have its bugs and
it might be nice to have a look at some alternatives.


>
> PIR does have an unimplemented #line operator as does c and perl.

I think this was implemented some time ago.

thanks for your feedback.
regards,
klaas-jan

Klaas-Jan Stol

unread,
Mar 22, 2007, 6:12:23 AM3/22/07
to Joshua Isom, perl6-i...@perl.org, bugs-bi...@netlabs.develooper.com
Hi again,

attached a new patch, the old one duplicated all files. Please ignore
that one.

(I also fixed the .include directive, should be working now)

regards,
kjs

PIRC.patch

Allison Randal

unread,
Mar 22, 2007, 3:03:59 PM3/22/07
to perl6-i...@perl.org
Klaas-Jan Stol (via RT) wrote:
>
> as requested by particle to send this to the list, attached a patch of
> an implementation of PIR in C. Instead of using a bottom-up parser
> (using Yacc), this is a pure-C top-down approach.

This is quite cool! Keep us updated as you continue working on it.

I'm happy to host it in compilers/pirc/ as an experiment-in-progress. If
you check it in, take advantage of Parrot's Makefile substitutions so
people don't have to manually modify the Makefile for Linux. And
standardize on Parrot conventions like a t/ directory instead of test/.

Thanks!
Allison

0 new messages