Re: Virtual Memory for the Heap

Thread View: comp.os.msdos.programmer

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Bruce Atherton Thu, 02 Aug 1990 16:01

#1780

Author: Bruce Atherton
Date: Thu, 02 Aug 1990 16:01

41 lines
2292 bytes

6600m00n@ucsbuxa.ucsb.edu (Rob Blair) writes:
> 
> 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?

Re: Virtual Memory for the Heap

#1794

Author: Duncan Murdoch
Date: Mon, 06 Aug 1990 13:52

21 lines
1387 bytes

In article <2698@mindlink.UUCP> a35@mindlink.UUCP (Bruce Atherton) writes:
>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

Re: Virtual Memory for the Heap

#1805

Author: Walter Bright
Date: Mon, 06 Aug 1990 18:41

16 lines
1428 bytes

In article <2698@mindlink.UUCP> a35@mindlink.UUCP (Bruce Atherton) writes:
>6600m00n@ucsbuxa.ucsb.edu (Rob Blair) writes:
<< 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.

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads