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

Groups > comp.lang.c > #164587 > unrolled thread

Here come the 128-bit pointers

Back to article view | Back to comp.lang.c

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#164648

On 26/01/2022 16:34, Malcolm McLean wrote:
> On Wednesday, 26 January 2022 at 08:43:35 UTC, Bonita Montero wrote:
>> I don't see any sense in logical or physical 128 bit pointers.
>> Imagine that memory-density could be shrinked up to 100 times,
>> so computers could be equipped with much more memory. But it
>> would be impossible have tolerable access-times with an amount
>> of memory in the upper margin of 64 bit (that's 16 billion
>> gigabytes).
>> So the only usage for me would be a larger address space to
>> accomodate larger memory-mapped files. But memory-mapped files
>> are slow anyway as they don't allow pipelined transfers from
>> the disk (except asynchronous read-ahead). An access-facility
>> like in a database-system which issues pipelined asynchronous
>> operations is much more efficient.
>> And have a look at the filesystems: although ZFS data-layout
>> allows 128 bit filesystems, its current implementation is
>> limited to 64 bit.
>>
> The idea is to carry meta-data around with the pointer to make
> certain operations, particularly with C, less error-prone.

But requiring double the storage for pointers?

People already think that 64-bit pointers are overkill. Most programs 
would probably work fine with just 32-bit pointers.

I already have trouble myself because of structs that end up being 64 
bytes instead of 32, say, after rounding to a power of two, becauses 
they use needlessly large pointers.

A correctly written program, and one using more helpful language 
features, should rarely need to validate a pointer. Except for 
debugging, but then you can emulate 128 bits in software.

(Also, if the upper 64 bits are accessible from the application, what's 
to stop it writing erroneous bounds as well as an erroneous addresss?)

[toc] | [prev] | [next] | [standalone]

#164649

Bart <bc@freeuk.com> writes:
>On 26/01/2022 16:34, Malcolm McLean wrote:

>> The idea is to carry meta-data around with the pointer to make
>> certain operations, particularly with C, less error-prone.
>
>But requiring double the storage for pointers?
>
>People already think that 64-bit pointers are overkill.

Who are these people, other than you?

[toc] | [prev] | [next] | [standalone]

#164650

On 26/01/2022 17:27, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 26/01/2022 16:34, Malcolm McLean wrote:
> 
>>> The idea is to carry meta-data around with the pointer to make
>>> certain operations, particularly with C, less error-prone.
>>
>> But requiring double the storage for pointers?
>>
>> People already think that 64-bit pointers are overkill.
> 
> Who are these people, other than you?
> 

The people who came up with the x32 ABI for a start.

I also, in my first x64 compiler, kept 32-bit pointers, which worked 
great for my own stuff, but unfortunately the 64-bit OS didn't cooperate 
as sometimes there were function pointers for shared libraries that 
needed more than 32 bits.

Eventually I switched to 64-bit pointers, but my programs also got 5% 
slower and used more memory.

[toc] | [prev] | [next] | [standalone]

#164651

Bart <bc@freeuk.com> writes:
>On 26/01/2022 17:27, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 26/01/2022 16:34, Malcolm McLean wrote:
>> 
>>>> The idea is to carry meta-data around with the pointer to make
>>>> certain operations, particularly with C, less error-prone.
>>>
>>> But requiring double the storage for pointers?
>>>
>>> People already think that 64-bit pointers are overkill.
>> 
>> Who are these people, other than you?
>> 
>
>The people who came up with the x32 ABI for a start.

My employers have been shipping 64-bit systems for almost 30 years.

I can count on one hand the number of customers that cared
for the 32-bit ABI on a 64-bit processors.

[toc] | [prev] | [next] | [standalone]

#164653

On 26/01/2022 18:05, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 26/01/2022 17:27, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 26/01/2022 16:34, Malcolm McLean wrote:
>>>
>>>>> The idea is to carry meta-data around with the pointer to make
>>>>> certain operations, particularly with C, less error-prone.
>>>>
>>>> But requiring double the storage for pointers?
>>>>
>>>> People already think that 64-bit pointers are overkill.
>>>
>>> Who are these people, other than you?
>>>
>>
>> The people who came up with the x32 ABI for a start.
> 
> My employers have been shipping 64-bit systems for almost 30 years.
> 
> I can count on one hand the number of customers that cared
> for the 32-bit ABI on a 64-bit processors.
> 

Of /your/ 64-bit customers? Perhaps that not surprising.

But if that x32 ABI means a system that is faster and cheaper (because 
it can use a lower spec part or less ram) and maybe uses less power, 
then someone is going to be interested, if they want 64-bit registers 
and operations, but don't need to address lots of memory.

[toc] | [prev] | [next] | [standalone]

#164660

On 1/26/2022 12:23 PM, Bart wrote:
> On 26/01/2022 18:05, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 26/01/2022 17:27, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 26/01/2022 16:34, Malcolm McLean wrote:
>>>>
>>>>>> The idea is to carry meta-data around with the pointer to make
>>>>>> certain operations, particularly with C, less error-prone.
>>>>>
>>>>> But requiring double the storage for pointers?
>>>>>
>>>>> People already think that 64-bit pointers are overkill.
>>>>
>>>> Who are these people, other than you?
>>>>
>>>
>>> The people who came up with the x32 ABI for a start.
>>
>> My employers have been shipping 64-bit systems for almost 30 years.
>>
>> I can count on one hand the number of customers that cared
>> for the 32-bit ABI on a 64-bit processors.
>>
> 
> Of /your/ 64-bit customers? Perhaps that not surprising.
> 
> But if that x32 ABI means a system that is faster and cheaper (because 
> it can use a lower spec part or less ram) and maybe uses less power, 
> then someone is going to be interested, if they want 64-bit registers 
> and operations, but don't need to address lots of memory.
> 

Pointer size doesn't usually effect things enough to (significantly) 
effect the overall RAM use of a program. It is typically more like a 
10-20% difference than a 2x difference.

Much under 2x, it will not effect how much physical RAM one needs, as 
RAM modules tend to come in power-of-2 sizes.


Granted, yes, there are cases where spending an extra 10-20% in memory 
overhead due to larger pointers is undesirable.

Though, if one increases all the pointers to 128 bits, they may see, 
say, an additional 15-30% overhead over 64-bit pointers (depending a lot 
on the application).


If the 128-bit pointers were supported, but remained mostly as a 
special-case / novelty, then the overhead should mostly disappear (more 
so on an ISA which has semi-native support for working with 128-bit data).

[toc] | [prev] | [next] | [standalone]

#164659

On 1/26/2022 11:10 AM, Bart wrote:
> On 26/01/2022 16:34, Malcolm McLean wrote:
>> On Wednesday, 26 January 2022 at 08:43:35 UTC, Bonita Montero wrote:
>>> I don't see any sense in logical or physical 128 bit pointers.
>>> Imagine that memory-density could be shrinked up to 100 times,
>>> so computers could be equipped with much more memory. But it
>>> would be impossible have tolerable access-times with an amount
>>> of memory in the upper margin of 64 bit (that's 16 billion
>>> gigabytes).
>>> So the only usage for me would be a larger address space to
>>> accomodate larger memory-mapped files. But memory-mapped files
>>> are slow anyway as they don't allow pipelined transfers from
>>> the disk (except asynchronous read-ahead). An access-facility
>>> like in a database-system which issues pipelined asynchronous
>>> operations is much more efficient.
>>> And have a look at the filesystems: although ZFS data-layout
>>> allows 128 bit filesystems, its current implementation is
>>> limited to 64 bit.
>>>
>> The idea is to carry meta-data around with the pointer to make
>> certain operations, particularly with C, less error-prone.
> 
> But requiring double the storage for pointers?
> 
> People already think that 64-bit pointers are overkill. Most programs 
> would probably work fine with just 32-bit pointers.
> 

Generally true.

Also pretty much true of FPGA boards as well.

Pretty much none of the (affordable) FPGAs have RAM much outside of the 
MB range (and some boards, such as the Digilent CMod series, either lack 
RAM chips, or come with RAM chips in the KB range).

It would be pretty hard to justify 64b pointers on a device with an 
XC7A35T and 512K of RAM.


I am dealing with 64b pointers on something with 128MB of RAM, which is 
arguably kinda overkill, but does have other side benefits (eg, plenty 
of space for ASLR to do its thing with little risk of adverse effects 
due to fragmenting the address space).


For many applications on PC (or server) class hardware, I suspect the 
memory-use impact from the larger pointers will be well within the range 
of "acceptable".


The bigger issue is likely to be with codebases which assume the ability 
to bit-twiddle pointers, which will likely include nearly every existing 
script-language VM and JIT compiler and similar in existence.

Similar for many programs which implement their own custom memory 
allocation systems (possibly the majority of "non-trivial" programs), ...


> I already have trouble myself because of structs that end up being 64 
> bytes instead of 32, say, after rounding to a power of two, becauses 
> they use needlessly large pointers.
> 
> A correctly written program, and one using more helpful language 
> features, should rarely need to validate a pointer. Except for 
> debugging, but then you can emulate 128 bits in software.
> 
> (Also, if the upper 64 bits are accessible from the application, what's 
> to stop it writing erroneous bounds as well as an erroneous addresss?)
> 

I am not entirely sure, but I suspect the point of the extra hidden 
129th bit is to prevent the application from generating its own 
capabilities (by distinguishing memory holding capabilities from those 
holding data memory).

As for how much freedom this design allows in allowing the application 
to construct its own pointers (that are not based on applying a 
displacement to an existing pointer), is less clear.


My understanding of it thus far sort of implies that the bounds would be 
mostly limited to OS-level memory allocations, rather than usable within 
an application (such as for individual arrays or memory allocations).

Could be wrong on this though...


This could at least prevent some sort of "wildly out of bounds" bugs, 
where say one goes so far out of bounds from a mmap or similar as to hit 
another mmap.

More common cases, like going out of bounds on a stack array or heap 
object, I am not sure yet if these are addressed by the capabilities system.

For more conventional cases, going out of bounds with a mmap or similar 
will trigger a fault by landing in unallocated pages between the mmaps.

If the mmap allocates from randomized locations within the address 
space, then it is rather unlikely to have any mmap directly adjacent to 
another mmap.

If the address space is some orders of magnitude larger than the memory 
use of the program, it is also statistically rather unlikely that a 
pointer going off in some random direction will hit anything accessible 
(whereas with a 32-bit program using a significant portion of its 
address space, there is a much higher probability of a garbage pointer 
hitting other memory in-use by the program).



When one goes further, such as to 96-bit addressing, the space is in 
effect so large that (with a strong RNG or "pointer encryption"), it 
becomes pretty much impractical for a program to guess pointers.

So, one can achieve similar effect to a capability, not so much by 
preventing a program from forging pointers, or enforcing bounds checks, 
... but making the address space big enough and random enough that the 
program can't guess the pointers to anything it doesn't already know 
about (interspersed with immense distances of "nothingness").


This wasn't done for all pointers, rather the idea was that there would 
be a 48-bit "near space" or "near quadrant" (representing memory space 
local to the program in question) and an optional (much bigger) "far 
space" (accessible via 128-bit pointers).

If the program had no need for "far space" (probably the vast majority 
of programs), it could mostly ignore its existence. In some of my stuff, 
I describe the organization of the larger "far space" in terms of 
"quadrants" (or "quads"). Despite some possible superficial similarity, 
this should not be confused with x86 style segmented addressing.



In other cases, I would likely prefer my "enforce ACL checks on memory 
pages" approach (even if it knows the address, and can forge a pointer 
to it, it still can't access the address if the code in question does 
not have permission to do so).

However, granted:
By itself, it does not enforce (fine grained) bounds checks (such as for 
array access);
It would require segregating the heap to enforce memory access 
protections, with individual memory objects either unable to transfer 
ownership, or doing so via being copied from one part of the heap to 
another (in some sense, favoring "object identity via abstract handle" 
over "object identity via pointer address").


As noted elsewhere, I was generally using the 16 (or 32) bits cut off of 
pointers for implementing (software enforced) type-tag and bounds checks 
(in addition to it being usable for an ABI level dynamic typesystem).

Granted, using only 12 bits or so for the array bounds, limits bounds 
checks to small arrays (eg, fewer than 4095 elements), but these 
represent probably 99% of the cases where bounds-checks are most useful 
(larger cases need to fall back to a slower and more complex check, 
which generally involves needing to fetch the array bounds from memory).


I at one point considered the possibility of allowing instructions for 
combined memory access and bounds-check, but ended up not doing so as it 
didn't look favorable from a "cost and complexity" perspective.

It could make more sense as a special sub-mode for the 96-bit address 
ops, say:
   (127:112): Bounds Bits  (27:12)
   (111: 64): Base Address (95:48)
   ( 63: 60): Tag Bits     (0x2)
   ( 59: 48): Bounds Bits  (11:0)
   ( 47:  0): Base Address (47:0)

With some way of informing the CPU that it should trap if the Index 
register exceeds the 28-bit array bounds field (or if the pointer does 
not match the expected type-tag).

This would not encode any permissions, but granted, in my case this part 
would be left up to the MMU and encoded via the page tables.

The array bounds would be set up when the array is cast to a pointer.

...

[toc] | [prev] | [next] | [standalone]

#164654

2022-01-26 at 08:34 -0800, Malcolm McLean wrote:
> The idea is to carry meta-data around with the pointer to make
> certain operations, particularly with C, less error-prone.

Perhaps another possible use could be complete address space
randomization, improving existing ASLR techniques.

Mateusz

[toc] | [prev] | [next] | [standalone]

#164655

Mateusz Viste <mateusz@xyz.invalid> writes:
>2022-01-26 at 08:34 -0800, Malcolm McLean wrote:
>> The idea is to carry meta-data around with the pointer to make
>> certain operations, particularly with C, less error-prone.
>
>Perhaps another possible use could be complete address space
>randomization, improving existing ASLR techniques.

It pretty much obsoletes existing ASLR/KASLR techniques.

[toc] | [prev] | [next] | [standalone]

#164657

On 1/26/22 09:43, Bonita Montero wrote:

> So the only usage for me would be a larger address space to
> accomodate larger memory-mapped files. 

    I really like this idea.


-- 
+-------------------------------------------------------------------+
|                      sphinx of black quartz, judge my vow.        |
+-------------------------------------------------------------------+

[toc] | [prev] | [next] | [standalone]

#164658

On 26/01/2022 08:43, Bonita Montero wrote:
> I don't see any sense in logical or physical 128 bit pointers.
> Imagine that memory-density could be shrinked up to 100 times,
> so computers could be equipped with much more memory. But it
> would be impossible have tolerable access-times with an amount
> of memory in the upper margin of 64 bit (that's 16 billion
> gigabytes).
> So the only usage for me would be a larger address space to
> accomodate larger memory-mapped files. But memory-mapped files
> are slow anyway as they don't allow pipelined transfers from
> the disk (except asynchronous read-ahead). An access-facility
> like in a database-system which issues pipelined asynchronous
> operations is much more efficient.
> And have a look at the filesystems: although ZFS data-layout
> allows 128 bit filesystems, its current implementation is
> limited to 64 bit.

How often are you going to be working with a single file more than 2**64 
bytes in size? (Equivalent to 16 million 1TB drives I think.)

Or perhaps you want to be able memory-map every file on every computer 
in the world at the same time?

The various plans for 128 bits anyway don't appear to give that kind of 
addressability. While those uses are so niche that a software solution 
will work perfectly well. Bear in mind that fetching any data from a 
file will be bigger overhead than having to use two 64-bit registers to 
emulate such a pointer.

I think the chip makers are just desperately trying to find more uses 
for wider GP registers.

[toc] | [prev] | [next] | [standalone]

#164662

On 1/26/2022 2:18 PM, Bart wrote:
> On 26/01/2022 08:43, Bonita Montero wrote:
>> I don't see any sense in logical or physical 128 bit pointers.
>> Imagine that memory-density could be shrinked up to 100 times,
>> so computers could be equipped with much more memory. But it
>> would be impossible have tolerable access-times with an amount
>> of memory in the upper margin of 64 bit (that's 16 billion
>> gigabytes).
>> So the only usage for me would be a larger address space to
>> accomodate larger memory-mapped files. But memory-mapped files
>> are slow anyway as they don't allow pipelined transfers from
>> the disk (except asynchronous read-ahead). An access-facility
>> like in a database-system which issues pipelined asynchronous
>> operations is much more efficient.
>> And have a look at the filesystems: although ZFS data-layout
>> allows 128 bit filesystems, its current implementation is
>> limited to 64 bit.
> 
> How often are you going to be working with a single file more than 2**64 
> bytes in size? (Equivalent to 16 million 1TB drives I think.)
> 
> Or perhaps you want to be able memory-map every file on every computer 
> in the world at the same time?
> 

I expect such large mmaps to be exceedingly unlikely.


> The various plans for 128 bits anyway don't appear to give that kind of 
> addressability. While those uses are so niche that a software solution 
> will work perfectly well. Bear in mind that fetching any data from a 
> file will be bigger overhead than having to use two 64-bit registers to 
> emulate such a pointer.
> 
> I think the chip makers are just desperately trying to find more uses 
> for wider GP registers.

Could be.


My preference (in my ISA) had been to use register pairs.


Handling 128-bit data as fixed pairs has both some of the same features 
as having separate registers (such as not having much of the register 
space being "wasted" for narrower values), but in other cases pairs can 
be treated by the hardware (and ISA) as if they were a single larger 
register (without as much cost and complexity as would be associated 
with using separately addressable register pairs).

So, for example: R3:R2, R5:R4, and R7:R6 can be treated as a 128-bit 
register, wheres, say: R6:R5 or R7:R2 or similar cannot...


Though, going the other way and trying to, say, allows for 128x 32-bit 
registers or similar, would have its own issues (doesn't make sense from 
a cost/benefit POV).

Granted, this is for an ISA that is doing everything with a single big 
register file (no separate FPU or SIMD registers).

[toc] | [prev] | [next] | [standalone]

#164663

BGB <cr88192@gmail.com> writes:
>On 1/26/2022 2:18 PM, Bart wrote:


>> I think the chip makers are just desperately trying to find more uses 
>> for wider GP registers.
>
>Could be.

Come on, get real.  The documents referred to in the original post
indicate -very clearly- the whys and wherefores of the Morello architecture.

None of them are "to desperately find more uses for wider GP regisers".

That's just flat out ridiculous.

Security is the goal.

I'll note that capability architectures have been running in production
since the B6500 was released in 1969 (with a 51-bit word where the high
three bits were protected tag bits that differentiated capabilities from
normal 48-bit words).

[toc] | [prev] | [next] | [standalone]

#164668

On 1/26/2022 3:50 PM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 1/26/2022 2:18 PM, Bart wrote:
> 
> 
>>> I think the chip makers are just desperately trying to find more uses
>>> for wider GP registers.
>>
>> Could be.
> 
> Come on, get real.  The documents referred to in the original post
> indicate -very clearly- the whys and wherefores of the Morello architecture.
> 
> None of them are "to desperately find more uses for wider GP regisers".
> 
> That's just flat out ridiculous.
> 
> Security is the goal.
> 

I wasn't saying that security wasn't a goal.


> I'll note that capability architectures have been running in production
> since the B6500 was released in 1969 (with a 51-bit word where the high
> three bits were protected tag bits that differentiated capabilities from
> normal 48-bit words).
> 

Possibly, but:
I feel doubtful that it is necessarily the best approach from a 
cost/benefit perspective.

Not mentioned thus far, as that it is likely to need another 
special-purpose cache mostly to keep track of a bitmap of tag bits or 
similar.

...



It is also notable that historically, computers have tended more for 
fast and cheap solutions to problems, rather than heavyweight and 
expensive solutions.

There were some oddities here, like OoO winning out over VLIW in 
mainstream CPUs, but this may change as Moore's Law comes to an end...
Say, VLIW gets to see its time in the sun in the aftermath of the 
consequences of "The Great Plateau...".


Or such...

[toc] | [prev] | [next] | [standalone]

#164673

On 26/01/2022 21:35, BGB wrote:
> On 1/26/2022 2:18 PM, Bart wrote:
>> On 26/01/2022 08:43, Bonita Montero wrote:
>>> I don't see any sense in logical or physical 128 bit pointers.
>>> Imagine that memory-density could be shrinked up to 100 times,
>>> so computers could be equipped with much more memory. But it
>>> would be impossible have tolerable access-times with an amount
>>> of memory in the upper margin of 64 bit (that's 16 billion
>>> gigabytes).
>>> So the only usage for me would be a larger address space to
>>> accomodate larger memory-mapped files. But memory-mapped files
>>> are slow anyway as they don't allow pipelined transfers from
>>> the disk (except asynchronous read-ahead). An access-facility
>>> like in a database-system which issues pipelined asynchronous
>>> operations is much more efficient.
>>> And have a look at the filesystems: although ZFS data-layout
>>> allows 128 bit filesystems, its current implementation is
>>> limited to 64 bit.
>>
>> How often are you going to be working with a single file more than 
>> 2**64 bytes in size? (Equivalent to 16 million 1TB drives I think.)
>>
>> Or perhaps you want to be able memory-map every file on every computer 
>> in the world at the same time?
>>
> 
> I expect such large mmaps to be exceedingly unlikely.
> 
> 
>> The various plans for 128 bits anyway don't appear to give that kind 
>> of addressability. While those uses are so niche that a software 
>> solution will work perfectly well. Bear in mind that fetching any data 
>> from a file will be bigger overhead than having to use two 64-bit 
>> registers to emulate such a pointer.
>>
>> I think the chip makers are just desperately trying to find more uses 
>> for wider GP registers.
> 
> Could be.
> 
> 
> My preference (in my ISA) had been to use register pairs.
> 
> 
> Handling 128-bit data as fixed pairs has both some of the same features 
> as having separate registers (such as not having much of the register 
> space being "wasted" for narrower values), but in other cases pairs can 
> be treated by the hardware (and ISA) as if they were a single larger 
> register (without as much cost and complexity as would be associated 
> with using separately addressable register pairs).
> 
> So, for example: R3:R2, R5:R4, and R7:R6 can be treated as a 128-bit 
> register, wheres, say: R6:R5 or R7:R2 or similar cannot...

I've seen this approach in a few processors. I first came across it on 
Z8000 I think, where the 16 x 16-bit registers R0..15 can also be 
accessed as:

    16 x  8-bit registers (over R0..7 only)
     8 x 32-bit registers (as RR0  RR2 .. RR14)
     4 x 64-bit registers (as RQ0 RQ4 RQ8 RQ12)

(So 64-bit registers 40 years ago! Although probably there were 
limitations on what could be done with such a type)

Like yours, the wider registers couldn't overlap, as in R6:R7 and R7:R8.

Such a scheme for 128 bits wouldn't be objectionable. Actually it would 
be useful the other way too: C is still primarily 32 bits, but you can't 
conveniently use one 64-bit register to hold two independent 32-bit values.

> 
> 
> Though, going the other way and trying to, say, allows for 128x 32-bit 
> registers or similar, would have its own issues (doesn't make sense from 
> a cost/benefit POV).

I actually use quite a few 128-bit types (actual 128-bit ints, and 
composite ones like slices and variants).

These are expressed using a virtual 128-bit type in my IL, but are 
implemented as two 64-bit registers on x64, not necessarily consecutive. 
(Sometimes, half of it can be on the stack!)

The funny thing is that x64 /has/ 128-bit registers (xmm0 etc), but not 
in a form that I found useful for my purposes.

[toc] | [prev] | [next] | [standalone]

#164675

On 1/27/2022 6:11 AM, Bart wrote:
> On 26/01/2022 21:35, BGB wrote:
>> On 1/26/2022 2:18 PM, Bart wrote:
>>> On 26/01/2022 08:43, Bonita Montero wrote:
>>>> I don't see any sense in logical or physical 128 bit pointers.
>>>> Imagine that memory-density could be shrinked up to 100 times,
>>>> so computers could be equipped with much more memory. But it
>>>> would be impossible have tolerable access-times with an amount
>>>> of memory in the upper margin of 64 bit (that's 16 billion
>>>> gigabytes).
>>>> So the only usage for me would be a larger address space to
>>>> accomodate larger memory-mapped files. But memory-mapped files
>>>> are slow anyway as they don't allow pipelined transfers from
>>>> the disk (except asynchronous read-ahead). An access-facility
>>>> like in a database-system which issues pipelined asynchronous
>>>> operations is much more efficient.
>>>> And have a look at the filesystems: although ZFS data-layout
>>>> allows 128 bit filesystems, its current implementation is
>>>> limited to 64 bit.
>>>
>>> How often are you going to be working with a single file more than 
>>> 2**64 bytes in size? (Equivalent to 16 million 1TB drives I think.)
>>>
>>> Or perhaps you want to be able memory-map every file on every 
>>> computer in the world at the same time?
>>>
>>
>> I expect such large mmaps to be exceedingly unlikely.
>>
>>
>>> The various plans for 128 bits anyway don't appear to give that kind 
>>> of addressability. While those uses are so niche that a software 
>>> solution will work perfectly well. Bear in mind that fetching any 
>>> data from a file will be bigger overhead than having to use two 
>>> 64-bit registers to emulate such a pointer.
>>>
>>> I think the chip makers are just desperately trying to find more uses 
>>> for wider GP registers.
>>
>> Could be.
>>
>>
>> My preference (in my ISA) had been to use register pairs.
>>
>>
>> Handling 128-bit data as fixed pairs has both some of the same 
>> features as having separate registers (such as not having much of the 
>> register space being "wasted" for narrower values), but in other cases 
>> pairs can be treated by the hardware (and ISA) as if they were a 
>> single larger register (without as much cost and complexity as would 
>> be associated with using separately addressable register pairs).
>>
>> So, for example: R3:R2, R5:R4, and R7:R6 can be treated as a 128-bit 
>> register, wheres, say: R6:R5 or R7:R2 or similar cannot...
> 
> I've seen this approach in a few processors. I first came across it on 
> Z8000 I think, where the 16 x 16-bit registers R0..15 can also be 
> accessed as:
> 
>     16 x  8-bit registers (over R0..7 only)
>      8 x 32-bit registers (as RR0  RR2 .. RR14)
>      4 x 64-bit registers (as RQ0 RQ4 RQ8 RQ12)
> 
> (So 64-bit registers 40 years ago! Although probably there were 
> limitations on what could be done with such a type)
> 
> Like yours, the wider registers couldn't overlap, as in R6:R7 and R7:R8.
> 
> Such a scheme for 128 bits wouldn't be objectionable. Actually it would 
> be useful the other way too: C is still primarily 32 bits, but you can't 
> conveniently use one 64-bit register to hold two independent 32-bit values.
> 

Going the other way, and allowing independent access to 32-bit parts, 
would result in 128 logical registers. One issue here is that there is 
no good way to encode this within the current ISA.


I actually had to get a little hackish in order to support the current 
set of 64x 64-bit GPRs.

Originally, there were 32x 64-bit GPRs, which could be used as 16x 
128-bit. I later (at first) expanded it to 32x 128-bit, but this left 
half the register space being (only) accessible to 128-bit instructions.

I later added some ugly hack encodings to make it possible to use 
R32..R63 as 64-bit registers; but technically the existence of R32..R63 
remains as an optional extension (and, the C ABI partly sweeps their 
existence under the carpet in a few areas).

There are occasional cases where such a large register space comes in handy.



That said, it is possible in many cases to pack multiple smaller values 
into a 64-bit register and use them SIMD style, where the ISA currently 
supports:
   2x Int32 (__vec2si / __vec2ui)
   4x Int16 (__vec4sw / __vec4uw)
   2x Float32 (S.E8.M23) (__vec2f)
   4x Float16 (S.E5.M10)) (__vec4sf)

And, 128-bit:
   2x Float64 (S.E11.M52) (__vec2d, '_Complex double')
   4x Float32 (S.E8.M23) (__vec4f, __quatd, ...)


And a few special cases (in 32-bits, second tier):
   4x FP8S (S.E4.M3)
   4x FP8U (E4.M4)

There are a few unusual formats as well (second tier):
   3x FP21 (S.E5.M10 + M5) (__vec3fq)
   3x FP42 (S.E8.M23 + M10) (__vec3fx)
These cases are similar to the 4x cases, but interpret the 'W' element 
as extension bits for the other elements.

Where, second-tier formats are not directly supported by SIMD 
instructions, but have dedicated converter ops so can be used indirectly.



Some extra funky variants pop up when the dynamic type-system get involved:
Flonum, which is in effect a Double but shifted right 2-bits, with tag 
bits in the MSB;
Packed Vec2F (2x Float28) and Vec3F (3x FP21, but with the Z-ext bits 
cut off to encode the type-tag).


Some of these have been mapped to C as extension types:
   A subset of the GCC vector extensions is supported
     (to what extent there is overlap)
   It reuses "__m64" and "__m128" albeit with looser semantics.
     These function more like the vector analog of "void*"
     Can be used to facilitate cast-conversion between unrelated types.


The dynamic (tagged) types are also exposed in C as "__variant", which 
may hold any number of types at runtime (can be operated on, cast 
to/from various other types, type-checked via an "__instanceof" 
operator, ...).

Its performance is a bit worse than native types (implemented almost 
entirely via runtime calls), but "surprisingly not completely awful" 
(or, like, "you can use this, within reason, and it probably shouldn't 
completely wreck performance").


There is also a (more obscure) "fat variant" ('__variantf') which uses 
128-bit storage, and can (natively) hold some 128-bit values. Runtime 
support for this format is a bit lacking though.

Note, not to be confused with C++ "variant", which is almost entirely 
different. It is more like a tagged pointer scheme as is commonly used 
in implementing dynamically typed languages.


>>
>>
>> Though, going the other way and trying to, say, allows for 128x 32-bit 
>> registers or similar, would have its own issues (doesn't make sense 
>> from a cost/benefit POV).
> 
> I actually use quite a few 128-bit types (actual 128-bit ints, and 
> composite ones like slices and variants).
> 

Yeah, I have sorta done my own ISA here (as a hobby project).

In my case, 128-bit integers are supported as an ISA extension.

Operations which operate on 128 bit values:
   Packed PADDF/PSUBF/PMULF (4x Single)
     PADDD/SUBD/PMULD (2x Double)
   MOV.X (128-bit Load/Store)
   ADDX/SUBX, ANDX/ORX/XORX (Basic ALU ops, 128-bit)
   CMPEQX/CMPGTX, ... (Integer Compare, 128-bit)
   SHADX/SHLDX (Arithmetic and Logical Shift, 128-bit)
   ...

The main restriction on 128-bit ops in my current ISA is that one can 
only run them one-at-a-time.

These instructions basically eat all 3 lanes at the same time, and as a 
result are not allowed in bundles.



> These are expressed using a virtual 128-bit type in my IL, but are 
> implemented as two 64-bit registers on x64, not necessarily consecutive. 
> (Sometimes, half of it can be on the stack!)
> 
> The funny thing is that x64 /has/ 128-bit registers (xmm0 etc), but not 
> in a form that I found useful for my purposes.
> 

Having the ability to do 128-bit stuff in GPR space is actually fairly 
convenient.

It allows sharing a lot of instructions between the SIMD and integer ops.


It isn't so great at conventional benchmarks (such as Dhrystone), but it 
can do pretty well at things like software-rendered OpenGL.

If it could be scaled up to the same clock speed as my PC, it is likely 
it would significantly beat out my PC at this task.


Also, relative to clock speed, its Dhyrystone score also falls inline 
with the MSVC vs GCC discrepancy (Dhrystone compiled with GCC seems to 
give noticeably higher numbers than Dhrystone compiled with MSVC).

Scaled relative to clock-speed, Dhystone on my ISA would have been 
modestly slower than the MSVC result.

Clang was intermediate, but much closer to the GCC score than the MSVC 
score.


In my case, I have eliminated most of the "obvious faults" in my 
compiler's code generation, but it does still have a few weak areas in 
terms of its register allocator, and lack of any real "high-level" 
optimizations (does not inline/unroll/reorder/..., so for the most part 
code is executed more-or-less as-written).

At the IR level, it is not using a "true" SSA either, mostly because 
most of my attempts to make "phi" operators work have tended to blow up 
in my face. So, it uses a sort of "pseudo-SSA" internally, and any 
values which are not statically assigned to a register are spilled to 
the stack (the compiler may assign the "top N" variables in a given 
function to registers, and give a significant boost here to any 
variables with the "register" keyword, ...).

Any other variables are demand-loaded within a given basic-block, and 
spilled back to the stack afterwards.

In theory, a phi operator could be used to turn these spills and reloads 
into direct register moves, but this requires the ability to "make it work".


However, did have moderate success with a few optimizations for cases 
where there were sufficiently few variables that all the variables in 
the function could be statically assigned to registers, the compiler 
will do so. This can pretty much eliminates any register spills for 
local variables within a function, but does have its own limitations 
(using things like stack arrays, taking the address of a variable, etc, 
will break the ability to use this optimization for a given function).

Another related optimization may skip stack-frame creation for certain 
"pure leaf" functions, which:
   May not perform any function calls (including implicit runtime calls);
   Needs to fit entirely within scratch registers;
   No local arrays or by-value structs;
   ...

...

[toc] | [prev] | [next] | [standalone]

#164676

Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 25.01.2022 um 09:31 schrieb BGB:
>> 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);
>> 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, ...).
>> 
>> 
>> 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).
>> 
>> ...
> 
> Where's the docuemntation for Morello supporting 128 bit pointers ?

Aside from the AAELF64 ABI link elsethread, more information can be found at
the CHERI project: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

AFAIU, ARM Morello implements the ISA as specified by CHERI. The CHERI
project developed the general model, ISA extensions for various existing
hardware architectures, an example ABI for common POSIX C environments, and
sponsored software implementations, including an entire port of FreeBSD--
compiler, kernel, and userspace--to the new ISA and ABI.

This 2019 paper details the extension for typical POSIX C ABIs: "CheriABI:
Enforcing Valid Pointer Provenance and Minimizing Pointer Privilege in the
POSIX C Run-time Environment",
https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904-asplos-cheriabi.pdf

Regarding pointer width, see section 2, page 4: "In implementation, CHERI
extends 64-bit addresses with metadata in both the in-register and in-memory
representations, increasing the in-memory size of pointers to 128 bits, plus
an out-of-band tag bit."

[toc] | [prev] | [next] | [standalone]

#164695

Scott Lurndal <scott@slp53.sl.home> wrote:
> https://www.theregister.com/2022/01/21/arm_morello_testing/
> https://www.arm.com/architecture/cpu/morello
> https://developer.arm.com/documentation/ddi0606/latest

It's probably worth starting at the CHERI introductory documentation, since
that's trying to explain the concepts at a higher level, while Morello is a
specific implementation:

Introduction
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-941.pdf

C/C++ Programmers Guide
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf

Architecture reference manual (v8)
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-951.pdf
(describes RISC-V implementation but doesn't include Morello specifics,
which have been designed separately by Arm)

Theo
(on the CHERI team, but speaking personally)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web