nanogui: MicroWindows, Java and desktop
Subject:
Re: MicroWindows, Java and desktop
From:
Alan Cox ####@####.####
Date:
3 Mar 2000 23:01:42 -0000
Message-Id: <E12R0vQ-0001SU-00@the-village.bc.nu>
> this way: with each memory access, the processor has to look up in a
> translation table to convert each logical address to a physical address. It's
> quite amazing that you can do it without burning up much of your memory
> bandwidth. Never mind the problems that virtual memory causes for designing
> cache systems.
Actually
1. You use lookaside buffers and because of locality you can hardly
measure the overhead
2. Caches are physically tagged and indexed nowdays. So no problem
> Also, operating systems pay a high price in the time it takes to tear down
> and put up memory protection walls while context switching. All that burns up
Its almost impossible to measure its so small
> CPU cycles, time, and ultimately battery power in small devices.
_battery power_ is a real one: See MMU's are gates and high speed logic,
no MMU - less gates.
> innovation of Java, however, is the way the JVM provides memory protection
> in ~software~ with very little cost: the verifier does a static safety check,
Not a java innovation and they havent solved the memory fragmentation problem
without big overhead (handles)
> There just aren't enough transistors on a smart card for hardware memory
> protection, and more conventional methods of software memory protection would
> have too great of a performance cost.
Older CPU's used to get memory protection into < 1000 gates.
> interesting vision, but we're already buying small devices with hardware
> memory protection and we're already running Linux on them, so it might never
> materialize.
I take issue with your reinvention of history 8). MMUless devices can be
smaller, lower power and avoid some overheads. That I agree.
Now to get back on topic: nanogui doesnt need an MMU. I'd like to think it
can stay that way
