Michael L Maraist wrote:
> The only "memory" storage for scalars that I currently am conceiving of is
> in name-space stashes (globals). Thus our most likely implementation of S2S
> would be to have 'add "g_x", "g_y", "g_z"' which performs two stash
> lookups, an add, then one stash write.
Kakapo currently uses:
.global G:$x
.global G:$y
.global G:$z
add G:$x, G:$y, G:$z
The assembler translates this to:
add [1:0], [1:1], [1:2]
The operands are in [frame:offset] notation. Global variables always
appear in frame #1. Symbol table lookup is done at compile time.
Run-time uses the same addressing mode to fetch globals as it does
to fetch locals.
There isn't any aliasing mechanism -- I'm not sure if Perl 6 bindings
are going to require VM aliasing support or not. Even without aliasing,
somebody can still do by-name lookups: (hand-waving here)
lookup L0, "$x"
That doesn't alias L0 to G:$x -- it copies the value of G:$x into
L0. (Note that PMCs act like pointers anyways, so if G:$x is a PMC,
then L0 is effectively an alias. That wouldn't be true if G:$x
was a machine int.)
> How does the GC sweep across a huge VM heap (as opposed to walking
> the register / stash maps).
It simplifies things because the root set is just the frame display
and inactive regions of the display that have been pushed onto the
stack. Since there aren't any registers or register stacks, all
traversals are done on a single data structure -- a frame.
> I spoke exclusively on scalars (PMCs) because I had an interesting time
> considering static datatypes. It's obvious what happens when we declare:
> for my int $idx ( 0 .. 100 ) {
> }
> We get an integer register variable which maps directly to add / extraction
> calls.
Maybe. You might get a strongly-typed PMC depending on how the body
of the code uses $idx. (Dan has said that Perl 6 functions will take
a list of PMCs as arguments. If $idx gets passed to a sub, you'll
need to create a scratch PMC out of that integer register.)
Capturing a closure inside the loop might also affect how $idx is
allocated.
> But what about:
>
> our int $g_idx;
You're asking how Parrot will do this? I don't think Dan's told us yet.
In Kakapo's case, the compiler just assigns a spot in the
scope definition. When the scope is entered, a frame is created
large enough to hold all the variables. A single frame holds
many types -- the only difference between "our int $g_idx" and
"our $g_idx" is how the space in the frame is initialized.
- Ken
