5 ms·
Hardware capabilities seem like they could be an interesting alternative to traditional separate address space memory management; they could allow you to have f
by lambda 8y ago
Hardware capabilities seem like they could be an interesting alternative to traditional separate address space memory management; they could allow you to have fine grained access control to individual objects in memory without having to have separate address spaces via a TLB.
However, they seem to be trying to stuff so much into the capability; there's a base, a length, and offset, permissions, sealing bits, extra bits reserved for user permissions, and so on. They're 256 bytes, 4 times the size of a normal pointer, plus an extra tag bit for validity.
They do have a compressed 128 bit version, with various alignment constraints, but it seems like they are trying to stuff too much functionality into these capabilities.
I feel like it might be more instructive to start from a much simpler capability design, with just simple fat pointers with a few bits used for tagging (due to alignment, or not needing to use the full 64 bit address space), and see how far you can get with that, without adding in all of the extra features and needing huge pointers or funky compression that imposes much stricter alignment constraints.
- gumby 8y agoIt’s a research project. It’s not the first capability based architecture but it’s one with which you can run lots of different kinds of experiments.
- jabl 8y agoI recall skimming one of their papers, where they argued that they need base/length/offset in order to efficiently support existing C semantics. If you drop C compatibility you can get by with less.