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
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
