4 ms·

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? Wh

by sebcat 10y ago

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?

lmm 10y ago
That wouldn't help. GCC would just compile code that turns off those features, since that would help it do better on benchmarks.
- sebcat 10y ago
  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.
  - ThisIs_MyName 10y ago
    http://yosefk.com/blog/the-high-level-cpu-challenge.html http://yosefk.com/blog/the-high-level-cpu-challenge.html
- Sanddancer 10y ago
  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.
ThisIs_MyName 10y ago
> 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.
spc476 10y ago
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.

by sebcat 10y ago

lmm 10y ago

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

sebcat 10y ago
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.
- ThisIs_MyName 10y ago
  http://yosefk.com/blog/the-high-level-cpu-challenge.html http://yosefk.com/blog/the-high-level-cpu-challenge.html
Sanddancer 10y ago
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.

ThisIs_MyName 10y ago

> 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.

spc476 10y ago

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.