News for hackers. Stuff that matters.
Re:Allocgate: Restructuring how allocators work in Zig by Spex_guy on Wednesday December 15, 2021 @07:28PM (#29573354)
It's true that language specific IRs are more powerful, but that isn't the problem in this example. Interfaces aren't part of Zig at the language level, nor are object lifetimes over which to make the vtables immutable. Having a memory model where memory is not innately typed is what makes this problem difficult to optimize, the IR has very little to do with it.
Re:Allocgate: Restructuring how allocators work in Zig by dnautics on Wednesday December 15, 2021 @08:36PM (#29573814)
> a memory model where memory is not innately typed

This is intriguing. Do you have examples of systems where memory is typed? Or some ideas?

Re:Allocgate: Restructuring how allocators work in Zig by Spex_guy on Wednesday December 15, 2021 @09:18PM (#29574071)
Memory is typed in C++. You must use placement new to imbue memory with a non-POD type, and that memory continues to have that type until its destructor is invoked. This is what allows the optimizer to assume that vtable pointers don't change while an object is alive.

Effects of the typedness of memory can also be seen in the strict aliasing rules. Once a piece of memory has taken on a type, it may no longer be aliased by pointers of different types, until the memory is relinquished back into typelessness by a destructor.

Re:Allocgate: Restructuring how allocators work in Zig by dnautics on Wednesday December 15, 2021 @11:08PM (#29574705)
thanks!
Re:Allocgate: Restructuring how allocators work in Zig by brandmeyer on Wednesday December 15, 2021 @09:16PM (#29574066)
BitC used a strictly typed memory model.