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
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@gmail.com
"50% Reservation, 100% Politics" - Protest the Indian government's decision to increase reservation in private educational institutions (yfemumbai.blogspot.com)