From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: Patches for wip-rtl Date: Sat, 4 May 2013 21:29:34 -0400 Message-ID: References: <871ua2jo4l.fsf@pobox.com> <87fvyhimha.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec5215ea97b48b904dbee85d1 X-Trace: ger.gmane.org 1367717406 32513 80.91.229.3 (5 May 2013 01:30:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 May 2013 01:30:06 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun May 05 03:30:05 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UYnm6-0000x7-Br for guile-devel@m.gmane.org; Sun, 05 May 2013 03:30:02 +0200 Original-Received: from localhost ([::1]:54812 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYnm5-0001F4-Vq for guile-devel@m.gmane.org; Sat, 04 May 2013 21:30:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42705) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYnm2-0001Ek-1L for guile-devel@gnu.org; Sat, 04 May 2013 21:30:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UYnm0-000380-H9 for guile-devel@gnu.org; Sat, 04 May 2013 21:29:57 -0400 Original-Received: from mail-pd0-f179.google.com ([209.85.192.179]:58326) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYnm0-00037m-7G for guile-devel@gnu.org; Sat, 04 May 2013 21:29:56 -0400 Original-Received: by mail-pd0-f179.google.com with SMTP id q10so1472087pdj.10 for ; Sat, 04 May 2013 18:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=xFKBdmiiR0dP5gGaWE1qvzdt7OMgJCOtlELk5o6UzSQ=; b=jHWcAyR6fY7jKEG3vg3ukpQ540KkBK317ca2t05NwgZRBh52aWari22glXayHq6Q3z M87+TAVvma6OkX92NugeoMP41RLGm8dzejyHHzOrn5sVtGATpDVc+P/4GhU20R+voB1n bmuh+6uLL7MrMy0oyi29fqY3oLLJGen219uuF5WDE8XOjhCSdXn1Q0wCSZtU4dNzZ311 dVE5tGqwfkuNCUa5LJiOywzJDXeuRT15JNsotP007LA09cRQwJqlG05vyNNWGS1W7Qoi uDrXOg7lbP54WfeTERvVLUIvWu8L6tWdAsPexvAzaHKF3t2NQDO4olpvzwJXxa2cm2Uz 26Iw== X-Received: by 10.68.1.34 with SMTP id 2mr6473666pbj.3.1367717394988; Sat, 04 May 2013 18:29:54 -0700 (PDT) Original-Received: by 10.68.7.9 with HTTP; Sat, 4 May 2013 18:29:34 -0700 (PDT) In-Reply-To: <87fvyhimha.fsf@pobox.com> X-Google-Sender-Auth: KWIXTecmVdlD_IoipA4lacUwfY4 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.192.179 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16352 Archived-At: --bcaec5215ea97b48b904dbee85d1 Content-Type: text/plain; charset=ISO-8859-1 Hello, On Tue, Apr 23, 2013 at 6:13 AM, Andy Wingo wrote: > Heya, > > On Tue 23 Apr 2013 04:38, Noah Lavine 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 --bcaec5215ea97b48b904dbee85d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

On Tue, Apr 23, 2013 at 6:13 AM, Andy Wingo <wingo@pobox.co= m> wrote:
Heya,

On Tue 23 Apr 2013 04:38, Noah Lavine <noah.b.lavine@gmail.com> writes:

Ah I see what you mean. =A0There are two uses of variables in the VM:= one
for calls to variable-ref or variable-set, and the other for internal
use. =A0For the internal uses, we know the variable should indeed be a
variable and so we should emit the checks. =A0For 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 ...)). =A0Dunno. =A0WDYT?

D= o we usually omit checks for internal stuff? If so, I agree, we should do t= hat here too. But right now we do the check every time anyway - the only di= fference 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 fo= r 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 err= or checking only for user-generated box-refs, but that seems more complex t= han we need right now (unless you want to add it to the VM).
=A0
> One thing that would be interesting - and I don't know if we do th= is
> now - is using different VMs for different parts of the
> code. Specifically, if the REPL ran in a different VM than user code,<= br> > then the REPL wouldn't die in these cases. =A0That might also enab= le
> cool debugging things, like single-stepping the user VM and examining<= br> > 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 "fallbac= k" that
we have is the stack VM, actually. =A0What happens if you install traps on<= br> 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 neve= r 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 li= ttle while.

Noah

--bcaec5215ea97b48b904dbee85d1--