Re: [Proposal] JIT, exec core, threads, and architectures

[Jeff Clites]

On Oct 17, 2004, at 3:18 AM, Leopold Toetsch wrote:
Jeff Clites wrote:
On Oct 16, 2004, at 4:47 AM, Leopold Toetsch wrote:
Nethertheless we have to create managed objects (a Packfile PMC) so 
that we can recycle unused eval-segments.
True, and some eval-segments are "done" as soon as they run (eval "3 + 
4"), whereas others may result in code which needs to stay around (eval 
"sub {....}"), and even in the latter case not _all_ of the code 
generated in the eval would need to stay around. It seems that it may 
be hard to determine what can be recycled, and when.

And we have to protect the packfile dictionary with mutexes, when this 
managing structure changes i.e. when new segments gets chained into 
this list or when they get destroyed.
Yes, though it's not clear to me if all eval-segments will need to go 
into a globally-accessible dictionary. (e.g., it seems the "3 + 4" case 
above would not.)

OTOH it might be better to just toss all the constant table access 
in all instructions, except:

   set_n_nc
   set_s_sc
   set_p_pc   # alias set_p_kc
This would reduce the interpreter size significantly (compare the 
size of core_ops_cgp.o with core_ops_cg.o).
Reducing the size is good, but this doesn't overall reduce the number 
of accesses to the constant table, just changes which op is doing 
them.
Not quite, e.g:
   set P0["foo"], "bar"
   set S0, P0["foo"]
are 3 accesses to the constant table. It would be
   set S1, "foo"
   set S2, "bar"
   set P0[S1], S2
   set S0, P0[S1]
with 2 accesses as long as there is no pressure on the register 
allocator.
Sure, but you can do this optimization today--narrowing it down to just 
those 3 ops isn't required. But it only helps if local re-use of the 
same constants is frequent, and it may not be. (But still, it's a good 
optimization for a compiler to implement--it just may not have a huge 
effect.)

Also, there's some subtlety. This:
        set S1, "foo"
        set S2, "foo"
isn't the same as:
        set S1, "foo"
        set S2, S1
but rather:
        set S1, "foo"
        clone S2, S1
since 'set' copies in the s_sc case. (That's not a problem, just 
something to keep in mind.)

The assembler could still allow all constant variations of opcodes 
and just translate it.
For this we'd need a special register to hold the loaded constant, so 
that we don't overwrite a register which is in use.
No, just the registers we have anyway,
For PIR yes, but the PASM assembler can't know for sure what register 
would be safe to use--the code could be using its own obscure calling 
conventions.

JEff