OSDev.org

I think there is thread previously about this but I don't want bump it.

Most of us here are developing on kernels that use MMU but since the trend towards managed code continues this will eventually sneak down to system code. I wonder how redundant creating kernels in C/C++ is right now. As I see it, the fundamental change is the protection granularity, you go from protection on process level to protection to object level. There is very little HW support for object protection so it must be handled by SW. Despite the performance hit of run-time checks you automatically get other advantages.

There is ~1.3 as many memory references with MMU on.
HW page table walkers are quite expensive silicon wise, if we just could avoid them the cpu will become simpler.
Programming productivity increases

We Singularity which is an R&D experiment but there are a few Java based OSes out there that has found its way into some commercial embedded systems. I wonder if there is anybody here have any experience with these OSes when it comes to performance, porting and development speed.

So I ask you, are most of us tinkering with already redundant technology? Will the MMU, be just like the hardware task switcher found in several CPUs that usually end up being unused?

It's never going to become redundant, simply because Windows uses process-level protection. If Windows exists, it will use a hardware MMU. If Windows doesn't exist, there's no reason for Intel-based PCs to be the norm any more, and that's an even bigger game changer.

Now, to actually answer your question. I think the future is in object-oriented hardware designs, especially with regards to hardware protection and a huge number of processing cores. However, we're not going to jump ship until the performance is just as good, if not better. So it's going to take a while. An hobbyists are always behind the game, because documentation for the latest and greatest is usually fairly sparse (although CPU documentation is quite good really).

Just my $0.02.

Windows is Windows with its x86 legacy and all that backwards compatibility. I meant new systems, usually meaning not Windows and not x86.

For hobbyists I see that tool chains is usually behind the game. C/C++ is quite mature and ported to a wide range of targets. Managed code languages, I'm bit lost especially if you want it to be compiled to a specific HW.

My prediction is that MMUs will be around for a while but that CPUs will gradually provide managed ISAs (thus also eliminating the need for AOT compilers/interpreters running underneath the kernel---if anyone wants JIT, they can do it on top of the native ISA). As for the Windows argument, they are already preparing for this as everything is shifting towards .NET.

I don't think the MMU will become redundant in any foreseeable time frame.

CPU manufacturers - even Intel - don't produce for a specific operating system. Even if, say, Windows should switch to some kind of virtualized / managed protection approach (which I don't see coming, seeing how much of their system is still plain old C/C++) - Linux is C, and will remain so for quite some time. They adamantly refused opening up the kernel land for C++, so I don't see them warming to the idea of running everything as managed code.

Bottom line, when asking "will the MMU become redundant?", we're looking at a time frame of post-Windows, post-Linux (post MacOS). Or at least post-some-major-rewriting of all of these systems.

I'd be willing to bet money on MMU's still being standard issue in twenty years. Which, if you think about it, is quite a time frame to make any forecasts in the IT industry.

With current hardware and interpreter technology at least, developing a decent managed code OS would mean a lot of extra effort, and still get relatively bad performance compared to its native code counterparts. The programming productivity benefit is also far from obvious : without their standard libraries, managed languages aren't very different from their unmanaged counterparts, and if you're ready to spend your time and effort implementing something equating .Net in complexity, you certainly also can create a very powerful and productive C++ framework.

I'd also like to point out that software-based isolation is significantly less secure than hardware-based one, as simple bugs are all it takes to break it whereas with hardware isolation you also can limit what buggy software can do. There's a reason why Java is one of the most exploited software in existence.

So well... Maybe managed languages are to revolutionize computing in a few decades. But here and now, I feel that C/C++ with MMU isolation is still the way to go.

Solar wrote:I don't think the MMU will become redundant in any foreseeable time frame.

As I've said, this certainly won't happen overnight and MMUs will still be around for quite a while, although I'm not sure 15--20 years, as berkus predicts. No one will care about running even a 10 year-old version of PhotoShop. In 15--20 years, we might all be using quantum computers; if that's the case, MMUs won't be the only thing to go considering that backwards compatibility won't be an issue.

Solar wrote:CPU manufacturers - even Intel - don't produce for a specific operating system. Even if, say, Windows should switch to some kind of virtualized / managed protection approach (which I don't see coming, seeing how much of their system is still plain old C/C++) - Linux is C, and will remain so for quite some time. They adamantly refused opening up the kernel land for C++, so I don't see them warming to the idea of running everything as managed code.

They don't produce CPUs for a specific OS but they certainly do produce them for the more popular ones. I admit that the Linux community is further away from switching to managed systems than the Windows community is but 15 years is a long time. We shall see, no one knows for certain.

Solar wrote:Bottom line, when asking "will the MMU become redundant?", we're looking at a time frame of post-Windows, post-Linux (post MacOS). Or at least post-some-major-rewriting of all of these systems.

Indeed. Then again, let's not forget that there are many compoments that these systems have already deprecated. Who's to say that 15--20 years isn't enough time for a gradual shift towards managed systems?

Solar wrote:I'd be willing to bet money on MMU's still being standard issue in twenty years. Which, if you think about it, is quite a time frame to make any forecasts in the IT industry.

I think it would be fun to revisit this post in 20 years (provided there is still at least some backup of it) and see how everyone here was probably dead wrong about everything This reminds me of how many others attempted and failed to make good predictions, including Tanenbaum (see the Tanenbaum–Torvalds), and Knuth (see the MIX architecture, now replaced by MMIX).

Love4Boobies wrote:I think it would be fun to revisit this post in 20 years (provided there is still at least some backup of it) and see how everyone here was probably dead wrong about everything

I've been quite good at this game in the last 20 years.

I remember when I quite recently re-visited an Amiga website, where they still argue that PowerPC is the better architecture etc. etc. yadda yadda. I dropped something in the "I told you so" ballpark, and someone flamed me like, "yeah, as if you could foresee that PPC wouldn't be the way to go".

At which point another old-time user replied, "actually... he did, in 2001." Including link to my post from back then.

Let's see if someone will link to this thread in ten years' time.

Solar wrote:I remember when I quite recently re-visited an Amiga website, where they still argue that PowerPC is the better architecture etc. etc. yadda yadda. I dropped something in the "I told you so" ballpark, and someone flamed me like, "yeah, as if you could foresee that PPC wouldn't be the way to go".

At which point another old-time user replied, "actually... he did, in 2001." Including link to my post from back then.

Let's see if someone will link to this thread in ten years' time.

PPC was more or less dead as a "general-purpose" CPU back in 2001. This one is going to be more fun

Love4Boobies wrote:PPC was more or less dead as a "general-purpose" CPU back in 2001.

You should've seen the flames I got back then.

To be honest, it wasn't that much about the future of the PPC per se, but about the roadmap / strategy of AmigaOS that I criticised.

I'd better throw my thoughts into the ring, though you probably know them already. No one's going to be interested in protection mechanisms of any kind ten years from now. The Turing Test will be passed within twelve months. Am I going to look silly, I wonder...

If anything is going to change, it will almost definitely be in a way that improves multiprocessor performance. I don't see paging limiting that in a fundamental way, although if cores are to become smaller and more numerous, the cost of having an MMU on each core will increase proportionally. Perhaps this will be solved with a decoupling of MMU and CPU, such that multiple cores may be assigned to a single MMU state, because heavy threading within a single process is becoming the norm for applications.

Not supporting non-managed languages does not increase programmer productivity, retraining and rewriting multimillion line programs is a job no company will want to do. For instace many businesses still have lots of COBOL code in programs that are used every day. Changing it would be a cost to productivity as well as monetary.

garob wrote:Not supporting non-managed languages does not increase programmer productivity, retraining and rewriting multimillion line programs is a job no company will want to do. For instace many businesses still have lots of COBOL code in programs that are used every day. Changing it would be a cost to productivity as well as monetary.

Sure, but there's a difference between supporting managed languages in user mode applications and using them at the core of the system.

In user mode, all you have to do is to port the usual toolkit associated to that language (Mono, JRE...), which should be pretty straightforward. But writing an OS in managed code is several order of magnitudes more complicated, you have a whole lot of things to implement yourself and there isn't lots of legacy code as an incentive at lower levels.

Solar wrote:

Love4Boobies wrote:PPC was more or less dead as a "general-purpose" CPU back in 2001.

You should've seen the flames I got back then.

To be honest, it wasn't that much about the future of the PPC per se, but about the roadmap / strategy of AmigaOS that I criticised.

Thanks for the fun read I learned bits of the Amiga history, I'm too young to be an Amigian (22 in 3 months).

DavidCooper wrote:I'd better throw my thoughts into the ring, though you probably know them already. No one's going to be interested in protection mechanisms of any kind ten years from now. The Turing Test will be passed within twelve months. Am I going to look silly, I wonder...

We're not much closer to this goal than we were 15 years ago. Current predictions are for something like 2030 and they keep adding to that every few years.

NickJohnson wrote:If anything is going to change, it will almost definitely be in a way that improves multiprocessor performance. I don't see paging limiting that in a fundamental way, although if cores are to become smaller and more numerous, the cost of having an MMU on each core will increase proportionally. Perhaps this will be solved with a decoupling of MMU and CPU, such that multiple cores may be assigned to a single MMU state, because heavy threading within a single process is becoming the norm for applications.

Sounds like a bottleneck to me and something that would only make sense with SMP, which we're already running away from in favour of NUMA.

garob wrote:Not supporting non-managed languages does not increase programmer productivity, retraining and rewriting multimillion line programs is a job no company will want to do. For instace many businesses still have lots of COBOL code in programs that are used every day. Changing it would be a cost to productivity as well as monetary.

You don't need to rewrite anything, you can have several types of CPUs around until the transition phase is over (that's how it always works). Also, have you not noticed the big interest in virtualization?