Re: Q: newsub opcodes

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"

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