Hello, On Tue, Apr 23, 2013 at 6:13 AM, Andy Wingo <wi...@pobox.com> wrote:
> Heya, > > On Tue 23 Apr 2013 04:38, Noah Lavine <noah.b.lav...@gmail.com> writes: > > Ah I see what you mean. There are two uses of variables in the VM: one > for calls to variable-ref or variable-set, and the other for internal > use. For the internal uses, we know the variable should indeed be a > variable and so we should emit the checks. For calls to variable-ref / > variable-set, I think it would be best if somehow the compiler could > replace those calls with (if (call variable? x) (primcall box-ref x) > (call error ...)). Dunno. WDYT? > Do we usually omit checks for internal stuff? If so, I agree, we should do that here too. But right now we do the check every time anyway - the only difference my patch made is whether we failed with abort() or vm_error_not_a_variable. I agree that that doesn't make much sense as an error for internal stuff. Maybe change it to vm_error_bad_instruction or something like that for now? In general I agree that we should be able to do nice error checking only for user-generated box-refs, but that seems more complex than we need right now (unless you want to add it to the VM). > > 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? > > We can do that already to a degree... probably the best "fallback" that > we have is the stack VM, actually. What happens if you install traps on > the VM that call stack VM procedures and then you run an RTL function? > I would think that you should be able to do something useful there. > That does sound interesting, but I've never used traps. I've been meaning to learn them some time so I can try to remember tail calls for debugging, but that probably won't be for a little while. Noah
