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"
A complex PMC could be
.pmc_constant .Complex, "2+3i"
Putting PMC constants into the constant table isn't the problem here, nor changing the format on disc to use freeze/thaw, the construction of more or less arbitrary PMC constants needs some thoughts.
We could probably just define that the C<new_extended> vtable of a class is responsible for constructing an appropriate object from a given string. And that get's frozen to bytecode.
[ 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. When running "add_i_ic" or "new_p_ic". we have to know, whether the integer is inlined or in the constant table. For RISC cpus JIT code a constant table is better even for integers.
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.
When we now have only: add_p_p_p we'd get: add_p_p_pc add_p_pc_p add_p_pc_pc additionally.
We'll start blowing caches. The code get's too big (think compile problems with CGoto). JIT maintainers have to support all these opcodes.
Please consider to reduce constant usage to 4 opcodes:
set_i_ic set_n_nc set_s_sc set_p_pc
(yes, that imposes a bit more pressure on the register allocator, but these constants are reloadable all the time and don't need spilling)
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 ;)
We'll do yet another fixup and I really like the idea WRT PMC types.
leo
