delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/01/31/11:32:22

From: Thomas Demmer <demmer AT LSTM DOT Ruhr-UNI-Bochum DOT De>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Physical memory, virtual memory. DJGPP+CWSDPMI, how they work?
Date: Sat, 31 Jan 1998 17:16:59 +0100
Organization: Lehrstuhl fuer Stroemungsmechanik
Lines: 91
Message-ID: <34D34E7B.945CA9A7@LSTM.Ruhr-UNI-Bochum.De>
References: <3 DOT 0 DOT 1 DOT 32 DOT 19980130203727 DOT 006c24f8 AT adinet DOT com DOT uy>
NNTP-Posting-Host: bvb.lstm.ruhr-uni-bochum.de
Mime-Version: 1.0
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

lubaldo AT adinet DOT com DOT uy wrote:
> 
>         Hello everyone! I think this is on-topic... if it is not... sorry.
> 
>         I would like to know how physical memory and virtual memory works using
> CWSDPMI and DJGPP. I want to know this only for curiosity... but maybe this
> helps someone or someone has the same curiosity...
Well, there are basically two things necessary:
A memory mapping unit, MMU, that translates logical addresses to
physical
addresses. Like that, you can have a really huge logical address space,
say
ranging from 1 to 1024 GB. The MMU can map physical memory, real RAM
into
this address space. So if you access memory at location  x, the physical
address
may be y. Or, there is no memory at all at this location. If this
happens, 
a fault condition is generated. The DPMI host can now move another 
physical location to disk and map this physical address to your
requested
address x, maybe paging in the old contents of that address from disk. 
To speed up things, it doesn't work with single addresses, but pages,
which
are under DOS 16k (64k?)




> 
>         Suppose I have a computer with 2 mb free of memory, DOS 6.22 and CWSDPMI
> as DPMI provider. Suppose I have a program (compiled with DJGPP) that it
> has 1mb of code and 2mb of music and bitmaps. Ok, this are my questions:
> 
>         1- Suppose I load all the program and the music and the bitmaps on the
> startup. 

Parts of the code/data are paged out. I think CWSDPMI uses an LRU
algorithm
to page out the oldest "untouched" pages first. So you won't be able to 
get all into memory. If you are not wildly jumping around in your code, 
I'd guess some of the code segment will be paged out first.

> Then, I use only 1mb of the music and the bitmaps in a first
> stage, so the 2mb of the free memory are full with 1mb of code and 1mb of
> data. 
Not neccessarily, see above.

> The question is: what happens when the program enters in a 2nd stage
> where I use the same 1mb of code but the other 1mb of the data?
>                 - The previous data is stored in virtual memory and the other data (the
> one that it is used now and has not been used before) is loaded in memory?
Yes.

>                 - The previous data is leaved in memory and the other (new) data is
> readed from virtual memory?
No. How could the DPMI host that your program does not want to 
reuse the first chunk again? This would get lost, when it would be
simply overwritten.


Thinking about this, wouldn't it be possible for CWSDPMI not to page
out code? This could be overwritten and read back on demand from the
.exe-file. (Yes, I do know there is a certain risk in it. Having run 
a program on my NFS'd home directory on one machine while fiddeling
around with the code and recompiling on another gave me a few nice
core dumps. Sometimes you learn the hard way;-)

> 
>         2- CWSDPMI or DJGPP has something to optimize the speed when all the
> physical memory is not suficient to hold all the data (something like a
> cache?)?
Not built in. And I am not sure SMARTDRV is really on optimization
in this respect. It uses RAM that your program might lack. OTOH, calling
the compiler a few times gets sped up, so on total it is worth it.

Hope this sheds a little light and doesn't confuse too much ;-)
-- 
Ciao
Tom

*************************************************************
* Thomas Demmer                                             *
* Lehrstuhl fuer Stroemungsmechanik                         *
* Ruhr-Uni-Bochum                                           *
* Universitaetsstr. 150                                     *
* D-44780  Bochum                                           *
* Tel: +49 234 700 6434                                     *
* Fax: +49 234 709 4162                                     *
* http://www.lstm.ruhr-uni-bochum.de/~demmer                *
*************************************************************

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019