OT: down with memory protection!
I have this somewhat crazy idea about systems design which is highly off topic
here but maybe someone would be interested. (I'm not subscribed to any more
appropriate groups at the moment.) If this is _too_ OT please let me know.
I want to be able to write programs with lots and lots of coroutines or
"sub-processes", which means a lot of context switching - but context switching
is expensive, such programs would go slow!
Current mainstream OSes like Linux implement memory protection primarily to
prevent buggy or malicious processes trampling on each-others memory and
memory-mapped devices, or spying on other processes. The system must do this
because we have no way to be sure that buggy or malicious C programs will not
peek or poke where they should not. In contrast, programs written in python,
Perl or Java cannot peek or poke at other processes (unless there is something
wrong with the language implementation).
It should be possible to create a C-like language, with unconstrained memory
access, but an additional requirement that the intended range and access type
of each pointer must be declared or implied in the code. The compiler could
then attempt to _prove_ to itself that the code did not access memory it should
not. I expect in many cases a good proof engine would be able to do this.
Otherwise, the compiler could require the programmer to provide a formal proof
that the program's memory access is bounded. If the program is well
structured, this should not be too difficult. If the programmer can't be sure
that the program is well behaved, I would suggest that program should not be
used anyway!
Anyway, if we assume this is possible, and if all compiled-to-machine-code
programs were written in such a way, and if the final stage of compilation were
done by a trusted party (preferably on the local machine), perhaps we wouldn't
need to implement memory protection in the VM.
All processes could run on a single address space, there would be no need for
context-switching, pipes could be implemented as shared buffers, and processes
could send messages to eachother without needing to copy memory. There would
be no need for a kernel/userland distinction. It would be unnecessary to copy
things around so much when doing IO.
I think people don't normally use more than 4GB of VM on 32-bit computers, at
least they won't now that 64 bit CPUs are taking off, so this single address
space model would be ok for 32 bit as well as 64 bit.
The need for preemptive multiprocessing could be reduced or eliminated in a
similar way. Programs could call "yield" every now and again, and the compiler
and programmer could be required to prove that the code would not loop forever
without calling yield. An interrupt-driven alarm could be used as a last
resort to suspend an offending process after an unacceptable amount of CPU
hogging. Without the kernel/userland distinction, yield and other "syscalls"
could be implemented cheaply.
On multi-CPU machines, the scheduler could make sure that shared memory was
written safely (when no other CPU can be accessing that memory). This would
work best if programs were written in a highly threaded / many coroutines
style, with dedicated sub-processes for IO. It would be efficient to have
small-scale process modularity in a system which did not need context
switching.
Regarding "the stack", I would like to see the demise of the stack altogether!
Files could be accessed by partially mapping them to memory. The common case
of reading a file a-buffer-at-a-time would translate to a moving window mapped
onto the file. File locking would therefore usually be automatic and implicit.
I used to use "RISC OS" on Acorn computers in "the good old days", it used
non-preemptive multitasking. RISC OS has a lot going for it.
Anyway, if anyone would comment on any of this vapourware, I'd like to hear it
- off the list if you think it's too off topic.
It's not completely dreamware, I am developing a progamming language called
nipl (at the moment it's basically C, but with a python-like syntax, it is
evolving from C and translates to C), I will have a go at implementing
"compile-time memory protection" in it. It is definitely going to have
coroutines!
thanks
Sam
Reply to: