Re: [epsilon-devel] Questions about Epsilon and call-stack introspection.

[Luca Saiu]

On 2014-01-04 at 17:41, Basile Starynkevitch wrote:

> The big advantage of the list is that others (me included) can
> contribute to it. AFAIK your blog is written by you only (this is ok for
> me, but I won't call that a "blog").

"Blog" just means "web log".  But yes, maybe mine wouldn't qualify for
many people; I don't care too much.  Communication over the web is
inconvenient anyway.

> You could perhaps have a slightly different design. Knowing which local
> variables are accessible at some given Epsilon0 source code handle is
> trivial (your compiler already knows that). You could have the
> convention that every such variable has a fixed offset on the stack (at
> the given source code handle).

That certainly works in a simple implementation, but I don't want to be
*forced* to do that.

Of course my first version will still "spill" everything, not using
registers at all, so e0:call-with-saved-temporaries would be exactly
like call; but at least I'm not limiting my future options.

I think I prefer the proposal in my previous email, but details can be
changed.

> I would believe that you'll need to have some operator (or primitives)
> mapping the machine program counter (i.e. in each call frame) into
> epsilon0 handles (which might be non-trivial if you do loop-unrolling at
> the epsilon0 level, but I thought you'll only do that at epsilon1).

I was actually considering removing handles altogether.  However if we
keep handles, that can be done; it should be easy enough when compiling.
I guess the clean solution would be to use ELF debugging information.
Sure, why not.  We have to store program source information; I don't
have very strong opinions about the choice among handle source locus, or
epsilon0 expressions.

Are you thinking about debugging?  A "partial" interface to GDB (source
locations but no variables) should not be terribly hard.

Yes, "synthetic" epsilon0 expressions has to be assigned a locus in some
meaningful way.  Now that my s-expressions can actually contain loci,
and they will spread to expressions, I'll see how to do that exactly.

> Well, updating a call frame is "removing" the old frame and "inserting"
> the new one... But IIUC you cannot define "insert a frame in the middle
> of the call stack" from the "change call frame" primitive...

The proposal from my previous message makes the whole stack available as
a vector, which then can be updated in any way.  Of course updating a vector
is less efficient if one has to resize a frame followed by many others,
but it can be done.

It would be fun to update the stack by replacing saved return addresses:
we could insert calls to procedures which temporarily replace it with a
different one, or reinstate a previously saved version.  It's doable at
the assembly level, but in epsilon0 it's a little scary.

You're right.  Now I see that one weakness of my proposal is this
inability of updating the return address of an existing frame.  I think
that I want that, and I might need it anyway in order to build frames to
be executed later; not necessarily for call/cc, but possibly for
something similar.
I have to address this.  Can a return site be identified with just a
specific procedure call in the source?  This only becomes messy with
respect to registers holding values from caller frames; that's a pity,
because I liked that optimization.

I fear that chained stack frames are inefficient.  Chained (and
garbage-collected) stack frames were used in SML/NJ at the time of
Andrew Appel's "Compiling with continuations"; but I've read somewhere
that they completely changed the implementation after the book's
publication, for efficiency reasons.


Do you think that destructively update a frame down the stack will be
a common operation?  I don't see the use case.
I think most jumps will be either "downwards", à-la-longjmp, or will be
complete stack replacements, à-la-call/cc.  In the first case the stack
doesn't actually change: only the stack pointer gets smaller; in the
second case the new stack is independent from the old one.

> Well, I thought that your primitives had the (defining & limiting)
> properties that they did not alter the call stack!

Yes, that the case with the current system; in fact in the current
semantics primitives don't receive nor return stacks.  But now you've
convinced me to change the semantics.

> You really should contact Jacques Pitrat (to other readers, see
> http://bootstrappingartificialintelligence.fr/ and
> http://jacques.pitrat.pagesperso-orange.fr/ ...) he knows even better
> than I do why writing the control stack is so important! Of course, you
> and him need to adapt terminology!

Professor Pitrat is Basile's great master, and Basile told me many times
to contact him because of some points of contact between epsilon and his
Artificial Intelligence research.  I've never met him or communicated
with him yet, but one of this days I will write to him.

Thanks again, Basile.  You let me understand the point about return
addresses, which I had missed before.

-- 
Luca Saiu
Home page:   http://ageinghacker.net
GNU epsilon: http://www.gnu.org/software/epsilon
Marionnet:   http://marionnet.org