Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #164627
| From | BGB <cr88192@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Here come the 128-bit pointers |
| Date | 2022-01-25 15:59 -0600 |
| Organization | A noiseless patient Spider |
| Message-ID | <ssprrc$d8h$1@dont-email.me> (permalink) |
| References | <RZBHJ.39378$gX.11188@fx40.iad> <sso8kg$82t$1@dont-email.me> <ssochk$t26$1@dont-email.me> <sspgoj$s5l$1@dont-email.me> |
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). ...
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-24 18:12 +0000
Re: Here come the 128-bit pointers Dan Purgert <dan@djph.net> - 2022-01-24 18:31 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-24 15:41 -0600
Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-25 08:25 +0100
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-25 02:31 -0600
Re: Here come the 128-bit pointers Öö Tiib <ootiib@hot.ee> - 2022-01-25 02:04 -0800
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-25 14:48 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-25 11:54 -0600
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-25 18:23 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-25 14:17 -0600
Re: Here come the 128-bit pointers David Brown <david.brown@hesbynett.no> - 2022-01-26 09:36 +0100
Re: Here come the 128-bit pointers Theo <theom+news@chiark.greenend.org.uk> - 2022-01-28 22:12 +0000
Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-25 19:49 +0100
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-25 15:59 -0600
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-25 22:25 +0000
Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-26 09:43 +0100
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 15:53 +0000
Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-26 17:25 +0100
Re: Here come the 128-bit pointers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-01-26 08:34 -0800
Re: Here come the 128-bit pointers Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-26 17:57 +0100
Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-26 17:10 +0000
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 17:27 +0000
Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-26 17:41 +0000
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 18:05 +0000
Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-26 18:23 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-26 14:42 -0600
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-26 14:30 -0600
Re: Here come the 128-bit pointers Mateusz Viste <mateusz@xyz.invalid> - 2022-01-26 19:36 +0100
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 18:52 +0000
Re: Here come the 128-bit pointers tth <tth@none.invalid> - 2022-01-26 21:01 +0100
Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-26 20:18 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-26 15:35 -0600
Re: Here come the 128-bit pointers scott@slp53.sl.home (Scott Lurndal) - 2022-01-26 21:50 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-26 20:34 -0600
Re: Here come the 128-bit pointers Bart <bc@freeuk.com> - 2022-01-27 12:11 +0000
Re: Here come the 128-bit pointers BGB <cr88192@gmail.com> - 2022-01-27 13:40 -0600
Re: Here come the 128-bit pointers William Ahern <william@25thandClement.com> - 2022-01-27 13:28 -0800
Re: Here come the 128-bit pointers Theo Markettos <theom+news@chiark.greenend.org.uk> - 2022-01-28 23:18 +0000
csiph-web