Re: [f-cpu] Re: Rep:Re: virtually or physically-addressed cache ?

["Marco Al" <marco@simplex.nl>]

From: "Andreas Bombe" <bombe@informatik.tu-muenchen.de>


> 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.

Ok then ... yes first link from google for "mungi fork" shows they do in
fact have a fork equivalent.

I was wrong though, its not their method ... they borrowed it from a much
earlier SASOS angel (http://citeseer.nj.nec.com/wilkinson93compiling.html
which they cite, as can be seen on the 4th link on the search).

> 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.

Not exactly, it can support traditional virtual memory ... just slightly
less efficiently.

It supports everything necessary to efficiently support SASOS's, just as
long as you have a 64 bit address space (with less, fragmentation would be a
huge problem ... Ill readily admit defragmenting the virtual->physical
memory mapping, while possible if code was compiled to make all data
movable, is not something you really want to do). Everything thats necessary
turns out not to include a TLB.

Marco

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/