[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/