Re: generic code generator? [was: subroutines and python status]
At 11:09 PM -0400 8/4/03, Michal Wallace wrote: On Tue, 5 Aug 2003, Stephen Thorne wrote: Thus the code generator is best suited to be in a language that can be run from within the parrot machine, otherwise statements like 'eval()' would not be possible without binding parrot to a non-portable C library. I would instead suggest that we pick a suitable 'dynamic' language to write the code generator in, so it can be self-hosting. Sure. That's why I said stick to C or parrot. I'm not sure I understand why C wouldn't be portable... (I don't know c at all but I thought that was the point)?? I'd much rather use parrot. Where parrot means something else compiled down to parrot, and something else means python. :) The original thought was to use the new perl 6 grammar engine/code to do this, but I think it'll be a while before that's ready to go. Rather than invent an entirely new language for this (which is somewhat problematic) why not go for something already reasonably well-known? YACC and BNF grammars seem like a good place to start, especially as most of the languages have some form of grammar defined for them. It's only a first step, as then everyone beats the heck out of the resulting token stream, but it's a place to start. 80-90% of the result will end up being generically parseable as well--x + y will generate the same code for all languages if x and y are PMCs, for example, so I'd bet we could have a lot of standard products designed. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
make install on Win32
Hi, Sorting out make install on Win32 wasn't as simple as I'd first guessed, but I'm getting there. I've now got it outputting 'correct' paths etc for Win32 to the makefile, and tools/dev/install_files.pl piping to command rather than sh on Win32 as well. Now I've hit the next snag - there is no install program under Win32. I see two possible approaches (and await somebody to suggest the third, which will be perfect ;):- 1) Create a Perl script that resembles the functionality of install, then we print:- print perl dev/tools/install.pl -d $_\n; # If there is no install program 2) Write Perl to implement that functionality directly into dev/tools/install_files.pl if the install program is not available. What's the best choice here? Thanks, Jonathan
[perl #23231] [PATCH] dynamic PMCs 1
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #23231]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=23231
Attached is (if it wasn't stripped again ;-) a patch, that allows using
dynamic PMCs.
- pmc2c.pl has a new class flag dynpmc
- these appends a global init function to the class file
- this init function is called twice for setup init
- it may register as many PMCs as it wants
- example: dynclasses/dynfoo.pasm, foo.pmc
TODOs
- Parrot_base_vtables is still a static array, this should better be
allocated, but existing vtables shouldn't move
- Communicating the state between parrot and the shared lib is ugly.
Maybe passing real callback functions would be better.
Or don't have any globals at all: Instead put globals into the first
interpreter, and let other interpreters just point there.
Comments welcome have fun,
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/62310/45923/730b81/dyn_PMCs.patch
--- parrot/MANIFEST Tue Aug 5 10:56:23 2003
+++ parrot-leo/MANIFEST Wed Aug 6 17:41:41 2003
@@ -203,7 +203,9 @@
dotgnu.ops[]
dynclasses/Makefile [devel]
dynclasses/README [devel]
+dynclasses/dynfoo.pasm[devel]
dynclasses/foo.pmc[devel]
+dynext.c []
editor/pasm.el[devel]
editor/pasm.vim [devel]
embed.c []
@@ -1289,6 +1291,7 @@
include/parrot/datatypes.h[devel]include
include/parrot/debug.h[devel]include
include/parrot/dod.h [devel]include
+include/parrot/dynext.h [devel]include
include/parrot/embed.h[devel]include
include/parrot/encoding.h [devel]include
include/parrot/enums.h[devel]include
--- parrot/classes/pmc2c.pl Thu Jul 31 21:07:07 2003
+++ parrot-leo/classes/pmc2c.pl Wed Aug 6 17:40:06 2003
@@ -59,7 +59,7 @@
=item 2.
-pmclass PMCNAME [extends PMCNAME] [abstract] [extension] [noinit] {
+pmclass PMCNAME [extends PMCNAME] [abstract] [dynpmc] [noinit] {
=item 3.
@@ -587,12 +587,66 @@
$methodlist
};
+ if (!whoami)
whoami = string_make(interp,
$classname, @{[length($classname)]}, 0, PObj_constant_FLAG, 0);
Parrot_base_vtables[entry] = temp_base_vtable;
$class_init_code
}
+EOC
+ }
+
+ if (exists $flags{dynpmc}) {
+ my $lc_classname = lc $classname;
+ $OUT .= EOC;
+/*
+ * This init function will be called to setup/init/whatever
+ * is needed to get this extension running
+ */
+#include parrot/dynext.h
+
+int Parrot_dynext_${lc_classname}_init(Interp *interp, int action, void *param)
+{
+dynext_pmc_info_t *info = (dynext_pmc_info_t*) param;
+int ok;
+int i;
+
+/*
+ * These are globals. As the shared lib is linked against libparrot
+ * the shared libs has its own globals, so we must initialize these
+ * yep, that's ugly
+ */
+for (i = 1; i *(info-class_max); i++)
+ Parrot_base_vtables[i] = info-base_vtable[i];
+enum_class_max = *info-class_max;
+switch (action) {
+ case DYNEXT_SETUP_PMC:
+ string_init(); /* default type/encoding */
+ /* one time setup code */
+
+ /* for all PMCs we want to register:
+*/
+ if (!whoami)
+ whoami = string_make(interp,
+ $classname, @{[length($classname)]}, 0,
+ PObj_constant_FLAG, 0);
+ info-class_name = whoami;
+ ok = Parrot_dynext_setup_pmc(interp, info);
+ $initname(interp, info-class_enum);
+ /* set our class enum */
+ Parrot_base_vtables[info-class_enum].base_type = info-class_enum;
+ /* copy vtable back to caller */
+ info-base_vtable[info-class_enum] =
+ Parrot_base_vtables[info-class_enum];
+ return ok;
+ case DYNEXT_INIT_PMC:
+ /* per interpreter/thread init code */
+ return Parrot_dynext_init_pmc(interp, info);
+}
+return DYNEXT_INIT_ERR;/* error, unsupported action */
+}
+
EOC
}
--- parrot/config/gen/core_pmcs.pl Thu Jul 3 12:04:47 2003
+++ parrot-leo/config/gen/core_pmcs.pl Wed Aug 6 10:58:29 2003
@@ -33,7 +33,7 @@
print OUT enum_class_default,\n;
print OUT enum_class_$_,\n foreach (@pmcs);
print OUT END;
-enum_class_max
+enum_class_core_max
};
/* end_gen */
--- parrot/config/gen/makefiles/root.in Mon Jul 28 00:35:45 2003
+++ parrot-leo/config/gen/makefiles/root.in Wed
repeat() not implemented in PerlInt
After running cvs up -d and then make, a bunch of my tests broke. Here's the problem boiled down to the simplest case I can find: [~/pirate]: cat bug.imc .sub __main__ $P2 = new PerlInt $P2 = 1 $P3 = new PerlInt $P3 = 1 if $P2 == $P3 goto cmp1 cmp1: end .end [~/pirate]: imcc bug.imc repeat() not implemented for PerlInt What happened!? :) Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
This Week's Perl 6 Summary
Perl 6 Summary for the week ending 20030703 Ooh look, it's another Perl 6 summary. Doesn't that man ever take a holiday? I think he took one last month. Is it in Esperanto this week? I don't think so. Does Leon Brocard get a mention? It certainly looks that way. Does it start with the internals list again? I think it does, in fact, here it comes now. Approaching Python Discussions (and coding) of the Parrot implementation of Python continued this week. Michal Wallace is working on taking a preexisting (but incomplete, it's a proof of concept only) python parse tree - parrot code generator and rejigging it to generate code for IMCC. Assuming the initial rejig is doable, Michal surmises that getting a complete python compiler will be 'just' a matter of fleshing out the rest of the visitor methods, 'and then dealing with the C-stuff.' Actually, the main strand of this discussion dealt with ways of extending IMCC to help optimize the translation of stack based code to code that uses registers more efficiently (register unspilling as Benjamin Goldberg called it), which should help with any bytecode translator based efforts. http://xrl.us/crudf http://xrl.us/crukq Semantics of clone for PIO-objects Jürgen Bömmels' work on the Parrot IO system continues to find edge cases in Parrot's memory management subsystem. As initially written, a clone call adds a reference to a ParrotIO object, but that object is neither garbage collected nor refcounted, and it gets destroyed when its first reference is destroyed. The problem can be solved by allocating a new ParrotIO in the clone call, but Jürgen had some questions about how to handle various things like what to do with buffering or position pointers. Jos Visser offered a suggestion involving indirection and reference counting which met with (at least) Melvin Smith's approval. http://xrl.us/crusx Making 'make' less verbose Leo Tötsch checked in a patch to make make's output rather less verbose. After the patch, the make process only echos the name of the file being compiled, and doesn't spam your terminal with the entire compiler commandline (the compiler warnings do that). Some people liked this. Others didn't. http://xrl.us/cruz5 Don't trace system areas in sweep ops One of the things we discussed at the Parrot BOF was how to solve the 'bogus objects' problem when doing timely destruction sweeps (The 'bogus objects' problem is when the stack walk code detects chimerical objects through holes in the C stack (hmm... if anyone has a good drawing of this?)). After much discussion we came to the conclusion that the trick was to only walk the system stack during DOD (Dead Object Detection) runs that got triggered via resource starvation. This works because There is nothing unanchored and alive beyond the runloop's stack. Brent Dax was impressed, but then, he wasn't at the BOF so he doesn't know how long it took us to get to the answer. http://xrl.us/cru73 User defined events Klaas-Jan Stol wondered if there would be some way of generating and posting user defined events. Uri Guttman thought that there probably would be. http://xrl.us/crviz PHP/Parrot The language implementation insanity continues! Stephen Thorne announced that he's working on implementing a PHP parser and is seriously considering targetting Parrot. He asked for pointers to good docs on how to go about doing so. He worried a little about bootstrapping as well. Luke Palmer and Simon Glover were forthcoming with lots of useful answers and pointers. http://xrl.us/crvsa Why Parrot uses Continuation Passing Style In a delayed response to a question from Klaas-Jan Stol, Dan has posted a long message on the reasons for choosing Continuation Passing Style as Parrot's calling convention. It's definitely worth the read if you're at all interested in the reasoning behind Parrot (and the reason that my copy of *Perl 6 Essentials* has a signed correction from Dan). http://xrl.us/crv24 IMCC supports the Parrot Calling Conventions Leo announced that IMCC's brand of assembler, PIR (I can't remember what it stands for, Parrot Intermediate Representation perhaps). Of course, there are things it doesn't quite do yet (tail call detection, only preserving 'necessary' registers...) and it's somewhat lacking on the test front, but it's a start. Yay Leo! http://xrl.us/crv75 Another task for the interested: Coverage Dan threw out another 'task for the interested' this week. At present we don't have a complete set of coverage tests for the parrot opcodes, nor do we even know why opcodes do have coverage. Volunteers to fix this state of affairs (start with a coverage report
