Mostly a Perl task for the interested

Leopold Toetsch

unread,

Oct 29, 2004, 11:47:55 AM10/29/04

to Perl 6 Internals

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.

Thanks,
leo

Nicholas Clark

unread,

Oct 29, 2004, 5:57:57 PM10/29/04

to Leopold Toetsch, Perl 6 Internals

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

Leopold Toetsch

unread,

Oct 30, 2004, 3:58:13 AM10/30/04

to Nicholas Clark, perl6-i...@perl.org

Nicholas Clark <ni...@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

leo

Jeff Clites

unread,

Oct 30, 2004, 7:42:15 AM10/30/04

to l...@toetsch.at, perl6-i...@perl.org, Nicholas Clark

On Oct 30, 2004, at 12:58 AM, Leopold Toetsch wrote:

> Nicholas Clark <ni...@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.

JEff

Sam Ruby

unread,

Oct 31, 2004, 10:26:34 PM10/31/04

to Leopold Toetsch, Perl 6 Internals

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.

- Sam Ruby

const_base_vtable_and_mmd_init.patch

Leopold Toetsch

unread,

Nov 1, 2004, 7:28:44 AM11/1/04

to Sam Ruby, perl6-i...@perl.org

Sam Ruby <ru...@intertwingly.net> wrote:

> Leopold Toetsch wrote:
>>
>> * the temp_base_vtable should be const.

> Patch attached.

Thanks, applied - with s/clone/vt_clone/ to avoid a warning about a
shadowed global.

> + clone->whoami = string_make(interp,
> "$classname", @{[length($classname)]}, "iso-8859-1",
> PObj_constant_FLAG|PObj_external_FLAG);

Is there a specific reason that dynamically loaded libs don't use
CONST_STRING()?

leo

Sam Ruby

unread,

Nov 1, 2004, 10:11:05 AM11/1/04

to l...@toetsch.at, perl6-i...@perl.org

Leopold Toetsch wrote:
>
>>+ clone->whoami = string_make(interp,
>> "$classname", @{[length($classname)]}, "iso-8859-1",
>> PObj_constant_FLAG|PObj_external_FLAG);
>
> 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.

Does this sound about right?

- Sam Ruby

Leopold Toetsch

unread,

Nov 1, 2004, 10:32:47 AM11/1/04

to Sam Ruby, perl6-i...@perl.org

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.

> - Sam Ruby

leo