4 ms·

Regardless, you would lose the automatic guarantee that the same bit is zero for pointers, which is the whole motivation for doing this (more efficient GC). Po

Regardless, you would lose the automatic guarantee that the same bit is zero for pointers, which is the whole motivation for doing this (more efficient GC). Pointers are guaranteed to have LSB of zero because of data is typically aligned to the machine word size rather than individual bytes. In this case, that is enforced (or at worst everything must be 16-bit aligned). It's a pretty clever idea really.

glandium 12y ago
> Pointers are guaranteed to have LSB of zero Except pointers to functions in ARM thumb. Or more simply pointers inside strings.
- koenigdavidmj 12y ago
  The way that this is overcome is that most garbage collectors only permit direct pointers to an object rather than to a particular field inside an object. For example, there's no Java equivalent to this C: void a(int *b) { *b = 5; } struct c { int d; }; int main() { struct c foo; a(&foo.d); // no way to do this in Java! printf("%lu\n", (unsigned long)foo.d); }
- robert_tweed 12y ago
  As has been pointed out, you can disallow direct pointers into the middle of things and use offsets instead. I'm curious though, because I don't know much about ARM, why function pointers can't be forced into even alignment? If it's 3rd party binary code you might have a problem, but if you control the compilation you can add NOP padding to get whatever alignment you want. There's nothing that requires any particular alignment on x86/x64 either, but it's standard for most compilers because it makes everything run faster at minimal size cost.
  - belovedeagle 12y ago
    > why function pointers can't be forced into even alignment The actual instructions are aligned on an even byte boundary; however, on AArch32, encoding interoperability is achieved with BLX or BX, which uses the low bit as a tag value: 0=A32, 1=T16/32. However, in a lisp interpreter, e.g., you should never find a function pointer in an "object" context; i.e., something which could be an integer instead.
  - ufo 12y ago
    Last time I checked the generated executables, Ocaml did include the extra NOPs for padding.

glandium 12y ago

> Pointers are guaranteed to have LSB of zero Except pointers to functions in ARM thumb. Or more simply pointers inside strings.

koenigdavidmj 12y ago
The way that this is overcome is that most garbage collectors only permit direct pointers to an object rather than to a particular field inside an object. For example, there's no Java equivalent to this C: void a(int *b) { *b = 5; } struct c { int d; }; int main() { struct c foo; a(&foo.d); // no way to do this in Java! printf("%lu\n", (unsigned long)foo.d); }
robert_tweed 12y ago
As has been pointed out, you can disallow direct pointers into the middle of things and use offsets instead. I'm curious though, because I don't know much about ARM, why function pointers can't be forced into even alignment? If it's 3rd party binary code you might have a problem, but if you control the compilation you can add NOP padding to get whatever alignment you want. There's nothing that requires any particular alignment on x86/x64 either, but it's standard for most compilers because it makes everything run faster at minimal size cost.
- belovedeagle 12y ago
  > why function pointers can't be forced into even alignment The actual instructions are aligned on an even byte boundary; however, on AArch32, encoding interoperability is achieved with BLX or BX, which uses the low bit as a tag value: 0=A32, 1=T16/32. However, in a lisp interpreter, e.g., you should never find a function pointer in an "object" context; i.e., something which could be an integer instead.
- ufo 12y ago
  Last time I checked the generated executables, Ocaml did include the extra NOPs for padding.