Virtual memory and memory protection

vipin.sachdeva@gmail.com <vipin.sachdeva@gmail.com> wrote:

> I think the Blue Gene is also only physical memory, but more due to
> performance reasons (don't swap to disk and take too long) than
> anything else.

The PPC440 core in Blue Gene has virtual memory. What it doesn't have is
cache coherence.

-- 
Mvh./Regards,    Niels J&#4294967295;rgen Kruse,    Vanl&#4294967295;se, Denmark

On 19 Aug 2005 22:59:09 -0700, "drizzle" <drizzle76@gmail.com> wrote:

>Hi,
>    Any examples of embedded systems with memory protection hardware
>but no virtual memory ? 

The 8086 had a very primitive "memory protection" system, since the
memory could only be accessed directly through 4 segment registers
(CS, DS, SS and ES), thus only up to 256 KiB could be corrupted of the
total 1 MiB address space at any time, which gave some kind of
protection for runaway programs. Of course, you still could
deliberately load the segment registers.

IIRC, the 80286 in protected mode limited what the user could do with
the segment registers but did not yet support virtual memory. 

In practice, any processor using the segmentation model would use
memory protection without virtual memory.

For instance the PDP-11 mapped the 64 KiB program address space to the
256 KiB or 4 MiB physical memory using 8 (or 16 for I/D space) memory
base and segment size registers that were not normally visible to the
user. Any reference outside the mapped address range (or a write
access to read-only segment) would be trapped. 

In order to avoid the discussion is PDP-11 an embedded processor :-),
these features were available on the K-11 chip set as well as on the
J-11 chip.
 
>Or the other way ?

If someone implements the virtual memory features (including page
tables and instruction suspension and/or restart), it would be foolish
not to implement the memory protection.

Paul

Paul Keinanen wrote:
> On 19 Aug 2005 22:59:09 -0700, "drizzle" <drizzle76@gmail.com> wrote:
> 
> 
>>Hi,
>>   Any examples of embedded systems with memory protection hardware
>>but no virtual memory ? 
> 
> 
> The 8086 had a very primitive "memory protection" system, since the
> memory could only be accessed directly through 4 segment registers
> (CS, DS, SS and ES), thus only up to 256 KiB could be corrupted of the
> total 1 MiB address space at any time, which gave some kind of
> protection for runaway programs. Of course, you still could
> deliberately load the segment registers.
> 
> IIRC, the 80286 in protected mode limited what the user could do with
> the segment registers but did not yet support virtual memory. 
> 

The 80286 System Programmers Reference showed a way to
provide virtual memory using the segmentation mechanism,
but AFAIK nobody has implemented it as such. The segment-
based virtual memory makes it pretty difficult to avoid
memory fragmentation (both real and virtual memory).

-- 

Tauno Voipio
tauno voipio (at) iki fi

On Sat, 20 Aug 2005 12:09:00 GMT, Tauno Voipio
<tauno.voipio@iki.fi.NOSPAM.invalid> wrote:

>Paul Keinanen wrote:

>> IIRC, the 80286 in protected mode limited what the user could do with
>> the segment registers but did not yet support virtual memory. 
>> 
>
>The 80286 System Programmers Reference showed a way to
>provide virtual memory using the segmentation mechanism,
>but AFAIK nobody has implemented it as such. 

Any hardware, that is capable of detecting non-existent memory
references or unsupported op-codes by trapping can be used to
implement some kind of virtual memory. The unsupported op-code
trapping can be used to emulate non-existent instructions (such as
floating point) and the non-existent address to load the missing
page/segment. 

However, when emulating missing op-codes or addresses, it is essential
to be able to continue from the middle of instruction at the point it
was interrupted on undo any modifications (such as pointer
autoincrements) done by the first part of the instruction. If there is
no hardware support for this, quite a lot of software will be
required, before the instruction can be completed.

One other very desirable feature of a virtual memory processor is the
hardware implementation of the "dirty bit" and recently accessed page
concept or you end up in similar implementations as in WinNT (which in
those days supported multiple architectures), in which pages were
randomly moved to the output queue to be written to the page file.
Heavily used pages were often page faulted back from the output queue
back to the working set before it was written to the page file. Thus
frequently used pages remained in memory, while seldom used pages
reached the end of the queue and were written to the page file, thus
implementing some kind of the LRU (Least Recently Used) algorithm:-).

>The segment-
>based virtual memory makes it pretty difficult to avoid
>memory fragmentation (both real and virtual memory).

Is it any better for paged virtual memory systems (at least for the
virtual memory) ? Try to allocate 1MiB of contiguous virtual memory
from the WinNT e.g. for a memory mapped file ...

Paul

Paul Keinanen wrote:
> On Sat, 20 Aug 2005 12:09:00 GMT, Tauno Voipio
> <tauno.voipio@iki.fi.NOSPAM.invalid> wrote:
> 
>>The segment-
>>based virtual memory makes it pretty difficult to avoid
>>memory fragmentation (both real and virtual memory).
> 
> 
> Is it any better for paged virtual memory systems (at least for the
> virtual memory) ? Try to allocate 1MiB of contiguous virtual memory
> from the WinNT e.g. for a memory mapped file ...
> 

No - that was the reason a Windows-based monitoring system
run short of available (virtual) memory in 13 +/- 1 days
when run 24h/day.

The paged system solves the fragmentation problem at
the real memory level: a page fits any page frame.

However, the fragmentation problem stays there for
the logical addresses (virtual memory). For a system
with plenty of processes the remaining fragmentation
problem is only in the process itself - not system-
wide as the real memory fragmentation.

-- 

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio wrote:
> 
... snip ...
> 
> The 80286 System Programmers Reference showed a way to
> provide virtual memory using the segmentation mechanism,
> but AFAIK nobody has implemented it as such. The segment-
> based virtual memory makes it pretty difficult to avoid
> memory fragmentation (both real and virtual memory).

Why?  As long as the segment registers are not visible to the user,
and include limits, the OS can move contents about freely when a
segment allocation fails for lack of a large enough free space.  If
combined with virtual memory it only needs to save the moved
segment when it is dirty.  When combined with page tables things
become even easier.

The advantage of proper segments with limits, privileges etc. is
that it is much easier to detect erroneous addresses.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

On 19 Aug 2005 05:02:51 -0700, "ssubbarayan" <ssubba@gmail.com> wrote,
in part:

>I am not able to understand relation between Virtual memory and memory
>protection.Can some one throw some light on this?

It certainly does seem odd, at first sight.

After all, if a computer has hardware bounds registers, or hardware
identifiers (the "memory key" of the 360), associated with memory, these
things would not apply to the data from memory stored on a disk.

But on the other hand, if a computer had _no_ hardware to assist in
protecting memory, the operating system could *swap out all memory
associated with other processes* while one program is running. Assuming
access to disk files can also be controlled and limited, this _would_
protect memory.

John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account

In comp.arch ssubbarayan <ssubba@gmail.com> wrote:
> I am not able to understand relation between Virtual memory and memory
> protection.Can some one throw some light on this?

There was memory protection before there was virtual memory.  When virtual
memory started showing up, one big problem I remember was correctly
faulting, then restarting instructions which included a memory reference
to something which wasn't (currently) present.  Early instances of this
were auto-growing the PDP-11 stack (V7 UNIX)--I remember processor model
specific code to handle various tricky instructions.

Andy Valencia

drizzle wrote:
> Hi,
>     Any examples of embedded systems with memory protection hardware
> but no virtual memory ? Or the other way ?

Analog Devices Blackfin DSP has memory protection hardware, but no
vitual memory.

Darrell Harmon
http://dlharmon.com/dspcard

"virtual memory limited to physical memory". See the following
presentation by IBM research guy.

www.lofar.org/BlueGene/Bhanot_Day01.pdf