3 ms·

"Fatter than normal" pointers have a lot of disadvantages (it's been explored extensively as part of CHERI, etc) for the upsides they give you. For the purpose

"Fatter than normal" pointers have a lot of disadvantages (it's been explored extensively as part of CHERI, etc) for the upsides they give you. For the purpose of use after free/buffer overflow finding, it's IMHO, not a great fit (there are other uses, of course). "Tagging within existing sized pointers", ARM does have some hardware support for (see http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/ch12s05s01.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....) It won't verify tags, but it has explicit support for ignoring bits, which is very helpful.

binarycrusader 9y ago
If by "fatter than normal" you mean using bits of the memory address to do interesting things, SPARC does so with ADI in hardware: https://lazytyped.blogspot.it/2018/02/libcmalloc-meets-adiheap.html https://lazytyped.blogspot.it/2018/02/libcmalloc-meets-adihe...
- DannyBee 9y ago
  No, by fatter than normal I mean, say, 96 or 128 bit pointers. I'm aware of SPARC ADI :) It does not have fatter-than-normal pointers, it uses 4 bit tagging of the memory address by reusing bits 63-60 of the pointer. That is "tagging within existing pointers"
  - binarycrusader 9y ago
    As I said it depends on what you mean by “fatter than normal”.
nostrademons 9y ago
Gwydion Dylan used a two-word representation for values - a full word as a type tag, and then a word for the value itself (whether pointer or int). It was an interesting experiment, but multicore basically killed it. Once your basic value representation is more than a word, then every load/store/manipulation of a value requires a lock around it, to prevent corruption if the thread is preempted when the type has been written but the value has not. The locking overhead kills performance. Or you can go with a GIL (but for compiled code) the way Python and early Ruby/JS implementations did, but that hasn't worked out terribly well for them either.

binarycrusader 9y ago

If by "fatter than normal" you mean using bits of the memory address to do interesting things, SPARC does so with ADI in hardware: https://lazytyped.blogspot.it/2018/02/libcmalloc-meets-adiheap.html https://lazytyped.blogspot.it/2018/02/libcmalloc-meets-adihe...

DannyBee 9y ago
No, by fatter than normal I mean, say, 96 or 128 bit pointers. I'm aware of SPARC ADI :) It does not have fatter-than-normal pointers, it uses 4 bit tagging of the memory address by reusing bits 63-60 of the pointer. That is "tagging within existing pointers"
- binarycrusader 9y ago
  As I said it depends on what you mean by “fatter than normal”.

nostrademons 9y ago

Gwydion Dylan used a two-word representation for values - a full word as a type tag, and then a word for the value itself (whether pointer or int). It was an interesting experiment, but multicore basically killed it. Once your basic value representation is more than a word, then every load/store/manipulation of a value requires a lock around it, to prevent corruption if the thread is preempted when the type has been written but the value has not. The locking overhead kills performance. Or you can go with a GIL (but for compiled code) the way Python and early Ruby/JS implementations did, but that hasn't worked out terribly well for them either.