Virtual Memory for the Heap

Virtual Memory for the Heap

Post by Bruce Athert » Fri, 27 Jul 1990 01:34:43



I'm looking for the best method of implementing virtual memory on 80x86
machines under MSDOS.  Specifically, it has to allow swapping of the
heap, rather than code.  The method that is the simplest to implement
and least buggy would be preferable.

I just received Turbo C++ and was thinking of using VROOMM, but it
appears to only swap overlays of code.  Is there any way to allow it to
swap from the heap?  Do I have to overload the -> operator so that it
works with pages, or can VROOMM take care of that for me (and if so,
how?).

What about using _handle in Zortech C++?  It sounds like it would be
easy for bugs to creep in, from the description I read.  I would also
like to hear about any heap manager toolboxes and how they work.

Finally, is there a speed advantage to any of these methods over using a
disk caching system?

I would be grateful for any information on these questions.


uunet!van-bc!rsoft!mindlink!a35| to protect 'gainst injuns, but that's stupid.
                                 Injuns knew about doors.  But clams didn't."

 
 
 

Virtual Memory for the Heap

Post by Jihad 'R » Sat, 28 Jul 1990 19:39:20


   I'm looking for the best method of implementing virtual memory on 80x86
   machines under MSDOS.  Specifically, it has to allow swapping of the
   heap, rather than code.  The method that is the simplest to implement
   and least buggy would be preferable.

   I just received Turbo C++ and was thinking of using VROOMM, but it
   appears to only swap overlays of code.  Is there any way to allow it to
   swap from the heap?  Do I have to overload the -> operator so that it
   works with pages, or can VROOMM take care of that for me (and if so,
   how?).

VROOM will not swap data.  The main problem with swapping data is that
it is accessed 'asyncronously'. i.e.  You never know when you will need
to be in, since pointers can point anywhere.  Code is always accesed
with calls, and can be routed through a overlay maneger. ( setjmp,
longjmp could cause problems . . .)   One way of dealing with this is to
only use access to memory through 'handles' ( picked the idea up from
_mac_ programing.) and have a byte that says if the info is in main
memory ( in which case you use the pointer in the handle structure) or
not, in which case you use the (ems|xms|ext|disk) handle you have setup
to load the handle into main memory( and load out any needed to make
space). You could even put a byte in for 'locking' the pointer so it
does not get swapped out.

   What about using _handle in Zortech C++?  It sounds like it would be
   easy for bugs to creep in, from the description I read.  I would also
   like to hear about any heap manager toolboxes and how they work.

   Finally, is there a speed advantage to any of these methods over using a
   disk caching system?

Yes:  disk caching doesn't do diddly for speeding up writing data.
Not so important with code( how often do you write self modifing code)
very important with data.

  I would be grateful for any information on these questions.
happy to reply.


'Yea, brother . . .'

 
 
 

Virtual Memory for the Heap

Post by Walter Brig » Sun, 29 Jul 1990 06:22:41


<I'm looking for the best method of implementing virtual memory on 80x86
<machines under MSDOS.  Specifically, it has to allow swapping of the
<heap, rather than code.  The method that is the simplest to implement
<and least buggy would be preferable.
<
<What about using _handle in Zortech C++?  It sounds like it would be
<easy for bugs to creep in, from the description I read.

I've used _handles quite a bit in my code. The reason they were implemented
is that the code looked so *ugly* when explicit function calls had to be
done to dereference a handle. Thus, making a handle a special pointer type,
and having the compiler call the function for you, cleaned up the code
a lot. I'd say that the _handles are certainly the easiest to convert your
code into using.

The thing to watch out for is inadvertently converting a handle to a far
pointer, as in stuff like:
        char _handle *h;
        h = (char *) handle_malloc(10);         /* error!       */
        h = (char _handle *) handle_malloc(10); /* correct way  */

 
 
 

Virtual Memory for the Heap

Post by Bruce Athert » Sat, 04 Aug 1990 01:01:58



> The main problem with swapping data is that
> it is accessed 'asyncronously'. i.e.  You never know when you will need
> to be in, since pointers can point anywhere.  Code is always accesed
> with calls, and can be routed through a overlay maneger.

As long as a function was called every time a pointer was dereferenced,
the time that the data was accessed wouldn't be a problem.  Of course,
that function would somehow have to be able to tell what page the
pointer belonged to, and swap it in if necessary.

You could do that three ways that I can think of off of the top of my
head.  First, you could have a special memory model that had 6 byte
pointers.

Second, you could use the Zortech method of assuming that pointers will
never want to point into the BIOS.  This strikes me as dangerous, since I can
think of reasons why I might want a pointer to point there.

The third method, and one I am sorry they didn't include as part of
VROOMM, would be to use normalized pointers and store the page
information in the unused part.

In Turbo C++, there is a Huge memory model that automatically normalizes
your pointers, so the offset is always between 0 and 15.  That means the
pointers look like this -

Bit FEDCBA9876543210:FEDCBA987654210   s = segment
    ssssssssssssssss:xxxxxxxxxxxoooo   o = offset
                                       x = unused

Why couldn't there be a variant of the Huge memory model called Virtual,
that used those unused bits to store page information for a memory
manager?  Some function must be ensuring that the pointers stay
normalized.  If that function is called whenever a pointer is
dereferenced, a virtual memory manager would be simple to implement and
almost invisible to the programmer.

I know, I know.  That ain't the way Turbo C++ works.  Is there anything
that does, other than Zortech?

 
 
 

Virtual Memory for the Heap

Post by Bruce Athert » Sat, 04 Aug 1990 01:03:42



> I've used _handles quite a bit in my code. The reason they were implemented
> is that the code looked so *ugly* when explicit function calls had to be
> done to dereference a handle. Thus, making a handle a special pointer type,
> and having the compiler call the function for you, cleaned up the code
> a lot. I'd say that the _handles are certainly the easiest to convert your
> code into using.

> The thing to watch out for is inadvertently converting a handle to a far
> pointer, as in stuff like:
>         char _handle *h;
>         h = (char *) handle_malloc(10);         /* error!       */
>         h = (char _handle *) handle_malloc(10); /* correct way  */

I agree that explicit calls for dereferencing is no way to implement
virtual memory.  Zortech seems to use the most elegant solution I've
heard about so far.

Can you use a _handle anywhere you would use a pointer?  Can you declare
a _handle to a _handle to a function that returns a _handle? Does this
have to be a part of the compiler, or could I write an object in any C++
that would do the same thing?

Finally, can you create a pointer into the ROM BIOS area?

Thanks for your help.


uunet!van-bc!rsoft!mindlink!a35| We drive chicks MAAADD! - The Frantics.

 
 
 

Virtual Memory for the Heap

Post by Duncan Murdo » Tue, 07 Aug 1990 22:52:07



>The third method, and one I am sorry they didn't include as part of
>VROOMM, would be to use normalized pointers and store the page
>information in the unused part.
...

>Why couldn't there be a variant of the Huge memory model called Virtual,
>that used those unused bits to store page information for a memory
>manager?  Some function must be ensuring that the pointers stay
>normalized.  If that function is called whenever a pointer is
>dereferenced, a virtual memory manager would be simple to implement and
>almost invisible to the programmer.

>I know, I know.  That ain't the way Turbo C++ works.  Is there anything
>that does, other than Zortech?

Turbo Pascal also uses normalized pointers, and there's a package available
(called HEAP55.xxx for TP 5.5) that calls an interrupt every time a pointer
is dereferenced.  

Duncan Murdoch

 
 
 

Virtual Memory for the Heap

Post by Walter Brig » Wed, 08 Aug 1990 03:41:14


<< The main problem with swapping data is that
<< it is accessed 'asyncronously'. i.e.  You never know when you will need
<< to be in, since pointers can point anywhere.  Code is always accesed
<< with calls, and can be routed through a overlay maneger.
<As long as a function was called every time a pointer was dereferenced,
<the time that the data was accessed wouldn't be a problem.  Of course,
<that function would somehow have to be able to tell what page the
<pointer belonged to, and swap it in if necessary.
<Second, you could use the Zortech method of assuming that pointers will
<never want to point into the BIOS.  This strikes me as dangerous, since I can
<think of reasons why I might want a pointer to point there.

You *can* have pointers pointing into the BIOS. They just cannot be _handle
pointers, they must be regular far pointers.

 
 
 

Virtual Memory for the Heap

Post by Walter Brig » Wed, 08 Aug 1990 03:50:34


<I agree that explicit calls for dereferencing is no way to implement
<virtual memory.  Zortech seems to use the most elegant solution I've
<heard about so far.
<Can you use a _handle anywhere you would use a pointer?

Anywhere you would use a far pointer, except if you want a far pointer
that points into the BIOS.

<Can you declare a _handle to a _handle to a function that returns a _handle?

You cannot have _handle pointers to functions (there is no point to that!).
But you can do things like:

        char _handle *(_handle **)(void);

which is a _handle to a pointer to a function returning a _handle.

<Does this have to be a part of the compiler, or could I write an object
<in any C++ that would do the same thing?

You can do it in standard C++ on a class-by-class basis by overloading the
* [] and -> operators. The disadvantage is that the optimizer cannot tell
when the dereferencing function calls are redundant and cannot eliminate
them. For instance:
        struct A __handle *h;
        h->a = 1;
        h->b = 2;
On the second assignment, the function call to dereference h can be
eliminated if handles are built in to the compiler, but cannot be if
it's a user-defined function in C++.

You cannot do it with pointers to something-besides-a-class in standard C++.

<Finally, can you create a pointer into the ROM BIOS area?

Yes. Simply use a far pointer:
        char far *p = MK_FP(0xFFFF,0);