[Yhc] how stable is yhc?

Neil Mitchell ndmitchell at gmail.com
Thu Sep 14 16:12:48 EDT 2006


Hi,

Very interesting. I believe that the original version of Hat (way back
in the past) did this, but the move to a file trace was needed because
of a lack of memory. I guess now that memory is much cheaper and
larger, this is possibly useful once more.

As for your issue of stability, now that you have defined your
project, I'm much more confident to say Yhc is definately the vehicle
of choice. There are lots of projects that play with the bytecode -
convert to .NET, interpret in Python/Java, convert to register
machine, libraries for manipulation in Haskell etc.

As for garbage collection, just turning it off will probably get you
quite far. You might need to do some work to tie the original code
back to the interpretted stuff (desugaring complicates some things),
but some of this work has been done by Tom for the Hat stuff.

Thanks

Neil

On 9/14/06, Kartik Vaddadi <itskartik at iitb.ac.in> wrote:
> Neil Mitchell wrote:
>
> > If you want to modify the runtime of one of Yhc and nhc, then Yhc is
> > really the sensible choice! The nhc runtime is mashed into the program
> > and compiled as one chunk of (not very nice looking) C. The Yhc
> > runtime is entirely separate doing runtime bytecode interpretation -
> > making it much much easier to play with.
>
> Thank you. That (and Tom's comments) really cleared up the issue for me.
> I'm almost certain Yhc is the right choice.
>
> > Also, can you give us any information on your debugging stuff, since
> > Yhc already supports some debugging stuff related to Hat in the
> > bytecode - it would be interesting to see how your stuff differs.
>
> This is how my debugger works: Rather than logging information to a file
> as the program runs (like HOOD) or generating the redex trail as a
> separate data structure in memory (which I believe Hat does; please
> correct me if I'm wrong), we use the YHC/NHC heap itself as the
> Evaluation Dependence Tree. We change the virtual machine so that when a
> function returns, just before the root of the tree representing the
> redex is overwritten by an indirection node to the root of the result
> tree, we keep a backup copy of the word that is overwritten. Also, the
> garbage collector is disabled so that indirection nodes are not
> eliminated. In addition, the top of stack in the caller (immediately
> after the return) will be a pointer to the redex node rather than the
> result. The attached slide gives an example of some of this; please look
> at it.
>
> When the VM during evaluation (or the debugger) examines such a node (a
> node representing a function application that finished evalution), it
> follows the indirection and everything works as expected -- once a
> function is evaluted, its result is used (rather than the function being
> re-evaluated). But the debugger can look at the saved state and examine
> the redex -- the body of the function that was executed.
>
> We also need a breakpoint instruction to execute step-by-step (or rather
> function-by-function) -- in effect, controlled execution by the user.
>
> Am I correct in assuming that if we want to leave indirection nodes as
> is, there is no work for the garbage collector to do? What about memory
> requirements once the GC is disabled? I believe that the general opinion
> is that memory can be problem, but on computers with say 512 MB memory
> is it still a problem?
>
> I'm not sure how Freja works; I think it keeps a copy of the EDT (as
> it's created) in memory separate from the program's heap, if you
> understand what I mean. Am I correct? In any case it runs only on SPARC,
> and so does not exactly suit my purposes.
>
>
> > Can you describe what you mean as stable? Ability to compile haskell
> > programs? Code change in the runtime? Code change in the compiler?
>
> I'm largely referring to the assumptions I made in the description above
> -- the Eval, Return & ReturnEval instructions, the indirection nodes,
> etc. I think these won't be changing, right? I don't need a Haskell
> implementation that can compile all programs, just enough non-trivial
> ones to demonstrate my work. Things like garbage collection algorithms,
> type checking, etc can change without any problem for me. I think you
> now understand what I mean when I ask about Yhc being stable.
>
>
> Thanks a lot for your time. I eagerly look forward to your comments.
>
>
> --
> Kartik Vaddadi.
>
> Home:                   www.cse.iitb.ac.in/~kart
> Blogs:                  kartik.infogami.com, kartik-log.blogspot.com, kartik-rlog.blogspot.com
> Alternate mail ID:      kartik.vad at gmail.com
>
> "50% Reservation, 100% Politics" - Protest the Indian government's decision to increase reservation in private educational institutions (yfemumbai.blogspot.com)
>
>
>
>


More information about the Yhc mailing list