https://www.theregister.com/2022/01/21/arm_morello_testing/
https://www.arm.com/architecture/cpu/morello
https://developer.arm.com/documentation/ddi0606/latest

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Scott Lurndal 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

.... and here I'm having a hard enough time keeping things straight in
16-bit land :/

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmHu8JwACgkQbWVw5Uzn
KGB9aQ/+NzrNULP1zaEUTpVO5KrhCXxfAmGStDDq1yopl95H81ZyOOWOkswUzC0B
n8Xkb/drMtWnbjeHbR0DS3qZ/cSiCjRx9y5sPiioMLMhzwqtLRZtHTWHkx51micS
2e9fKT5+1W1KM/IBvU2biU/6ob3g7u//dcSDQIT/1LHKW4tq4AOdj7L0nGOn9d/t
1FdNyiJhMHWlcidXvQaOR9umGnvRtKPIhjF7cgkY9UMA8Vng6uc1ihjiazG68N65
E6BMTG73DinjgjoG/OCkIVhlkDvKjD5DLIrMUwY6LczGl78IokcFmh+UKGp2vVlW
qHmZuWbWBt4sBrwv4pbsW9gGGCqnf9WfGSBk56DgdU2S46KlRy1ryOxIhpILAofT
r8l5EuHXRc8EWRkAfYY3EBscBrtxMo43MFtZEyyHteHN26h1KCOIldaD+LE9UJGs
6hLZOrRZufN+xiZwygHX++U3jKL8klemozCiiaJmyOq/cQk8RhwNn0Lcp4auT89w
CKqU9o+LoaUw3GJOt4WpmMWVELKpuMovOMrBvXxADYnZxu5bBHjwjzBf+R/jNLOC
9/PeeU1O2/Z6TXzRBci5BxnAJ1q30/jFH7gDp/GtbY1fz5t+C8EHDjLDN2CU+wTj
wPFC0l61le0Gmgf96CtdXyDcrWOw3U49CDf56j743hbIk9NXjsc=
=IzVd
-----END PGP SIGNATURE-----

--
|_|O|_| Github: https://github.com/dpurgert
|_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
|O|O|O|

On 1/24/2022 12:12 PM, Scott Lurndal 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

Going OT here...

FWIW, when I designed my own ISA (BJX2, mostly on FPGA), I decided to
take a somewhat different approach:
Memory pages can have an associated UID+GID pair and/or ACL;
Execution contexts may have a "keyring" which is checked against the ACL
(this would nominally be per-thread, but there is a possibility of
scoping it based on the page containing the currently executing
instruction, the keyring effectively functioning like an inverted ACL,
nominally limited to 4 entries if encoded directly, but an indirect
approach via ACLs can allow for an expanded set of keys);
....

The model used is fairly similar to that used in Unix style filesystems
(though, it may or may not be a separate namespace from that of the VFS).

In this case, these are handled by the MMU, and the access
determinations are signaled back to the L1 caches (implementation cost
for this being not significantly higher than for a more traditional
"protection ring" scheme).

Note that both TLB miss and ACL miss events would be handled by the OS
in this case (via interrupt handlers), so these are responsible for
fetching the relevant information from the page tables and ACL tables.

Information about the ACL in use by a page is encoded in the TLB entries
(along with the addresses and similar), and is (like the physical
address for the page) fetched from the page table.

From the perspective of the MMU itself, the ACL cache is mostly in
terms of A/B pairs and access-mode flags (with both this cache and the
TLB being set-associative).

In this case, it isn't necessary to expand pointers, and most remain as
64 bits (though the ISA itself is limited to an effective 48 bit address
space with 64-bit pointers).

The remaining 16 bits for pointers serve other purposes:
Data Pointers: Mostly used as type-tags for dynamically-typed objects;
Code Pointers: Can encode flag state and execution mode (*).

*: Function call/return, these capture some parts of the execution
state. These bits are also used for inter-ISA jumps (the CPU core
supports both my own ISA and also RV64I).

For raw C pointers, the high order bits are usually left zeroed.

Though, granted, some people have said that effectively trying to build
a capability system on top of ACLs is a terrible approach, but it seems
to work and makes more sense from an implementation cost perspective.

It is also almost entirely transparent from C (the C code does not need
to know or care that anything special is going on, it just sees
everything in terms of a fairly conventional linear address space with
64-bit pointers; with it just sort of "magically" having a protection
fault if it tries to access memory it doesn't have access permissions
for via its ACLs).

As can be noted, the ACL + keyring protection works in that access in
mostly granted or denied based on the contents of a system register that
is not accessible to the user-level ISA.

There was support for an optional expanded 96-bit address space (using
register pairs as pointers).

There was at one point an idea for "faking" more traditional object
capabilities via using part of the 96-bit address space with randomized
or "encrypted" addresses, but there are tradeoffs here. It would either
be "weak" (pointers would be forgeable) or "annoying" (a pointer is only
accessible within a certain context, and would require special system
calls to transfer the pointer from one context to another, which would
"re-encrypt" the high-order bits of the pointer for the new context).

Using the expanded pointers does visibly effect C code though, mostly:
The integer representation for these are 128 bits rather than 64;
May be cast to/from '__int128' rather than 'long' or similar.
They generally involve the use of the "__huge" modifier:
"int __huge *ptr;" or similar.
They are not generally intended for "general use" though.
...

It is also possible for code to operate within the 96-bit space via
narrow pointers, where it behaves more like 8086 style segmented
addressing, or (more technically accurate) like the addressing scheme in
the 65C816 (just with two 48 bit parts, rather than two 16 bit values).

Implicitly, this latter mode is also still usable from RV64I mode (just
with it being unable to access anything outside of its local 48-bit
"quadrant").

....

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 ?

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

....

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.

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

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

=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> writes:
>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.

I've spent the last decade working with the ARM64 architecture,
and we've built three generations of high-end ARM64 processors.

The cost for internally widening the register data paths is minimal,
given the current existance of 128-bit (or larger for SVE) SIMD
registers.

One issue is the storage for the capability tags (basically one
bit for every 8-bytes of memory capable of storing capabilities);
this leads to changes of the L1/L2/L3 cache hierarchies to manage
the bit (which is required to be stored where software cannot
reach it - a segregated section of DRAM or on-board SRAM).

The vast majority of ARM customers (Applem Cavium excepted) use IP provided
by ARM (e.g. Cortex A series or the Neoverse N2 series); for those, enabling
Morello will be a simple configuration option in the IP.

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

Indeed. And such pointer manipulation is still allowed, but provided
via specialized instructions instead of ad-hoc instruction sequences,
which as an added benefit can produce better performance.

>People dream about what is ideal but purchase what is available.
>Decisions in businesses are made based on their latter behaviour.

Note that Morello is still in the nature of an experiment.

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

BGB <cr88192@gmail.com> writes:
>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).

For a bespoke ASIC that already supports ARM's 128-bit SIMD registers, the
internal bus structures need another bit (129th) for the capability
bit, so its not so bad.

For the general purpose registers, they'll need 65 additional bits
each (for 32 registers, so 264 bytes or so of on-chip flops or
memories per core/thread) - on a 8 billion transister SoC ASIC, that's in the noise.

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 ?

On 1/25/2022 12:23 PM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> 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).
>
> For a bespoke ASIC that already supports ARM's 128-bit SIMD registers, the
> internal bus structures need another bit (129th) for the capability
> bit, so its not so bad.
>
> For the general purpose registers, they'll need 65 additional bits
> each (for 32 registers, so 264 bytes or so of on-chip flops or
> memories per core/thread) - on a 8 billion transister SoC ASIC, that's in the noise.

OK.

The core I have is arguably on the lower end (mostly targeting Spartan-7
and Artix-7 FPGAs; boards typically in the $100 to $300 range).

Not exactly huge, lots of corner cutting, ...

Was still able to fit a lot more than I had originally imagined.

Granted, MHz isn't exactly that high (my cores are mostly running at
50MHz), but alas... (can run Doom pretty OK, and Quake with a bit of lag).

Some things were added mostly because I was able to figure out ways to
do them "affordably":
128-bit ALU ops by effectively ganging up 64-bit units horizontally;
FPU SIMD ops via internal pipelining tricks;
...

Granted, it is 3-wide VLIW, which costs more than a 1-wide RISC.
However, the cost differences between a 1-wide RISC and 3-wide VLIW were
relatively modest, but a VLIW is a fair bit more capable and can deliver
better performance.

In terms of the pipeline design, there also isn't a huge difference
between a VLIW and a RISC, apart from a VLIW core having more register
ports and multiple ALUs and similar.

It has a register space which could be interpreted either as 32x
128-bits, or 64x 64-bits. One can choose whether to see them as pairs of
64-bit registers being merged into 128 bits, or as 128-bit registers
being split up and used as 64-bit halves.

It was also a cheaper than going over to superscalar.

Actual higher-performance OoO designs are mostly out of the reach of
what can effectively be pulled off on something like an typical
Spartan-7 or Artix-7 dev board (and higher end boards are significantly
more expensive).

Well, there are also ICE40 boards, but, these are not significantly
cheaper, but somewhat less capable (can maybe fit an RV32I core, but
more commonly people go for 16-bit designs on these).

There is FPU SIMD, but it doesn't have multiple FPUs internally, but
instead feeds each element through the FPU sequentially. Can still work
out faster than using scalar FPU ops though; also the FPU is corner cut
as well, and not strictly IEEE conformant (only does ADD/SUB/MUL,
doesn't reliably give 0.5 ULP, denormal-as-zero semantics, ...).

The ALU ops are because there are multiple ALUs (one for each lane), and
in many cases one can map a 128-bit ALU op to two 64-bit ALU ops running
in parallel (or, for ADD/SUB, it will effectively daisy chain the ALUs).

For 128-bit shift, was able to pull it off internally by using two
64-bit funnel-shift units (which actually worked out cheaper than the
original barrel shift units as well, ...).

As noted, I do have an extension for 96 bit addressing, however:
The L1's mostly handle it with hackery:
Doesn't store a full address, but hashes the high-order bits;
When used, it effectively cuts the TLB associativity in half;
...

So, the L1 effectively stores 96 bit addresses hashed down to 64 bits,
and the TLB runs 48-bit matches in an even/odd configuration (depending
mostly on the tag bits in the TLB entries).

There are also some pretty big costs though related to the L2 cache and
DDR interface. For performance reasons ended up with 64-byte (512 bit)
cache lines in the L2 cache, but these are not so great for LUT cost...

Trying to transfer data to/from DDR as 16-byte / 128-bit bursts though
is not so good for DRAM bandwidth...

As a result, a considerable chunk of FPGA LUT budget is going into the
DDR PHY and L2 cache and similar.

....

On 1/25/2022 12:49 PM, Bonita Montero 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 ?

It is my understanding of the various pieces of information I have read
about it thus far (some linked to by the pages mentioned in the OP),
that it is a modified Aarch64 where it either runs in normal A64 mode
(with 64-bit pointers), or runs in C64 mode (with 128-bit pointers), and
in C64 mode pretty much all of the pointers are widened to 128 bits.

There is apparently also a different C ABI for it, etc...

Eg:
https://github.com/ARM-software/abi-aa/blob/main/aaelf64-morello/aaelf64-morello.rst

What is unclear is if C64 mode still allows for using 64-bit pointers
(well, or at least without needing to synthesize them at load time or
similar).

However, the address space itself appears to remain as 64 bits, with the
high bits of the capability mostly holding bounds-check information and
permission flags and similar.

....

It is, as noted, all very different from my own approach (eg: ACL
checking and R/W/X permissions).

Well, also my case doesn't have built-in bounds checks, but there were
some instructions which allow for performing bounds-checks, namely an
instruction which would compare an index value against Base(59:48) and
set a flag based on whether it goes out of range (this could be used for
a conditional branch to an array-bounds check handler; used either for a
bounds check handler, or to handle checks specially for arrays with more
than 4095 elements).

In this case, Base(63:60) were interpreted as a type-tag, which would
also be checked to verify that it held the tag for an array (0x2 in this
case).

Say:
Base(63:60)!=2, Branch to handler.
Index>=Base(59:48), Branch to handler.
Perform Access.

The handler would do more advanced checks to determine what to make of
this case.

This case adds a few extra clock cycles per array access (and doing so
was left up to the compiler), but was "mostly sufficient" for Java-style
access patterns (with some restrictions, it can also be used for
dynamically-typed languages).

....

BGB <cr88192@gmail.com> writes:
>On 1/25/2022 12:49 PM, Bonita Montero 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 ?

If "Bonita" had bothered to read the links quoted, that question
would answer itself.

>>> ...
>>
>> Where's the docuemntation for Morello supporting 128 bit pointers ?

Pointers to all the documentation was in the orignal article "Bonita"
had replied to.

>
>
>It is my understanding of the various pieces of information I have read
>about it thus far (some linked to by the pages mentioned in the OP),
>that it is a modified Aarch64 where it either runs in normal A64 mode
>(with 64-bit pointers), or runs in C64 mode (with 128-bit pointers), and
>in C64 mode pretty much all of the pointers are widened to 128 bits.

This is correct. There is also a PCC (Program Counter Capability) register
and a DDC_ELx (Default Data Capability) register at each exception level.

For example, the ADRDP instruction will create a DDC relative address.

>There is apparently also a different C ABI for it, etc...

By necessity, since function call parameter passing and register
save/restore sequences are defined by the ABI.

>What is unclear is if C64 mode still allows for using 64-bit pointers
>(well, or at least without needing to synthesize them at load time or
>similar).

The DDC and PCC accomodate 64-bit pointers (within the bounds defined by
the capability - which isn't much different from permissions on pages).

>
>
>However, the address space itself appears to remain as 64 bits, with the
>high bits of the capability mostly holding bounds-check information and
>permission flags and similar.

The maximum physical address supported by AArch64 at this point in
time is 52-bits. Most only support 48-bits. The architecture provides
a mechanism where software can use the high 8 bits of a virtual address as
a tag field ignored by the processor - but that needs to be configured
by the Operating system on behalf of the task (tbi bit - top byte ignored).

On 25/01/2022 18:54, BGB wrote:
> On 1/25/2022 4:04 AM, Öö Tiib wrote:
>> On Tuesday, 25 January 2022 at 10:32:01 UTC+2, BGB wrote:

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

I think this is going to vary depending on the ancestory of the code.
In DOS and 16-bit Windows programming, you had a mess of "far" and
"near" pointers, and different sizes. There were many tricks/hacks used
for re-using high bits of pointers, xor'ing pointers so you get
double-linked lists with just one pointer, and so on. Some of this code
and attitude was moved directly over to 32-bit Windows. Programmers
viewed everything as a fixed ABI - you /knew/ "long int" was 32-bit and
big enough for a pointer. There was no C99 in MS' world at the time,
nor any attempt at standardisation or portability - you didn't use
"uintptr_t" for an integer matching a pointer, you used "unsigned long",
"DWORD", or other such "wintypes.h" name.

The move to 64-bit Windows involved a great deal of work here for a lot
of code. In particular, programmers had made two assumptions about
"long int" - that they were always 32-bit, and that they could always
hold a pointer. One of these had to break (MS choose the later), and
with it broke a lot of code. 30 years after the Alpha brought 64-bit to
the workstation, most of the programs run on Windows systems are still
32-bit.

However, for those that made the fixes and change of styles to get
64-bit to work, I don't /think/ supporting 128-bit pointers will cause
nearly as much of an issue.

For code and programmers from the *nix world, mixing 32-bit and 64-bit
targets has been the norm for decades. Programmers usually make far
fewer assumptions about sizes, endianness, and other portability issues.
It is common that the same source can be compiled for different 32-bit
or 64-bit targets without much trouble. (Yes, there are ifdef's and the
like - but those are mostly in standard headers and library headers, not
application code.) So again, moving to 128-bit pointers will not be as
hard as one might think.

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

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

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.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>I don't see any sense

That's been pretty clear all along.

Am 26.01.2022 um 16:53 schrieb Scott Lurndal:

> Bonita Montero <Bonita.Montero@gmail.com> writes:

>> I don't see any sense

> That's been pretty clear all along.

And you also can't say why this would make sense.

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.

Am 26.01.2022 um 17:34 schrieb Malcolm McLean:
> 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.

Better avoid C.

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

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?

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.

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.

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.

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