On Tuesday 30 October 2001 01:47 am, Ken Fox wrote:
> Uri Guttman wrote:
> > that is good. i wasn't disagreeing with your alternative architecture.
> > i was just making sure that the priority was execution over compilation
> > speed.
>
> I use a snazzy quintuple-pass object-oriented assembler written
> in equal parts spit and string (with a little RecDescent thrown in for
> good measure). A real speed demon it is... ;)
>
> The real motivation of my work is to see if a storage-to-storage
> machine ends up using cache better and with less compiler effort
> than a register machine. When I read about CRISP, the first thing
> that came to mind was the "top-of-stack-register-file" could be
> simulated exactly with high-speed cache in a software VM. Dropping
> the stack-machine instructions in favor of Parrot's 3 operand ones
> made it sound even better.
>
This raises an interesting question. PMC's are mighty beasts and can do just
about anything: mutate, store into stashes, perform queries of their
datatype, have embedded lock variables and even have embedded garbage
collecting info. They're work for safe thread-sharing, auto-variables, bla
bla bla.
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. I can't imagine that this would be
faster than using a load/store architecture w/ respect to stash accesess; the
overhead of the multi-level hash-table lookups is much greater than that of
the op-code.
What I think I hear you saying is that S2S would be storing in some sort of
memory frame outside of the register set. But this adds a bunch of
complexity. How does the GC sweep across a huge VM heap (as opposed to
walking the register / stash maps). Further, we'd have to have a notice of
the relative addresses of these objects (aren't they relocatable?). Assuming
the exclusive use of ld/st stash access for globals (which due to the
possibile stash-renaming/remapping, I think this is a fair assumption), then
the only reason for a scalar "scratchboard" would be for lexical locals. But
that could be addressed via an indexible stack, which is probably most
efficient with a load/store architecture anyway (due to the multitude of
stacks).
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. But what about:
our int $g_idx;
What's it's default value? zero? Where does it live? If you allow the
storage of pure integers in a stash, then you'll have to have a stash
structure like this:
struct stash_t {
.....
PMC sv_val;
PMC av_val;
PMC hv_val;
PMC cv_val;
PMC io_val;
...
IV i_val;
NV n_val;
SV str_val;
};
But then when you try and retrieve a global stash symbol, how do you
distinguish between i_val and a sv_val? Or even str_val from sv_val. If
perl6 is pre-compiled with access to all module-code (not likely due to late
binding), then it can be optimized to make special access requests (knowing
the prototype of $i), but this doesn't allow for dynamic modification of the
stash-space. We are, after-all, a high-level language, not "java". Further,
this would be completely unused in perl5 execution.
Best I can figure is that we can't store non PMC's in stashes. Which also
means that we don't store non PMC's anywhere except the stacks; They're thus
purely for lexical values.
Anyway have any vision that conflicts with this?
Back to the original discussion. I'm thusly not seeing a benifit for S2S
here.
-Michael
