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 10:39:38 +0200 Message-ID: <87d0jk5xdh.fsf@gnu.org> References: <87zhmvaw5p.fsf@netris.org> <87o939b2lz.fsf@gnu.org> <87a7eqae8d.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="208055"; 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 10:43:47 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 1hacNf-000s0f-7r for guile-devel@m.gmane.org; Tue, 11 Jun 2019 10:43:47 +0200 Original-Received: from localhost ([::1]:52856 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hacNd-0004Nb-R3 for guile-devel@m.gmane.org; Tue, 11 Jun 2019 04:43:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54046) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hacNZ-0004II-6H for guile-devel@gnu.org; Tue, 11 Jun 2019 04:43:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40897) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hacJg-0007FG-Sc; Tue, 11 Jun 2019 04:39:40 -0400 Original-Received: from [2001:660:6102:320:e120:2c8f:8909:cdfe] (port=39032 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hacJg-0004S5-8Y; Tue, 11 Jun 2019 04:39:40 -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: <87a7eqae8d.fsf@netris.org> (Mark H. Weaver's message of "Sun, 09 Jun 2019 12:56:55 -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:19960 Archived-At: Hello, Mark H Weaver skribis: > Ludovic Court=C3=A8s writes: [...] >> IIUC, your plan is to have a different tagging on 32-bit platforms, >> without fixflos, right? I=E2=80=99m curious to see how much complexity = would >> entail from that. > > Yes, although I'm avoiding the term "fixflos" because IEEE doubles are > also fixed width, and thus the term "fixflos" wouldn't adequately > distinguish them from IEEE doubles. Right! > Anyway, I agree that it's inconvenient to have different tags on > different targets, and I've been working to minimize the differences. > > At present, I'm currently implementing an alternative strategy where > pairs are tagged in their pointers instead of in their CARs, which > enables us to separate the heap tags and immediate tags into two > independent spaces. At first this sounds rather radical :-), but maybe it=E2=80=99s preferable = this way. > In this new approach, the heap tags are left unchanged, and the only > tags that vary with target word size are the fixints, fixrats, iflos, > and pair pointers. All other tags will be uniform across targets, > including the non-number immediates. Here's the new version: > > ;; /* with iflos: xxx: iflo (000 < xxx < 110) > ;; (64-bit) 0111: fixrat > ;; 1111: fixnum > ;; 0110: pair > ;; 000: tagged heap object (thob) > ;; tttt1110: other immediate > ;; > ;; without iflos: 1: fixnum > ;; (32-bit) 010: fixrat > ;; 100: pair > ;; 000: tagged heap object (thob) > ;; tttt1110: other immediate > > This new approach brings its own complications, mainly two: > > (1) It breaks the long-standing assumptions in Guile that all > non-immediates have a tag in their first word and that pointers are > always untagged. In my preliminary patch, I introduce a new concept > called a "tagged heap object" or "thob", and most existing checks > for SCM_NIMP or !SCM_IMP must be changed to use SCM_THOB_P. 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? > (2) Our existing VM instructions almost invariably specify offsets with > a granularity of whole words. To support tagged pair pointers with > good performance, I think we need a few new instructions that > specify byte offsets, to avoid the expensive extra step of removing > the tag before accessing the CAR or CDR of a pair. So instead of a pointer dereference, SCM_CAR becomes mask + dereference, right? I think we disable GC =E2=80=9Cinterior pointer=E2=80=9D scanning. With th= is scheme, an SCM for a pair would actually point in the middle of a pair; could this be an issue for GC? Thank you! Ludo=E2=80=99.