From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117405 invoked by alias); 2 Jan 2019 16:56:14 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 117386 invoked by uid 89); 2 Jan 2019 16:56:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=p.s, P.S, UD:P.S, PS X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Jan 2019 16:56:13 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8DD5E9B324; Wed, 2 Jan 2019 16:56:11 +0000 (UTC) Received: from ovpn-116-42.phx2.redhat.com (ovpn-116-42.phx2.redhat.com [10.3.116.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id 02C2410018F9; Wed, 2 Jan 2019 16:56:10 +0000 (UTC) Message-ID: <1546448170.7788.10.camel@redhat.com> Subject: Re: Conversion of pointers to integers and vice versa; pointer tagging From: David Malcolm To: Marc =?ISO-8859-1?Q?Nieper-Wi=DFkirchen?= , jit@gcc.gnu.org Date: Tue, 01 Jan 2019 00:00:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 02 Jan 2019 16:56:11 +0000 (UTC) X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00003.txt.bz2 On Tue, 2019-01-01 at 12:00 +0100, Marc Nieper-Wißkirchen wrote: > Implementations of languages with garbage collection and dynamic > typing often employ the concept of tagged pointers. Unused bits of a > pointer representation are used to distinguish between pointers to > different types or between pointers and immediate values. > > Implementing such a language with libgccjit raises a couple of > questions: > > 1) libgccjit has currently only a limited set of type-casting > expressions. In particular, there is no type-casting expression > between an integer type (e.g. uintptr_t) and a pointer type defined. > > Are there technical reasons for that or is that just an area where > libgccjit still has to be complemented? In general, I've chosen to require the user to explicitly supply any casting that's needed, out of a desire to catch problems early. gcc_jit_context_new_cast only supports a few conversions. IIRC this was to simplify the internal implementation; perhaps more conversions could be allowed. > I guess, a workaround could be to use union types à la > > union { > uintptr_t i; > void *p; > } > > everywhere. That ought to work. > 2) For pointer tagging, one needs to know which bits in the integer > representation of a pointer are unused. Does GCC make the guarantee > that on all supported platforms a pointer aligned on a 2^d-byte > boundary has its lower d bits zeroed? I don't know if we "guarantee" it, but it ought to work. > Is pointer arithmetic compatible > with the arithmetic on the underlying integer type? (I know that ISO > C > does not make these guarantees, but we are talking about a particular > implementation here.) C pointer arithmetic is done in terms of the number of units of the underlying type, so there's a scale factor involved. I can't remember what libgccjit does here off the top of my head. > 3) One may want to use bit fields when implementing tags. The > documentation for libgccjit seems to be silent on bit fields in > structures. Is this feature on the TODO list? It wasn't on the TODO list, as it hadn't occurred to me, but it does seem like a missing feature. > Thanks! > > -- Marc > > P.S.: A Happy New Year to everyone! ...and to you Dave