5 ms·

I think the interesting thing about having protection in software is you can do things differently, and possibly better. Computers of yesteryear had protection

by rwmj 8mo ago

I think the interesting thing about having protection in software is you can do things differently, and possibly better. Computers of yesteryear had protection at the individual object level (eg https://en.wikipedia.org/wiki/Burroughs_Large_Systems https://en.wikipedia.org/wiki/Burroughs_Large_Systems). This was too expensive to do in 1970s hardware and so performance sucked. Maybe it could be done in software better with more modern optimizing compilers and perhaps a few bits of hardware acceleration here and there? There's definitely an interesting research project to be done.

mananaysiempre 8mo ago
Sadly, even software-filled TLBs look to be a thing of the past. Apparently a hardware page-table walker is just that much faster? I’m not sure.
- rep_lodsb 8mo ago
  Why is that surprising? The trap into kernel mode alone would already take more cycles than dedicated hardware needs for the full page table walk.
  - rwmj 8mo ago
    Since we're talking about defining our own processor, that means we need to define one with cheaper traps. Expanding on what I wrote above about "bits of hardware acceleration", maybe adding a few primitives to the instruction set that make page table walking easier would help. And with a trusted compiler architecture you don't need to keep the ISA stable between iterations, since it's assumed that all code gets compiled at the last minute for the current ISA. Lots of fun things to experiment with.
    - saltcured 8mo ago
      Taking this to an extreme, the whole idea of a TLB sounds like hardware protection too? As a thought experiment, imagine an extremely simple ISA and memory interface where you would do address translation or even cache management in software if you needed it... the different cache tiers could just be different NUMA zones that you manage yourself. You might end up with something that looks more like a GPU or super-ultra-hyper-threading to get throughput masking the latency of software-defined memory addressing and caching?

by rwmj 8mo ago

mananaysiempre 8mo ago

Sadly, even software-filled TLBs look to be a thing of the past. Apparently a hardware page-table walker is just that much faster? I’m not sure.

rep_lodsb 8mo ago
Why is that surprising? The trap into kernel mode alone would already take more cycles than dedicated hardware needs for the full page table walk.
- rwmj 8mo ago
  Since we're talking about defining our own processor, that means we need to define one with cheaper traps. Expanding on what I wrote above about "bits of hardware acceleration", maybe adding a few primitives to the instruction set that make page table walking easier would help. And with a trusted compiler architecture you don't need to keep the ISA stable between iterations, since it's assumed that all code gets compiled at the last minute for the current ISA. Lots of fun things to experiment with.
  - saltcured 8mo ago
    Taking this to an extreme, the whole idea of a TLB sounds like hardware protection too? As a thought experiment, imagine an extremely simple ISA and memory interface where you would do address translation or even cache management in software if you needed it... the different cache tiers could just be different NUMA zones that you manage yourself. You might end up with something that looks more like a GPU or super-ultra-hyper-threading to get throughput masking the latency of software-defined memory addressing and caching?