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

Groups > comp.lang.c > #168373

Re: Why is glibc not extensive?

Show all headers | View raw

On 11/27/2022 3:13 PM, Bart wrote:
> 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.
> 

If the type is declared, one can have the full width.
If tagged as a variant type, then one only gets 62 bits...


Another option could have been to use 80 or 96 bit tagged-refs, but this 
would be a worse option than being limited to a 62 bit fixnum.


OTOH, the error added for cutting the low 2 bits off of double for 
flonum is unlikely to be particularly noticeable in practice.


For the most part though, MSB tagging was "the lesser of two evils" in 
this case, mostly as LSB tagging would interfere with pointer alignment.


Function and branch pointers do also use LSB tagging though, mostly to 
separate between ignoring the high order bits, or treating them as 
containing the operating mode (such as a way to jump between having the 
CPU run the BJX2 ISA, or run RISC-V RV64IM).

Though, RV64IM code would not be entirely data-compatible with code 
built to use tagged-pointers and bounds checking (neither the RISC-V ISA 
nor ABI design having any concept of tagged pointers or tagged values).


The basic design for the tagged pointer system was originally mostly 
carried over from my "BGBScript2 VM" project, which was using a similar 
system on x86-64. Though, a bit more work is needed on x86-64 as the ISA 
design does not help out with any of this (pretty much everything needs 
to be done manually using shifts and bit manipulation).


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

In these cases, native representations may be used when types are 
statically known.

For my custom ISA though, the tagged pointers *are* the native pointer 
format, though most C pointers are either tag 0 or 3 in this case.

For things like flonums, the "shift right by 2 bits and set the tag" is 
handled as a dedicated CPU instruction.


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

As I see it, a 48-bit virtual address space works well enough for now.


As is, on my ISA, I can run Doom with bounds-checking and tagged 
pointers with no real noticeable drop in frame-rate compared with a 
"plain" version (with no type tags).

Though, on a 50MHz CPU, this does leave Doom mostly in 16..24 fps territory.


Even for more extreme cases (such as running a prime factorization 
algorithm entirely using dynamically typed values), it was (at the time) 
around a 3x slowdown vs a static-typed version (written in C).

Though, much of the overhead here is because for dynamically typed code, 
pretty much every operator needs to be a runtime call (if the type is 
known, the calls can be skipped, and the use of type-tagged values isn't 
a big issue either way).


Though, in premise, if someone wanted, they could try writing something 
Doom-like in a language resembling JavaScript and then try to run it on 
this...

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