public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Conversion of pointers to integers and vice versa; pointer tagging
  2019-01-01  0:00 Conversion of pointers to integers and vice versa; pointer tagging Marc Nieper-Wißkirchen
@ 2019-01-01  0:00 ` David Malcolm
  2021-12-02 21:10   ` Marc Nieper-Wißkirchen
  0 siblings, 1 reply; 4+ messages in thread
From: David Malcolm @ 2019-01-01  0:00 UTC (permalink / raw)
  To: Marc Nieper-Wißkirchen, jit

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Conversion of pointers to integers and vice versa; pointer tagging
@ 2019-01-01  0:00 Marc Nieper-Wißkirchen
  2019-01-01  0:00 ` David Malcolm
  0 siblings, 1 reply; 4+ messages in thread
From: Marc Nieper-Wißkirchen @ 2019-01-01  0:00 UTC (permalink / raw)
  To: jit

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?

I guess, a workaround could be to use union types à la

union {
  uintptr_t i;
  void *p;
}

everywhere.

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? 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.)

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?

Thanks!

-- Marc

P.S.: A Happy New Year to everyone!

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Conversion of pointers to integers and vice versa; pointer tagging
  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
  0 siblings, 1 reply; 4+ messages in thread
From: Marc Nieper-Wißkirchen @ 2021-12-02 21:10 UTC (permalink / raw)
  To: David Malcolm; +Cc: Marc Nieper-Wißkirchen, jit

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Conversion of pointers to integers and vice versa; pointer tagging
  2021-12-02 21:10   ` Marc Nieper-Wißkirchen
@ 2021-12-03 15:47     ` Marc Nieper-Wißkirchen
  0 siblings, 0 replies; 4+ messages in thread
From: Marc Nieper-Wißkirchen @ 2021-12-03 15:47 UTC (permalink / raw)
  To: Marc Nieper-Wißkirchen; +Cc: David Malcolm, jit

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
>
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-12-03 15:47 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-01  0:00 Conversion of pointers to integers and vice versa; pointer tagging 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 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).