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

Groups > comp.lang.c > #168367

Re: Why is glibc not extensive?

Show all headers | View raw

On 27/11/2022 18:20, BGB wrote:
> 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).

I've never used any of these methods. Neither 'Nan' Boxing, nor using 
spare bits at either end of a pointer or integer. They always seemed 
incredibly fiddly. Also the data types are compromised, like not having 
a full 64-bit integer for example.

And, in cases where a compiler can statically determine a type, it could 
generate code to directly operate on the integer, float or pointer 
without bitshifting.

The cost however is using two machine words instead of one, but this 
seemed acceptable for dynamic code which is going to be slow anyway. (My 
dynamic language also has homogeneous arrays where each element is a 
plain i64 or f64 (or u16 etc), so the same overheads as any static 
language.)

64-bit pointers are also wasteful since it is rare that I'd use more 
than 2GB or even 4GB in my programs. But I've experimented with using 
32-bit pointers within a 64-bit environment, and it was too much 
trouble. I'm not exactly short of memory; I'm more in needs of ways to 
fill it up!

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