[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[f-cpu] Re: Rep:Re: virtually or physically-addressed cache ?
On Sun, Mar 03, 2002 at 10:45:44PM +0100, Marco Al wrote:
> From: "Andreas Bombe"
>
> > It would mean that all executables (not only shared libraries) would
> > have to be position independent code.
>
> Small loss, but if its really a problem segments provide an alternative
> solution.
Segments? Oh, ye gods, no...
> > Besides, how are you going to implement a Unix fork(), then?
>
> The Mungi people solved that if my memory serves me (look it up yourself :).
> I think they added an extra layer of indirection during compilation,
What I found is that Mungi is an OS using a single flat address space
over all processes. They likely simply don't have a fork() equivalent.
So it's an OS that uses a subset of the CPU's capabilities.
What you propose is making a CPU that provides a subset of the OS's
requirements.
> slightly messy but you only have to use it for programs which actually use
> fork
Which is any program that is not a leaf in the process tree. Starting
an executable is in fact a fork()+exec().
That said, it is possible to implement a Unix on a system where there is
only a flat address space (systems without a MMU). Minix did this by
copying data in shared addresses to backup buffers on context switch
IIRC. uCLinux simply doesn't have that, but it's also not compatible
with standard Unix applications.
--
Andreas Bombe <bombe@informatik.tu-muenchen.de> DSA key 0x04880A44
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/