Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion PMC constants
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Dan Sugalski  
View profile  
 More options Apr 19 2004, 2:48 pm
Newsgroups: perl.perl6.internals
From: d...@sidhe.org (Dan Sugalski)
Date: Mon, 19 Apr 2004 14:35:26 -0400
Local: Mon, Apr 19 2004 2:35 pm
Subject: Re: PMC constants
At 4:39 PM +0200 4/16/04, Leopold Toetsch wrote:

>While trying to speed up hash lookups [1] I came (again) to the
>problem that we are missing true PMC constants. We just have a
>special Sub PMC for storing subroutine entries but no general way to
>represent a constant PMC item. E.g.:

>    .const pmc s = "value"
>    .const pmc i = 1
>    ...
>    add $P0, i
>    setprop $P0, "xxx", s

>This would AFAIK not need a lot more opcode variants, because where
>we now have C<add_p_ic> and C<add_p_nc>, we would then just have
>C<add_p_pc>[2]. Only some ops that take PMCs only would need
>additional variants like setprop_p_sc?_pc.
>I'm currently thinking of constant scalar PMCs only, but this could
>get generalized to constant aggregates too.

I'm all for constant PMCs--they've been in the base design since the
beginning, and I'd love to get them in and running.

The interpreter stuff's simple enough--we teach the ops preprocessor
to handle them the same way that it does string constants, and index
into the PMC constant table. We'll want to put them in a separate
part of the bytecode file, so we probably ought to nail down metadata
so we can fully expose bytecode files to running code. And we need to
finish that fight over freeze/thaw methodologies, as constant PMCs
would end up being frozen in the bytecode.

As for the actual declaration of the constants... That's going to be
somewhat interesting. I can see one of two ways of doing it:

1) we execute the initialization code at compiletime and freeze the result
2) We compile the initialization code and execute it at runtime to
create the PMC

Both have their drawbacks when it comes to more complex PMCs. For
simple stuff it's not a big deal one way or the other, and for the
base PMC types we can even cheat and teach imcc how to create the
freeze format directly, but that's not tenable as a full solution.
--
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.