OK. Maybe I just don't understand game development very well, but I don't get why some of the problems they had in the post-MMU era even existed. 1) Memory Fra

OK. Maybe I just don't understand game development very well, but I don't get why some of the problems they had in the post-MMU era even existed. 1) Memory Fragmentation - why? This seems like it would only be a problem if they ran their entire game in the same virtual address space. 2) Subsystem A corrupting Subsystem B's RAM - once again, wouldn't one run the sim code in one address space, the rendering in another, etc. and have strategically shared pages for them to transfer data back and forth? It really seems to me like the idea is 'yeah, we had virtual memory, and it was great, but we didn't really use it'... Granted, they put guard pages on some allocations, but that's akin to using supercomputer to solve your family budget. Lots of power available, but using it in a trivial way. I acknowledge that there's some cost to a context switch, and that the 2005 generation used PowerPC with its fairly cache-inefficient hashed pagetable (poor locality), but the benefits of having a hard wall in memory between major system functions is immeasurable (I'm guessing that on PPC, they just set up a few Block Address Translation registers and called it 'good enough'). Then again, I come from a safety critical background .. we make aerospace code, so it's developed using the methods described in the article about 'the right stuff' that was up a day or two ago. We're really fond of having really hard walls between every resource we can (memory, CPU time, I/O bandwidth, FS bandwidth ... you name it) for major system functions. I realize that in game programming most of those walls aren't practical (due to performance impact) or necessary, but the memory one is fairly cheap and incredibly helpful. PS - if you're wondering, we prevent memory leak problems by just disabling dynamic allocation post-boot, which happens on the ground. Our stack utilization is also required to be statically analyzable, which means that you can't do things like recursion. These limitations make the design of some algorithms extremely painful, but what other software have you ever heard of that can truthfully claim 0 memory leaks, guaranteed. We also do 100% code coverage (at the machine language level), 100% decision coverage, static and dynamic worst-case timing analysis, etc. etc. etc. Look up 'DO-178B' or 'DO-178C' if you're curious about what's done and why safety critical stuff is insanely expensive. More recently we're throwing in fuzzing for good measure, but fuzzing doesn't turn up a whole lot in extremely thoroughly tested code that's been reviewed line-by-line by dozens of engineers (and is subject to strict design limitations).