From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Immediate doubles (up to 2^256) and rationals coming to Guile 3 Date: Tue, 11 Jun 2019 06:58:09 -0400 Message-ID: <87y32875ib.fsf@netris.org> References: <87zhmvaw5p.fsf@netris.org> <87o939b2lz.fsf@gnu.org> <87a7eqae8d.fsf@netris.org> <87d0jk5xdh.fsf@gnu.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="135361"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Andy Wingo , guile-devel To: Ludovic =?utf-8?Q?Court=C3=A8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jun 11 13:28:52 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 1haexO-000Z2A-9i for guile-devel@m.gmane.org; Tue, 11 Jun 2019 13:28:50 +0200 Original-Received: from localhost ([::1]:56450 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1haexN-000469-AS for guile-devel@m.gmane.org; Tue, 11 Jun 2019 07:28:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41505) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1haeWX-00061q-AZ for guile-devel@gnu.org; Tue, 11 Jun 2019 07:01:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1haeWO-0004Pf-PS for guile-devel@gnu.org; Tue, 11 Jun 2019 07:01:00 -0400 Original-Received: from world.peace.net ([64.112.178.59]:41598) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1haeWM-00047G-4f; Tue, 11 Jun 2019 07:00:56 -0400 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1haeW0-0004aQ-Po; Tue, 11 Jun 2019 07:00:33 -0400 In-Reply-To: <87d0jk5xdh.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 64.112.178.59 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:19961 Archived-At: Hi Ludovic, 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). >> (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? 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 In the VM, I've added four new instructions: make-tagged-non-immediate dst:12 tag:12 offset:32 tagged-allocate-words/immediate dst:8 count:8 tag:8 tagged-scm-ref/immediate dst:8 obj:8 byte-offset:8 tagged-scm-set!/immediate obj:8 byte-offset:8 val:8 The last two instructions above are like 'scm-ref/immediate' and 'scm-set!/immediate' except that they accept byte offsets instead of word offsets. CAR and CDR become: (tagged-scm-ref/immediate DST SRC -6) ;CAR and: (tagged-scm-ref/immediate DST SRC 2) ;CDR (although at present the -6 prints as 250 in the disassembler). > I think we disable GC =E2=80=9Cinterior pointer=E2=80=9D scanning. I agree. > With this scheme, an SCM for a pair would actually point in the middle > of a pair; could this be an issue for GC? It is already the case that Guile has tagged pointers in the first word of every struct. The first word of a struct contains a pointer to the vtable, with scm_tc3_struct added. 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. In 2.0 and 2.2, we register displacements 0, 16, and 17. The last two are for struct vtables, which point 2 words into a heap block, even before adding scm_tc3_struct (which is 1). In current master, we register 0 and 1 (scm_tc3_struct). With this new approach, we would register 0, 1, and 6 (scm_pair_tag). What do you think? Thanks, Mark