public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Marc Nieper-Wißkirchen" <marc.nieper+gnu@gmail.com>
To: "Marc Nieper-Wißkirchen" <marc.nieper+gnu@gmail.com>
Cc: David Malcolm <dmalcolm@redhat.com>, jit@gcc.gnu.org
Subject: Re: Conversion of pointers to integers and vice versa; pointer tagging
Date: Fri, 3 Dec 2021 16:47:12 +0100	[thread overview]
Message-ID: <CAEYrNrSsqPD7vfg2i+ZJ=3n1BdBUYTcbgP_Yj5+kUk_eKth2XQ@mail.gmail.com> (raw)
In-Reply-To: <CAEYrNrTH4yrZSucp4p-fZ64=OpNCre_oUrRHsEo5e6VDuZ=yRg@mail.gmail.com>

Please excuse the noise. It was too late yesterday evening and so I missed
the API function gcc_jit_context_get_int_type. :)

Am Do., 2. Dez. 2021 um 22:10 Uhr schrieb Marc Nieper-Wißkirchen <
marc.nieper+gnu@gmail.com>:

> Am Mi., 2. Jan. 2019 um 17:56 Uhr schrieb David Malcolm <
> dmalcolm@redhat.com>:
>
>> 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.
>>
>
> Please excuse resurrecting this thread, but it has occurred to me that I
> don't know how to create an integer type whose width is exactly the same as
> the one of a pointer using libgccjit. Wouldn't it make sense to add
> something like GCC_JIT_TYPE_UINTPTR_T or similar? Or am I supposed to use,
> say, Autoconf, to check the sizes of the provided types and choose one
> accordingly?
>
> Thanks,
>
> Marc
>
>

      reply	other threads:[~2021-12-03 15:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-01  0:00 Marc Nieper-Wißkirchen
2019-01-01  0:00 ` David Malcolm
2021-12-02 21:10   ` Marc Nieper-Wißkirchen
2021-12-03 15:47     ` Marc Nieper-Wißkirchen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEYrNrSsqPD7vfg2i+ZJ=3n1BdBUYTcbgP_Yj5+kUk_eKth2XQ@mail.gmail.com' \
    --to=marc.nieper+gnu@gmail.com \
    --cc=dmalcolm@redhat.com \
    --cc=jit@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).