X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: HELP with DPMI under DOS - Part II
Date:	Sat, 25 Oct 2003 23:30:04 CDT
Organization:	Rice University, Houston, TX
Lines:	78
Message-ID:	<3f9aec88.sandmann@clio.rice.edu>
References:	<3f99c179$0$164$cc7c7865 AT news DOT luth DOT se>
NNTP-Posting-Host:	clio.rice.edu
X-Trace:	joe.rice.edu 1067143343 21147 128.42.105.3 (26 Oct 2003 04:42:23 GMT)
X-Complaints-To:	abuse AT rice DOT edu
NNTP-Posting-Date:	Sun, 26 Oct 2003 04:42:23 +0000 (UTC)
X-NewsEditor:	ED-1.5.9
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

> : Due to the size of a 1GB-4GB address space, you will get sub-optimal 
> : performance using 4KB pages since the address lookups can't all be cached.  
> 
> Yes. So what? Do we want standard compliance that works everywhere? Or
> a hack that works only if special circumstances apply?

The DPMI 0.9 specifications will still be supported.  The DPMI 1.0 
specification doesn't talk about multiple page sizes or 4MB pages - which
isn't surprising since it was written before the hardware which 
supports this existed.  So some of the DPMI 1.0 functions that do page
protection (null pages) or page mapping might not work on a 4MB page.

The DPMI provider could then break up that page if needed into 4KB pages
to support these functions, or it could fail them.  The 4MB page size
code could be transparent to the application.  But since CWSDPMI doesn't
fully support the DPMI 1.0 specification, and the use of the DPMI 1.0
calls is *VERY* rare (only the null page protection usually) - I wonder
if it is worth the effort.  (First pass I decided not).

All of the users who have contacted me about > 500MB of memory under DOS
have mentioned the following requirements:
  1) Ultimate performance - better than other OSes, and
  2) Maximum memory - preferably more then 2GB (not available elsewhere).
So far no one using the work in progress r6 has complained about about
10 things which are broken with DPMI 1.0 features on 4MB pages.  But
all have pointed out relatively large performance improvements.

So I'm convinced that I can provide DPMI 0.9 compliance, and mostly
backward compatible DPMI 1.0 features which CWSDPMI provided before, and
improved large memory support - all in the same image.  The 4MB page 
stuff is only active when a request for more than 4MB in a single request
is made, the page table for that 4MB space doesn't exist yet.  I don't
page 4MB pages either.  It's been suggested that I limit 4KB pages to
the first 256MB of memory and use 4MB pages for the rest, and only 
enable it with more than 256MB physical.  But I haven't done anything
on it in 2 years (people with the test image are happy so far).

> Yes. But as you said yourself that won't be VCPI compatible.

That's because VCPI doesn't support 4MB pages:
  1) when you ask for memory it gives it to you 4KB at a time
  2) you share page tables with VCPI, and it might fry it's brain

If VCPI supported these features, then I don't see a problem.

> I don't myself see why that won't be VCPI compatible if the first 4MiB
> is mapped with ordinary 4KiB pages. You should be permitted to do
> sever abominations above 4MiB.

Still the problem of allocating memory in 4MB contiguous, aligned chunks.
And I would never be sure that a VCPI server wouldn't freak if it saw 
a 4MB page in the page directory.

> Yes. But you also decided to be not VCPI compatible.

Not completely true.  When I started there was no VCPI server available
which would serve more than 500MB of physical memory.  The r6 work in
progress still works with VCPI, it just doesn't attempt to use 4MB 
pages.  Since memory was always to much less than 500MB by the VCPI
server, no one interested in large memory would run VCPI.  There are
bad bugs in EMM386 which occur when you try to run it on systems with
huge amounts of memory.

If we did a full testing of VCPI servers, and found that none had problems
with 4MB pages then I would consider additional support.

So I've currently chosen not to even try under VCPI, due to potential
problems, implementation issues and complete lack of demand for this
environment.

> : PMODE avoids the issue completely by not turning on paging at all 
> : unless it must to deal with VCPI.
> 
> And what will happen if PMODE finds itself in a VCPI environment? 

Under VCPI it allocates the number of page tables needed to completely
map the physical memory (in DOS memory space).  So it would also
fail with more than 500MB or so of physical memory under VCPI.

- Raw text -