Hacker News Reader

Comment by sebcat | Hacker News Reader

Maybe the machine is at fault? Maybe the problem is not with C, but with a hardware architecture that does not offer finer granularity than page allocations? What if everything returned from malloc() would be bound checked by hardware? What if, instead of overwriting a malloc_chunk or the saved value of the instruction pointer, a hardware interrupt would be raised? Maybe the return stack and the parameter stack can be separate? Maybe someone solved these problems in hardware before the majority of us was born?

View on HN

The Intel 432 could do that (1982). Unfortunately, the Intel 432 was also slow and very complex (it's the only architecture I'm aware of that was object oriented at the microcode level).

The Intel 80286 could also do that (some of the features of the Intel 432 found their way into the 80286) but no one who lived through those days wants to return to those days (small, compact, medium, large and huge memory models anyone?).

The Intel 80386 (and really, any Intel CPU that can still execute 16-bit code) can do that. But then you are programming a glorified 80286 and well ... see above.

But okay, you want more details? You have segment registers, CS, DS, ES, SS (and the 80386 give you a few more) that define the base address and limit. To get byte granularity, you are limited to 65536 bytes and you are dealing with a very odd-ball 32-bit address (16-bit segment, 16-bit offset) or a 48-bit address (16-bit segment, 32-bit offset limited to 65,535). If you want more memory per segment, you lose the byte granularity (promoting sloppy coding, etc).

This is not an easy problem to solve.

> offer finer granularity than page allocations

How the fuck would that work? Today, the page table is cached in a TLB and modern Intel processors only have 1024 entries!

If you have a new entry in the page table for every malloc, dereferencing virtual memory will require a page walk for pretty much every memory access. You can't cache millions of entries.

That wouldn't help. GCC would just compile code that turns off those features, since that would help it do better on benchmarks.

Those "features" would be built into the platform. Instead of having the return stack and the parameter stack share memory space, the stacks would be kept separate by design. Instead of having malloc_chunks, the MMU would keep allocation metadata separate from the data presented to the user space. Any process overwriting an allocation would result in a segmentation fault, not on a per-page basis but on a per-allocation basis. It would be enforced by the architecture. It would not be optional. It would be by design.

http://yosefk.com/blog/the-high-level-cpu-challenge.html

To those downvoting lmm, look up C11 Annex K. There are standards for adding bounds checking and the like to C, but compiler makers don't implement them because they're "too slow." We need to demand more of our tooling makers.

Reply on news.ycombinator.com