[Yhc] how stable is yhc?

[Kartik Vaddadi]

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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.pdf
Type: application/pdf
Size: 12109 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/yhc/attachments/20060914/2113ee12/example-0001.pdf