classes/*.c is created by the bytecode compiler classes/pmc2c2.pl. Most of the actual code is in lib/Parrot/Pmc2c.pm.
The created C code could need some improvements:
* the temp_base_vtable should be const. This is currently not possible, because items like ".whoami" are changed in the temp_base_vtable. But we don't have to do that, as the vtable is cloned a few lines below anyway. So we should create a const table and do the rest of the init stuff in the cloned table.
* same with the MMD init table.
* All constant strings in classes (whoami, isa_str, does_str) and method names in the delegate.c should use the CONST_STRING() macro. That would need some Makefile tweaks too, to add a dependency on the .str file. Note: foo = CONST_STRING(interpreter, "foo"); should always be on it's own line and not inside a multiline expression.
On Fri, Oct 29, 2004 at 05:47:55PM +0200, Leopold Toetsch wrote: > classes/*.c is created by the bytecode compiler classes/pmc2c2.pl. Most > of the actual code is in lib/Parrot/Pmc2c.pm.
> The created C code could need some improvements:
Can I add a fourth - one I said to Dan I intended to do, but so far haven't managed:
* The created C code could benefit from #line directives to track where C code came from the input .pmc file, so that compiler errors are reported for the original .pmc file. Perl 5's xsubpp does this well, using #line directives to switch between foo.c and foo.xs, depending on whether that section of code was human written, or autogenerated. It makes things much easier while developing.
Of course, I may find time to do this before anyone else does, but anyone is welcome to beat me to it.
Nicholas Clark <n...@ccl4.org> wrote: > On Fri, Oct 29, 2004 at 05:47:55PM +0200, Leopold Toetsch wrote: >> classes/*.c is created by the bytecode compiler classes/pmc2c2.pl. Most >> of the actual code is in lib/Parrot/Pmc2c.pm.
>> The created C code could need some improvements: > Can I add a fourth - one I said to Dan I intended to do, but so far haven't > managed: > * The created C code could benefit from #line directives to track where > C code came from the input .pmc file, so that compiler errors are reported > for the original .pmc file. Perl 5's xsubpp does this well, using #line > directives to switch between foo.c and foo.xs, depending on whether that > section of code was human written, or autogenerated. It makes things much > easier while developing.
Yep, thanks. The hooks are there, as well as a command-line option to turn line numbers off, which is sometimes useful.
Anyway most line number stuff is already inside, but it's broken and needs fixing.
> Of course, I may find time to do this before anyone else does, but anyone > is welcome to beat me to it.
> Nicholas Clark <n...@ccl4.org> wrote: >> On Fri, Oct 29, 2004 at 05:47:55PM +0200, Leopold Toetsch wrote:
>> * The created C code could benefit from #line directives to track >> where >> C code came from the input .pmc file, so that compiler errors are >> reported >> for the original .pmc file. Perl 5's xsubpp does this well, using >> #line >> directives to switch between foo.c and foo.xs, depending on whether >> that >> section of code was human written, or autogenerated. It makes >> things much >> easier while developing.
> Yep, thanks. The hooks are there, as well as a command-line option to > turn line numbers off, which is sometimes useful.
> Anyway most line number stuff is already inside, but it's broken and > needs fixing.
FYI I'm fiddling with classes/pmc2c2.pl, in connection with your ccache-ish "feature request", but I'm not (much) touching Pmc2c.pm, so I shouldn't conflict with anyone working there.
Leopold Toetsch wrote: > classes/*.c is created by the bytecode compiler classes/pmc2c2.pl. Most > of the actual code is in lib/Parrot/Pmc2c.pm.
> The created C code could need some improvements:
> * the temp_base_vtable should be const. > This is currently not possible, because items like ".whoami" are > changed in the temp_base_vtable. But we don't have to do that, as the > vtable is cloned a few lines below anyway. So we should create a const > table and do the rest of the init stuff in the cloned table.
> * same with the MMD init table.
> * All constant strings in classes (whoami, isa_str, does_str) and method > names in the delegate.c should use the CONST_STRING() macro. That would > need some Makefile tweaks too, to add a dependency on the .str file. > Note: foo = CONST_STRING(interpreter, "foo"); should always be on it's > own line and not inside a multiline expression.
Patch attached.
Note: previously base_type for dynclasses was set twice in dynclasses. I'm not clear why this was done. If this is important, this will need to be restored; but without it dynclasses/dynfoo.pasm passes anyway.
> Is there a specific reason that dynamically loaded libs don't use > CONST_STRING()?
At the moment, each interpreter has exactly one const_cstring_table, and there is no string_register function. Additionally, c2str.pl would need to maintain a separate all_cstring.str file per library.
>> Is there a specific reason that dynamically loaded libs don't use >> CONST_STRING()? > At the moment, each interpreter has exactly one const_cstring_table, and > there is no string_register function. Additionally, c2str.pl would need > to maintain a separate all_cstring.str file per library.
Ah of course. I tend to forget that CONST_STRING doesn't really construct a constant STRING object in the constant segment as it did with the first approach.
