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.

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

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.

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.

....

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

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

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

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

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.

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.

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

David Brown <david.brown@hesbynett.no> wrote:
> Where I see the problem, however, is the challenge of introducing
> 128-bit integers to C. (It might be rare to need to convert a pointer
> to an integer, but people do it sometimes.) If you want to have a
> 128-bit "uintptr_t", it means you also need a 128-bit "intmax_t".

I'm not sure what we do with intmax_t, but uintptr_t is the way to handle a
type that might contain a pointer or an integer (when compiling with every
pointer is a capability). It's 128 bits, and it holds either a capability,
or something aligned as a capability but without the tag being set (ie an
integer).

If you load a capability via a 64 bit regular load instruction you just get
the address, and the metadata is invisible. You can refer to the upper bits
by loading the next 64 bits from memory, but that's not a capability.

There are also instructions for querying the metadata of an existing
capability.

If you try to deconstruct a capability by doing something to it (eg storing
a byte in the middle of it), the tag is cleared and it stops being a
capability.

> Are you going to make size_t 128-bit, or keep it at 64-bit? Should you
> now have a 128-bit "long long int"? Should your fundamental 128-bit be an
> extended integer type "__int128_t"? "Long long long int" ? Should you
> give up on uintptr_t entirely, and say that anyone who wants to manipulate
> the bits of a pointer should use memcpy and unsigned char* pointers?

I don't see why you would want size_t to be 128 - there's never more than 64
bits of address space. Likewise you don't have 128 bit integer registers -
you have registers that can hold either a 64 bit integer or a 128 bit
capability.

In other words you can cast capabilities to intptr_t and hold that in the
register file or in memory, but you can't cast intptr_t to any kind of
integer and be able to go back again.

(Our previous MIPS design had them as separate pointer registers a la 68K, but
saving them has an impact on context switch overhead. For ARM it made sense
to merge them into the integer register file, also due to limitations on
instruction encoding space)

> It will be interesting to see how this all plays out.

It will indeed. It's a large scale experiment, so it will be interesting to
see how it goes.

Theo
(declaration: on the CHERI team but not a compiler person, I may have the
wrong end of the stick in places)

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)