6 ms·

Sparse on details. Presumably will be based on the existing Linear Address Masking/Upper Address Ignore specs, which are equivalent, and will be similar to CHE

Sparse on details. Presumably will be based on the existing Linear Address Masking/Upper Address Ignore specs, which are equivalent, and will be similar to CHERI. If so it needs to be opt-in or at least opt-out per process, because many language runtimes use these pointers bits to optimize dynamic types, and would suffer a big performance hit if they were unable to use them.

monocasa 1y ago
Not a whole lot of language runtimes (if any) really depend on upper address ignore. AFAIK, AMD only added it in Zen4.
- fooker 1y ago
  Lua does
  - pansa2 1y ago
    I thought one of Lua’s selling points is that it’s written in highly standard-compliant C code. I wouldn’t expect it to do anything non-portable like bitwise manipulation of pointers?
    - sparkie 1y ago
      It's fine to use techniques like this in standard C provided you guard them with the preprocessor and provide a fallback option on unsupported hardware.
      - wahern 1y ago
        PUC Lua doesn't use these tricks; every value in the VM is represented with a POD struct with explicit tag and value members. The OP may have been thinking of LuaJIT, which uses NaN boxing, but not pointer tagging. PUC Lua does rely on two's complement integer representation, though, as well as long long, while nominally adhering to C90, so not quite strictly conforming.
- erichocean 1y ago
  The JVM does with the ZGC garbage collector, did a really nice talk on it recently. [0] [0] https://www.youtube.com/watch?v=y_QeST7Axrw https://www.youtube.com/watch?v=y_QeST7Axrw
  - monocasa 1y ago
    The JVM optionally does it. It does not rely on it.
- sparkie 1y ago
  You don't need the hardware UAI/LAM to make use of the high pointer bits. The most common technique is to use `shl reg, 16; sar reg, 16`, which will shift in ones or zeros from the left depending on the 47th bit. Several runtimes use high bits tagging combined with NaN-boxing, and have been doing so since before LAM/UAI existed.
wbl 1y ago
Dynamic types have classically used the lower bits freed by alignment constraints. If I know a cons cell is 16 bytes then I can use the low 4 bits of an address to store enough type info to disambiguate.
- monocasa 1y ago
  Depends on the architecture. Top bit usage lets you do what the hardware thinks if as an 'is negative' check for very cheap on a lot of archs for instance.
- themafia 1y ago
  Is it a guarantee that a 16 byte object would be 16 byte aligned?
  - ComputerGuru 1y ago
    No. It depends on the object.
  - vidarh 1y ago
    Not in general, but it is a guarantee a runtime where all allocation are 16 byte cons cells can choose to make quite trivially.
  - bluGill 1y ago
    If you implement malloc you can do that. The os generally gives you 4k (or other number in that range) at a time and malloc subdivides it. language runtimes can call malloc whatever they want.
  - secondcoming 1y ago
    In C++ you can force that with alignas(), I would imagine other low level languages offer something similar. If you're using a custom allocator you'd have to enfore it yourself which should be fine since you have full control. https://en.cppreference.com/w/cpp/language/alignas.html https://en.cppreference.com/w/cpp/language/alignas.html
IshKebab 1y ago
I highly doubt this is anything like CHERI. More likely it's their version of ARM MTE.
thayne 1y ago
Doesn't CHERI use additional bits to store the capabilities rather than masking existing bits in the pointer? But that can be problematic for any code that assumes that the size of pointers is the same as size_t/usize. I don't see how this could not be opt in for backwards compatibility though, since existing code wouldn't use the new instructions.
Tuna-Fish 1y ago
I would not assume they just use bits in the address word for the tag. LPDDR6 includes 16 bits of host-defined metadata per 256 bits of data. Systems can use that for ECC, and/or for other purposes, including things like tagging memory. DDR6 will likely include a similar mechanism. SECDED ECC requires 10 bits, leaving you 6 bits. That's enough for one bit per aligned address word, which is probably used to denote "valid pointer" like CHERI.

monocasa 1y ago

Not a whole lot of language runtimes (if any) really depend on upper address ignore. AFAIK, AMD only added it in Zen4.

fooker 1y ago
Lua does
- pansa2 1y ago
  I thought one of Lua’s selling points is that it’s written in highly standard-compliant C code. I wouldn’t expect it to do anything non-portable like bitwise manipulation of pointers?
  - sparkie 1y ago
    It's fine to use techniques like this in standard C provided you guard them with the preprocessor and provide a fallback option on unsupported hardware.
    - wahern 1y ago
      PUC Lua doesn't use these tricks; every value in the VM is represented with a POD struct with explicit tag and value members. The OP may have been thinking of LuaJIT, which uses NaN boxing, but not pointer tagging. PUC Lua does rely on two's complement integer representation, though, as well as long long, while nominally adhering to C90, so not quite strictly conforming.
erichocean 1y ago
The JVM does with the ZGC garbage collector, did a really nice talk on it recently. [0] [0] https://www.youtube.com/watch?v=y_QeST7Axrw https://www.youtube.com/watch?v=y_QeST7Axrw
- monocasa 1y ago
  The JVM optionally does it. It does not rely on it.
sparkie 1y ago
You don't need the hardware UAI/LAM to make use of the high pointer bits. The most common technique is to use `shl reg, 16; sar reg, 16`, which will shift in ones or zeros from the left depending on the 47th bit. Several runtimes use high bits tagging combined with NaN-boxing, and have been doing so since before LAM/UAI existed.

wbl 1y ago

Dynamic types have classically used the lower bits freed by alignment constraints. If I know a cons cell is 16 bytes then I can use the low 4 bits of an address to store enough type info to disambiguate.

monocasa 1y ago
Depends on the architecture. Top bit usage lets you do what the hardware thinks if as an 'is negative' check for very cheap on a lot of archs for instance.
themafia 1y ago
Is it a guarantee that a 16 byte object would be 16 byte aligned?
- ComputerGuru 1y ago
  No. It depends on the object.
- vidarh 1y ago
  Not in general, but it is a guarantee a runtime where all allocation are 16 byte cons cells can choose to make quite trivially.
- bluGill 1y ago
  If you implement malloc you can do that. The os generally gives you 4k (or other number in that range) at a time and malloc subdivides it. language runtimes can call malloc whatever they want.
- secondcoming 1y ago
  In C++ you can force that with alignas(), I would imagine other low level languages offer something similar. If you're using a custom allocator you'd have to enfore it yourself which should be fine since you have full control. https://en.cppreference.com/w/cpp/language/alignas.html https://en.cppreference.com/w/cpp/language/alignas.html

IshKebab 1y ago

I highly doubt this is anything like CHERI. More likely it's their version of ARM MTE.

thayne 1y ago

Doesn't CHERI use additional bits to store the capabilities rather than masking existing bits in the pointer? But that can be problematic for any code that assumes that the size of pointers is the same as size_t/usize. I don't see how this could not be opt in for backwards compatibility though, since existing code wouldn't use the new instructions.

Tuna-Fish 1y ago

I would not assume they just use bits in the address word for the tag. LPDDR6 includes 16 bits of host-defined metadata per 256 bits of data. Systems can use that for ECC, and/or for other purposes, including things like tagging memory. DDR6 will likely include a similar mechanism. SECDED ECC requires 10 bits, leaving you 6 bits. That's enough for one bit per aligned address word, which is probably used to denote "valid pointer" like CHERI.