Re: Patches for wip-rtl

[Noah Lavine]

Hello,

On Mon, Apr 22, 2013 at 4:39 PM, Andy Wingo <address@hidden> wrote:

Hi :)

Thanks for working on the RTL VM!

Thanks for doing most of the work! I'm happy to help. :-)

 

First of all, sorry about that linker error.  I'm trying to make RTL
programs more debuggable by hacking on the linker, so that it emits
proper debugging information.  I should have caught that typo though!

Debugging would be great. I have thought about stopping this and working on debugging stuff some, but that actually seems harder than what I'm doing now, and I would like to get the compiler working.

 

I think however that the strategy of making the VM somehow more
resilient is not going to work.  There are so many ways that invalid
instructions can make the VM fail -- and you have no idea what you can
rely on if those invariants fail.  So it doesn't seem to me that it's
possible to do that job well at all, and for that reason it seems to me
that we shouldn't try very hard.

I assume you're talking about the box-ref and box-set! stuff with checking for non-variables, right? I agree in general, but those instructions could plausibly be emitted for any code that uses module introspection to get its own variable objects, right?. At that point the not-a-variable error would be a user type error, and so I think it's better to throw wrong-type-arg. (But of course, that's not my real motivation - I just happened to hit this while debugging the compiler.)

And I don't know how you've been able to get as far as you have with the
deplorable state of the debugging infrastructure.  You can't even
disassemble a function you just made!  I'll be working on that this
week; we'll see what happens.

So in summary, dunno.  Surely there is some way we can do things better,
but I wanted to register my skepticism for this line of hacking.  What
do you think?

First of all, I agree that debugging infrastructure would be great. I'm very glad you're working on it - that should help a lot. I'm not sure if I have much to add there right now, but I will keep it in mind.

As for the line of hacking, as I said above, I think in the particular case of box-ref and box-set! it's justified; I don't know in general. I certainly agree that once the VM's internal state is corrupt, all bets are off, and we probably won't be able to continue. One thing that would be interesting - and I don't know if we do this now - is using different VMs for different parts of the code. Specifically, if the REPL ran in a different VM than user code, then the REPL wouldn't die in these cases. That might also enable cool debugging things, like single-stepping the user VM and examining its registers. I noticed that we already have support for changing the active VM. What do you think?

Best,
Noah