From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Newsgroups: gmane.lisp.guile.devel Subject: Re: Immediate doubles (up to 2^256) and rationals coming to Guile 3 Date: Tue, 11 Jun 2019 14:21:55 +0200 Message-ID: <875zpc1fdo.fsf@gnu.org> References: <87zhmvaw5p.fsf@netris.org> <87o939b2lz.fsf@gnu.org> <87a7eqae8d.fsf@netris.org> <87d0jk5xdh.fsf@gnu.org> <87y32875ib.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="103871"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: Andy Wingo , guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jun 11 14:22:33 2019 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hafnL-000QvI-G2 for guile-devel@m.gmane.org; Tue, 11 Jun 2019 14:22:31 +0200 Original-Received: from localhost ([::1]:57290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hafnJ-00016Y-FW for guile-devel@m.gmane.org; Tue, 11 Jun 2019 08:22:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36662) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hafn0-000144-8P for guile-devel@gnu.org; Tue, 11 Jun 2019 08:22:12 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hafmq-0003gL-JB; Tue, 11 Jun 2019 08:22:04 -0400 Original-Received: from [2001:660:6102:320:e120:2c8f:8909:cdfe] (port=40594 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hafmo-0007XQ-B0; Tue, 11 Jun 2019 08:22:00 -0400 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 23 Prairial an 227 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu In-Reply-To: <87y32875ib.fsf@netris.org> (Mark H. Weaver's message of "Tue, 11 Jun 2019 06:58:09 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.lisp.guile.devel:19963 Archived-At: Hi, Mark H Weaver skribis: > Ludovic Court=C3=A8s writes: >> Though an immediate, like a fixnum or an iflo, is still something >> different from a tagged heap object like a pair, right? So I would >> expect SCM_THOB_P to be a different test, not a drop-in replacement for >> SCM_NIMP, is that correct? > > That's right. It's not possible to create a drop-in replacement for > SCM_NIMP, because it is being used to answer two different questions > which used to be effectively equivalent, but no longer are: > > (1) Is X a pointer to a heap object with a heap tag in the first word? > (2) Is X a reference to a heap object? > > Test (1) needs to be done before checking the heap tag, to implement > type predicates for heap objects. Test (2) is needed in relatively few > places, e.g. to decide whether to register disappearing links when > adding an entry to a weak hash table. > > Actually, in my current branch I've removed the SCM_IMP and SCM_NIMP > macros outright, because it seems to me they are likely to be misused. > > SCM_THOB_P implements test (1) and SCM_HEAP_OBJECT_P implements test (2). I see. > There's no masking involved. Rather, it is subtracted from the pointer, > which allows the tag to be fused with the field offset. For example, on > x86-64, whereas CAR and CDR were previously: > > 1c0: 48 8b 07 mov (%rdi),%rax ;old car > and: > 1d0: 48 8b 47 08 mov 0x8(%rdi),%rax ;old cdr > > Now they become: > > 1e0: 48 8b 47 fa mov -0x6(%rdi),%rax ;new car > and: > 1f0: 48 8b 47 02 mov 0x2(%rdi),%rax ;new cdr Looks reasonable. :-) > Fortunately, BDW-GC provides GC_REGISTER_DISPLACEMENT, which allows us > to register a small offset K, such that BDW-GC should recognize pointers > that point K bytes into a heap block. We've been using this in both 2.0 > and 2.2 from scm_init_struct (), and in 'master' it's done in > scm_storage_prehistory (). > > This new approach entails registering one additional displacement. Cool; if it=E2=80=99s just one displacement, that=E2=80=99s OK. > What do you think? It all looks perfectly reasonable to me! Thanks for explaining, Ludo=E2=80=99.