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: Mon, 22 Apr 2013 21:34:19 -0400 Message-ID: References: <8761zejopa.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b10cd8f5910b604dafd30b2 X-Trace: ger.gmane.org 1366680886 13897 80.91.229.3 (23 Apr 2013 01:34:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Apr 2013 01:34:46 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Apr 23 03:34:50 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 1UUS89-000742-3n for guile-devel@m.gmane.org; Tue, 23 Apr 2013 03:34:49 +0200 Original-Received: from localhost ([::1]:48172 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUS88-0000nG-HL for guile-devel@m.gmane.org; Mon, 22 Apr 2013 21:34:48 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUS85-0000mz-CX for guile-devel@gnu.org; Mon, 22 Apr 2013 21:34:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UUS81-0003PB-9o for guile-devel@gnu.org; Mon, 22 Apr 2013 21:34:45 -0400 Original-Received: from mail-pd0-f179.google.com ([209.85.192.179]:53889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UUS80-0003Oy-W5 for guile-devel@gnu.org; Mon, 22 Apr 2013 21:34:41 -0400 Original-Received: by mail-pd0-f179.google.com with SMTP id x11so71826pdj.10 for ; Mon, 22 Apr 2013 18:34:39 -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=fz3OyAMnxpj01kxw6dRmsTbjBc3i5ZnJnMGuYzm/Wpo=; b=PjvocDgfOD23IZisUxoTteHpcFsqft3hz9OmyHpTtNOuszQSayiEXqDqCW+e6ifkT+ bKMneiRyKKHKiznOsisnjWcsEQMOCA0CDIeMrs2yG9eha89h3MOut1FhpJV+5VBM3s+2 LpR7jAzU0ll5CfDBbHW1lLrnum/t6TIwY+yU/28EP8yYp7uhRi/7QqzF7u7FfvBjiMEh UJp3f9XGPhlhVQhO2QBHYdvLIUzv/sNEAtohST6M55dURGLXoMr/mYrD1mY2+uMhIIw7 tZwUqmb6acNyygzurPFjrpe1Ajyf6Gyqt6AOcuWN+bTeFsFtH9jFiYaHFni+6u/QgQ05 2iyg== X-Received: by 10.68.136.132 with SMTP id qa4mr35381088pbb.3.1366680879565; Mon, 22 Apr 2013 18:34:39 -0700 (PDT) Original-Received: by 10.68.7.9 with HTTP; Mon, 22 Apr 2013 18:34:19 -0700 (PDT) In-Reply-To: <8761zejopa.fsf@pobox.com> X-Google-Sender-Auth: BnIcbRXgdWLmSQi5He-3ED-OC6M X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [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:16288 Archived-At: --047d7b10cd8f5910b604dafd30b2 Content-Type: text/plain; charset=ISO-8859-1 Hello, On Mon, Apr 22, 2013 at 4:27 PM, Andy Wingo wrote: > Hi Noah, > > Do I understand you correctly that you're just making a sequence of > non-idiomatic instructions because you know that doing the > assert-nargs-ee will check nargs? I would think in a normal case you'd > want to do "assert-nargs-ge 0", then "bind-rest 0", then "reserve-locals > 0" (or not; in this case it would not be necessary). > Yes, that's exactly why I'm doing it. I just wanted to find a way to test that the bug was fixed and stayed fixed. In this case that's a bit weird, because we probably don't want to guarantee that this pattern of instructions will continue to work, but I don't have a great alternative. I think any sort of test for this is going to be dependent on the internals of the VM. (My earlier email about adding accessors for the VM was about this same bug, but then I realized that nargs isn't part of the vm structure so I couldn't solve it like that.) > However the bug you have seen with bind-rest is probably also present > with keyword arguments. We should probably just change the > reserve-locals instruction to also take "nargs" as a value, given that > we know it statically at compile-time. > > Does that make sense to you? > I'm not sure. As long as nargs is going to be a local variable, I don't see a reason not to use it. It might make more sense to either keep it the way it is or change every instruction that uses nargs. But I haven't looked to see how many there are, or how important it is that they know nargs. Noah --047d7b10cd8f5910b604dafd30b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

On Mon, Apr 22, 2013 at 4:27 PM, Andy Wingo <wingo@pobox.co= m> wrote:
Hi Noah,

Do I understand you correctly that you're just making a sequence of
non-idiomatic instructions because you know that doing the
assert-nargs-ee will check nargs? =A0I would think in a normal case you'= ;d
want to do "assert-nargs-ge 0", then "bind-rest 0", the= n "reserve-locals
0" (or not; in this case it would not be necessary).
<= div>
Yes, that's exactly why I'm doing it. I just wan= ted to find a way to test that the bug was fixed and stayed fixed. In this = case that's a bit weird, because we probably don't want to guarante= e that this pattern of instructions will continue to work, but I don't = have a great alternative. I think any sort of test for this is going to be = dependent on the internals of the VM. (My earlier email about adding access= ors for the VM was about this same bug, but then I realized that nargs isn&= #39;t part of the vm structure so I couldn't solve it like that.)
=A0
However the bug you have seen with bind-rest is probably also present
with keyword arguments. =A0We should probably just change the
reserve-locals instruction to also take "nargs" as a value, given= that
we know it statically at compile-time.

Does that make sense to you?=

I'm not sure. As lon= g as nargs is going to be a local variable, I don't see a reason not to= use it. It might make more sense to either keep it the way it is or change= every instruction that uses nargs. But I haven't looked to see how man= y there are, or how important it is that they know nargs.

Noah

--047d7b10cd8f5910b604dafd30b2--