From: Eugene.Leitl@lrz.uni-muenchen.de
Date: Thu Jan 04 2001 - 13:14:05 PST
Tony Finch wrote:
> Then you don't have enough memory, and you don't have enough
> flexibility in your choice of system configuration.
No, the total amount of memory is not limited. Only the amount
of fast/cheap memory in a single node (die) is limited, due
to fabbing yield reasons.
> >Retain only enough of the MMU to protect the OS and only the OS.
>
> Not good enough. You have to protect applications from each other.
But you have asynchronous objects living in different nodes, ideally
one object in a node. They can't hurt each other, since only
allowed to shoot messages at their ilk. And they can't hurt the OS.
> >[...] Since objects residing in different nodes talk by hardware
> >message passing only, their individual address spaces are mutually
> >protected. [...]
>
> Oh, and throw away all the software that you use that has been
> developed over the last 20 years and start from scratch again.
Yes. Because it's all crap.
I realize it's the chiefest reason why it doesn't gets done, but
the longer you wait, the more painful it gets. And there will be
much wailing, renting of garments, and gnashing of teeth.
> Note that my previous message assumed that the first level cache is
> virtually addressed, which is usually the case so that MMU lookups
> don't slow down cache accesses. If the cache is physically addressed
All I know is gate delays do add up. Because you use the same machinery
to access on-die SRAM and on-die DRAM, you should minimize the number
of gates the signal has to traverse.
> then you can't access it quite as quickly, but context switches are
> much less expensive.
I've been reading up on QNX a few hours this afternoon. They claim
0.55 us best case (yeah, right) on high end Pentium III stuff and
RTLinux claims 15 us worst case on dated iron. Apples and oranges.
Apart from the fact that's it's close source (yuck) it looks rather
clean and small. I'm getting it, with the hope that one day we'll
get similiar nanokernels for Linux.
> I don't know enough about SMP to say how cache coherency and
> synchronization primitives (which often require a bus lock) affect the
> choice of cache design...
I think KISS applies once again here. FPU, MMU, BPU, pipelines, toss
them out. Eat up die space which you'll need for embedded stuff, add
signal latency, take designer brains, don't scale to high GHz clocks.
> Tony.
> --
> f.a.n.finch fanf@covalent.net dot@dotat.at
> "Perhaps on your way home you will pass someone in the dark,
> and you will never know it, for they will be from outer space."
--
______________________________________________________________________________
icbmto:N 48 10'07'' E 011 33'53'' http://www.lrz.de/~ui22204
ED 90 04 33 EB 74 E4 A9 53 7F CF F5 86 E7 62 9B 57 F9 CF D3
This archive was generated by hypermail 2b29 : Thu Jan 04 2001 - 13:21:24 PST