Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #168365

Re: Why is glibc not extensive?

Show all headers | View raw

On 11/27/2022 7:05 AM, Kaz Kylheku wrote:
> On 2022-11-27, Michael S <already5chosen@yahoo.com> wrote:
>> If current rate of Moore Law is not improved then even with
>> all conservatism of standard bodies it will happen several
>> decades before the first individual object reaches 2**63-1.
> 
> Currently, people are using the top bits of 64 bit pointers
> for funny things:
> 
> - Android implements pointer-tagging. The upper 16 bits of a pointer
> are a tag, which can be used to validate it.  E.g. if you malloc
> some space, free it and malloc again such that the same space
> is returned, it will have a different tag. The hardware strips
> away the tag; only the lower 48 bits (at most) is significant.
> 
> - A collection of techiques called NaN boxing can store a 50 bit
> pointer, fully unboxed 64 bit double, or a 50 bit integer, in a 64 bit
> word. This is a boon for dynamic languages, which can have unboxed
> floats.
> 

In my case, I am doing something similar with a custom ISA of mine...
The top 16 bits of the 64-bit pointers are mostly ignored by Load/Store 
ops, and often used as a dynamic type tag or similar.

The type-tag seemed more valuable in a near term sense than "virtual 
address space limit that likely wont be a big limiting factor for 
decades or more". Can note (on Windows) that after nearly 2 decades of 
having x86-64, we still have not (entirely) dispelled the use of 32-bit 
programs.

And, only a minority of programs on a PC "actually need" much more than 
a few GB (excluding things like FireFox wanting to eat all the RAM in a 
PC or similar).



I didn't use NaN boxing (in my dynamic and hybrid languages), while it 
makes sense for floating point numbers, it "kinda sucks" for pretty much 
everything else. It seemed a lot more sane to shift floating point 
numbers right by 2 bits, and then have a lot more tag space for 
everything else (say, then one can also have a 62-bit integer type in 
this range).

IMO, having a bigger integer type seemed to make more sense.

As can be noted, my mainly used languages on this are mostly static and 
hybrid languages (where in a hybrid language, many values may be kept in 
a tagged form, and dynamic typing is optional; but otherwise the 
language mostly behaves like a statically typed language).


So, top 4 bits, organized by hex:
   0=Pointer (59:48=Object Tag, 0=None)
   1=Small Spaces
   2=Bounds-Checked Pointer (Older Style)
   3=Bounds-Checked Pointer (Newer Style)
   4..7=Fixnum (62-bit integer)
   8..B=Flonum (62-bit floating point)
   C=Base-Offset Array (Older Style)
   D=Packed Vector (2 or 3 element)
   E=Type Tagged Pointer (Encodes a more C style pointer type)
   F=Raw pointer with 60-bit address.


Tag 2: Naively used a 12-bit bound, so only deals with small arrays and 
doesn't allow base-offsetting them (Tag C allowed base-offsetting, but 
required accessing memory to determine the array size).

Tag 3 can address both cases at the same time.


Tag 3:
   (59:56)=Base Offset Bias
   (55:51)=Exponent
   (50:48)=Size Fraction
Array size is interpreted as an 8-bit E5.F3 microfloat, with a base 
offset encoded using the same exponent (but not normalized).

The low 48 bits point to an address somewhere within the body of the array.

This format currently has some dedicated ISA level support.

It is not super exact, so is interpreted in one of two ways:
   Lax: Allow access unless it is "clearly out of bounds";
   Strict: Only allow access known in bounds.

So, say:
   RelIndex=(Index>>Exponent)+OffsetBias
   Lax: allows -1<=RelIndex<=Size
   Strict allows: 0<=RelIndex<Size

Address adjustment uses the adjustment index (shifted right) along with 
the carry out of the low-order bits, to figure out how to adjust the 
base offset bias.

If used as a for bounds-checked pointers in C, the lax version is used.
If used for a high-level array type, the strict version is used (will 
fall back to additional runtime checks, treating the bounds-checked 
version as a "fast path" version).


This version allows array bounds checking with only minimal performance 
overhead relative to bare pointers.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Why is glibc not extensive? Amit <amitchoudhary0523@gmail.com> - 2022-11-16 22:31 -0800
  Re: Why is glibc not extensive? Bart <bc@freeuk.com> - 2022-11-17 13:05 +0000
    Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-17 05:18 -0800
      Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-17 05:24 -0800
      Re: Why is glibc not extensive? Bart <bc@freeuk.com> - 2022-11-17 13:57 +0000
      Re: Why is glibc not extensive? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-17 17:04 +0000
      Re: Why is glibc not extensive? David Brown <david.brown@hesbynett.no> - 2022-11-18 09:32 +0100
        Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-18 02:32 -0800
          Re: Why is glibc not extensive? David Brown <david.brown@hesbynett.no> - 2022-11-18 13:09 +0100
            Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-18 04:47 -0800
              Re: Why is glibc not extensive? David Brown <david.brown@hesbynett.no> - 2022-11-18 13:59 +0100
                Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-18 05:27 -0800
              Re: Why is glibc not extensive? Bart <bc@freeuk.com> - 2022-11-18 17:04 +0000
                Re: Why is glibc not extensive? David Brown <david.brown@hesbynett.no> - 2022-11-21 08:50 +0100
                Bart (Was: Why is glibc not extensive?) gazelle@shell.xmission.com (Kenny McCormack) - 2022-11-21 14:14 +0000
              Re: Why is glibc not extensive? Michael S <already5chosen@yahoo.com> - 2022-11-21 08:10 -0800
                Re: Why is glibc not extensive? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-26 09:07 -0800
                Re: Why is glibc not extensive? Michael S <already5chosen@yahoo.com> - 2022-11-26 16:11 -0800
                Re: Why is glibc not extensive? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-27 13:05 +0000
                Re: Why is glibc not extensive? scott@slp53.sl.home (Scott Lurndal) - 2022-11-27 16:30 +0000
                Re: Why is glibc not extensive? BGB <cr88192@gmail.com> - 2022-11-27 12:20 -0600
                Re: Why is glibc not extensive? Bart <bc@freeuk.com> - 2022-11-27 21:13 +0000
                Re: Why is glibc not extensive? BGB <cr88192@gmail.com> - 2022-11-27 21:53 -0600
                Re: Why is glibc not extensive? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-03 01:17 -0800
        Re: Why is glibc not extensive? BGB <cr88192@gmail.com> - 2022-11-23 15:11 -0600
  Re: Why is glibc not extensive? Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-17 19:05 +0100
    Re: Why is glibc not extensive? gazelle@shell.xmission.com (Kenny McCormack) - 2022-11-18 08:09 +0000
      Re: Why is glibc not extensive? BGB <cr88192@gmail.com> - 2022-11-23 13:55 -0600

csiph-web