Re: Q: newsub opcodes

At 10:17 PM +0200 10/29/04, Leopold Toetsch wrote:
> Dan Sugalski wrote:
> > At 4:36 PM +0200 10/29/04, Leopold Toetsch wrote:
>
> > > Well, they are implemented, at least partly. Sub PMCs are in the
> > > constant table. The funny C<get_sub> "opcode" is actually a ...
> > >
> > > >  set_p_pc op.
> > >
> > >
> > > ... with the small difference, that at compile time, the integer
> > > argument is a label (offset).
> >
> >
> > Then we should toss the difference and have a single op to access 
> > the PMC constant table.
>
> I'm all for that. We just need set_p_pc. OTOH we need some syntax 
> bits, what this PMC constant in "_pc" denotes and how it's 
> constructed. For subroutine PMCs it's quite simple: the subroutine 
> label is defining the Sub PMC. So its probably something like:
>
>   .pmc_constant .Sub, "foo"

For now I'm fine with restricting it to sub PMCs and opening it up to 
more later. :)

> [ integer constants ]
>
> > More like what we do right now with all the other constant types.
>
> Ah, sounds good.
>
> > Integers aren't in a constant table since we just inline them, but 
> > the nice thing about a constant table is you can do fixups on it 
> > while not touching the actual bytecode, leaving it readonly and 
> > mmapped and all that.
> >
> > While I'd prefer to leave integers inlined in general, having an 
> > integer section of the constant table that can be accessed when 
> > necessary makes the things that need integer fixup easier.
>
> Well, we can't have both schemes coexisting.

Right, and I don't think it's a good idea to switch out from what we 
have now. For integer constants I think we ought to have an explicit 
op for fetching them:

   getconstant Ix, Iconstantnumber

or something like that. We can have a corresponding setconstant op 
for constants that... aren't. And for code to set up the constant 
table in the first place.

> And having integer constants in the constant table would open the 
> path to compile an INTVAL=64bit configuration on a 32-bit machine, 
> where opcode_t is 32 bits.
>
> That leads again to my warnocked proposal to just toss all variants 
> of opcodes that have constants too. With all possible PMC constants 
> in the constants table, we get another (estimated) times two opcode 
> count increase.
>
> Please consider to reduce constant usage to 4 opcodes:

I have, and no. (though we can toss all the two-constant I, S, and N 
forms) We leave things as-is. When we run up to our 1.0 release we 
can run some analysis on the different compilers to see what ops 
aren't being used and pare out the list at that point

> > And yeah, this imples that our constant table isn't necesasrily 
> > constant. I'm OK with that, though. :)
>
> Well, constant Sub PMCs have already offsets relative to their code 
> segment in the PBC. On loading the segment, this gets converted to 
> absolute code addresses. Forget the constantness of constant 
> segments ;)

:) Works for me. I want to revisit packfile formats and whatnot again 
soon anyway -- I want us to start adding in source line number & 
source lines to the packfiles and have it available as we run so we 
can start throwing more informative error messages and making the 
debugger more useful.
--
                                Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
dan@xxxxxxxxx                         have teddy bears and even
                                      teddy bears get drunk