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 1 of 2  [1] 2  Next page →

#164587 — Here come the 128-bit pointers

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

[toc] | [next] | [standalone]

#164590

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

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

#164595

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


...

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

#164604

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 ?

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

#164605

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

...

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

#164606

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. 

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

#164614

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

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

#164619

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

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

#164620

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.

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

#164626

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.

...

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

#164639

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.

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

#164691

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)

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

#164624

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 ?

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

#164627

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

...

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

#164628

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

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

#164641

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.

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

#164644

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

That's been pretty clear all along.

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

#164645

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.

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

#164646

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.

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

#164647

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.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web