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

Groups > comp.lang.c > #164619

Re: Here come the 128-bit pointers

Show all headers | View raw

On 1/25/2022 4:04 AM, Öö Tiib wrote:
> On Tuesday, 25 January 2022 at 10:32:01 UTC+2, BGB wrote:
>> On 1/25/2022 1:25 AM, Bonita Montero wrote:
>>> Am 24.01.2022 um 19:12 schrieb Scott Lurndal:
>>>
>>>> https://www.theregister.com/2022/01/21/arm_morello_testing/
>>>> https://www.arm.com/architecture/cpu/morello
>>>> https://developer.arm.com/documentation/ddi0606/latest
>>>
>>> Where are the 128 bit pointers in Morello ?
>> A quick skim implies that it works like:
>> 64-bit pointers, no special protection;
>> 129-bit pointers (with 128-bit storage), capability addressing, ...
>>
>> So, implicitly, it involves:
>> Extra big pointers;
>> Extra wonkiness for saving/reloading pointers;
>> Registers that are internally significantly wider than what it visible
>> in the rest of the ISA;
>> ...
>>
>> A quick skim makes me suspect that this will have few drawbacks:
>> More expensive for a hardware implementation (vs normal ARM64);
> 
> That feels likely but to what extent of affect? The grampies at comp.arch
> can perhaps estimate it better than we here.
> 

Possible.

I post around there more often than here anymore.


My experience is mostly in the context of custom cores on FPGAs, but can 
note that "expand all the GPRs internally to 129-bits but ignore these 
bits in most instructions" is kinda, not ideal from a cost POV (at least 
on an FPGA).


My ISA does have some 128-bit stuff, but internally it is all done by 
essentially pairing up 64-bit ports (using the 6R3W register file as a 
virtual 3R1W register file for 128-bit ops; spreading the logic across 
multiple lanes). (The core is basically using a 3-wide VLIW design 
internally, for an ISA with variable-length VLIW bundling).

Following the cost/benefit curves did lead to the relative oddity of 
having an ISA with some 128-bit integer ALU instructions, but only 
having a 32-bit integer multiplier, while not having any integer divide 
instructions, ...


>> Unlikely to be widely adopted, as using it would adversely impact
>> existing C codebases (which tend to assume pointers are either 32 or 64
>> bits, and the ability to freely cast to and from integer types and
>> manipulate them at the bit level, ...).
> 
> That is unlikely a problem. Very few actual products convert to integers
> and crunch pointers at bit level. The one's that do are highly platform
> specific and so don't care about Morellos elsewhere in universe.
> The portable code bases however support both 32 and 64 bit pointers
> without problems already now as rule. Adding 128 is just extending
> what is already there.
> 

My experience differs some.

It was sort of a pain porting a lot of 32-bit era code to 64-bit 
targets, mostly because of these sorts of issues. Porting 16-bit era 
code borders on rewriting much of it (such as to eliminate all the 
wrangling with "far pointers"; or to deal with things like 'int' and 
'long' now being different sizes; ...).

A lot of this sort of code often still ends up with ifdefs to try to 
detect things like target and pointer size.

A few times, one has also gotten bitten by code which assumes things 
like whether 'char' is signed or unsigned by default, etc.



My prediction is that porting such code to also be able to deal with 
128-bit pointers would be yet another layer of hassle.

Like, about as soon as one runs into a codebase based around "NaN 
boxing" a lot of their pointers or similar, what will they do?...

Or, can you even do this sort of bit-munging with capabilities without 
breaking them?... Will they have to switch over to treating all the 
heaps as Base+Displacement? ...

So, say your NaN boxed value stores the address as 
(PointerToObject-HeapBase) and then needs to do 
(HeapBase+ObjectDisplacement) to regenerate a valid pointer, or maybe 
needs a different base pointer for every heap segment, turning it into, say:
   uli=get_double_as_bits(val);
   ptr=somevm_heapbase[(uli>>32)&4095]+((uint32_t)uli);

...



Though, the alternative is, say, using 64 bit pointers but then defining 
the high 16 bits as being ignored (limiting the address space to 48 
bits). On the plus side, now things like NaN boxing and similar can be 
made pretty much free (well, though officially I don't use NaN boxing, 
but rather a different tagging scheme that makes more economical use of 
the bits, and allows for a 62-bit fixnum and similar).



Well, and of course, the other option for "fake" capabilities which is 
"make the address space so large that it is pretty much impossible to 
guess the high order bits" (in this case, the security would depend less 
on hardware level protection and more the strength of the random number 
generator).

Though, these faked capabilities still have the drawback of needing to 
deal with larger (128-bit) pointers, but if they are treated as an 
obscure special case, the overall impact to code is less (most code wont 
need to care).

Granted, a memory protection scheme which is opt-in is likely to see 
relatively little use in practice.


>> Ideally, one would want a solution which is both "pretty much invisible"
>> (code should not need to know or care) and "nearly free" (does not
>> significantly impact performance, memory usage, or the relative
>> implementation cost).
> 
> People dream about what is ideal but purchase what is available.
> Decisions in businesses are made based on their latter behaviour.

I suspect "slightly better security" is going to be a hard sell in the 
face of extra porting effort and/or ABI compatibility issues.


So, say:
Well, "we now get more security, and don't need to do anything";
Vs, "we can get more security, but need to recompile";
Vs, "we can get more security, but need to go through porting effort and 
also now the ABI is different".

...


Traditionally, "not needing to do anything" has been preferred (hence 
probably still why we have 64-bit systems still largely running programs 
compiled for 32-bit x86...).

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

Thread

Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-24 18:12 +0000
  Re: Here come the 128-bit pointers Dan Purgert <dan@djph.net> - 2022-01-24 18:31 +0000
  Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-24 15:41 -0600
  Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-25 08:25 +0100
    Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-25 02:31 -0600
      Re: Here come the 128-bit pointers Öö Tiib <ootiib@hot.ee> - 2022-01-25 02:04 -0800
        Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-25 14:48 +0000
        Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-25 11:54 -0600
          Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-25 18:23 +0000
            Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-25 14:17 -0600
          Re: Here come the 128-bit pointers David Brown <david.brown@hesbynett.no> - 2022-01-26 09:36 +0100
            Re: Here come the 128-bit pointers Theo <theom+news@chiark.greenend.org.uk> - 2022-01-28 22:12 +0000
      Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-25 19:49 +0100
        Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-25 15:59 -0600
          Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-25 22:25 +0000
          Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-26 09:43 +0100
            Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 15:53 +0000
              Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-26 17:25 +0100
            Re: Here come the 128-bit pointers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-26 08:34 -0800
              Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-26 17:57 +0100
              Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-26 17:10 +0000
                Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 17:27 +0000
                Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-26 17:41 +0000
                Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 18:05 +0000
                Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-26 18:23 +0000
                Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-26 14:42 -0600
                Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-26 14:30 -0600
              Re: Here come the 128-bit pointers Mateusz Viste <mateusz@xyz.invalid> - 2022-01-26 19:36 +0100
                Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 18:52 +0000
            Re: Here come the 128-bit pointers tth <tth@none.invalid> - 2022-01-26 21:01 +0100
            Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-26 20:18 +0000
              Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-26 15:35 -0600
                Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 21:50 +0000
                Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-26 20:34 -0600
                Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-27 12:11 +0000
                Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-27 13:40 -0600
        Re: Here come the 128-bit pointers William Ahern <william@25thandClement.com> - 2022-01-27 13:28 -0800
  Re: Here come the 128-bit pointers Theo Markettos <theom+news@chiark.greenend.org.uk> - 2022-01-28 23:18 +0000

csiph-web