Beta Test: CWSDPMI r7 - 4GB support

[Charles Sandmann]

I would like to announce the beta for CWSDPMI release 7.

The purpose of this release is to allow high performance access to large
amounts of physical memory (up to 4GB). Memory above 32-bit address space
(common on machines over 3GB physical memory) will be mapped to fill the
address hole to provide a full 4GB memory. 4MB pages will be automatically
used for large memory requests. Release 7 also includes the bug fixes
included
in the release 5 2008 refresh, and improved 4MB page support included in the
never completed r6.

Current DJGPP releases support large memory allocation requests and with
CWSDPMI release 7 allow a contiguous memory block over 4091MB. This
CWSDPMI release is dedicated to those few dozen people who want to prove
their 4GB+ computers can actually run 4GB 32-bit applications.

For those who need more than 4GB, I'll provide some code that allows you
to map 5GB+ memory (up to 64GB) into the address space on request.
The next release will probably be when I get several people bugging me that
64GB isn't enough under DOS :-)

Binary Distribution: http://clio.rice.edu/djgpp/beta/csdpmi7b.zip
Source Distribution: http://clio.rice.edu/djgpp/beta/csdpmi7s.zip

Please send me any comments or bug reports.
Have fun, and thanks for testing !

[jimmy...@gmail.com]

Hello,
I have one question about CWSDPMI r7 for 5GB+ support...

"...For those who need more than 4GB, I'll provide some code that allows you

to map 5GB+ memory (up to 64GB) into the address space on request"

=> Does this means(for example) if I allocate memory buffer then the returned pointer will point to the physical memory "beyond 4GB" ? Am I correct ?

Ex. the pointer value is 0x100000000 ....

Best wishes,

[Georg Potthast]

I have a question which I do not know if this related to CWSDPMI. I develop my programs in a Windows XP DOS box and they work fine there. When I then try them in real mode DOS they crash due to uninitialized pointers. So I have to work through the program again and fix that. But some of these problems I may not find and my users observe crashes.

Does Windows DPMI set the allocated memory to zero for you while CWSDPMI does not? Then a "char* mystring;" is set to NULL by Windows.

Georg

[Charles Sandmann]

<jimmy...@gmail.com> wrote in message
news:09068ed9-d989-4db5...@googlegroups.com...

CWSDPMI uses the page tables to re-map your system memory, making the first
4GB appear to be (mostly)
memory, filling the memory holes, replacing video ram, etc. So usually some
of the memory will come from above
the 4GB mark. But all of your pointers are 32-bit due to the page table
remapping.

If you want to access more then 4GB total, then a memory window is set up,
which you then can point to the
remaining unused memory. This is similar to EMS memory in the DOS 16-bit
days, so it is up to the user to manage
which section of memory is available in the "window".

[Charles Sandmann]

>"Georg Potthast" <dos...@googlemail.com> wrote in message
>news:788e2b72-ab43-4ae4...@googlegroups.com...

CWSDPMI does not initialize the memory (to improve performance). On a
single process system, there is no need to do this if the program is
properly written (no security issues leaking data).

To find these pointers (or to simply fix it), DJGPP has two features which
allow you to fill the memory, see crt0.h:

/* If set, fill sbrk()'d memory with a constant value. If not, memory
** gets whatever happens to have been in there, which breaks some
** applications. */
#define _CRT0_FLAG_FILL_SBRK_MEMORY 0x0020

/* If set, fill memory (above) with 0xdeadbeef, else fill with zero.
** This is especially useful for debugging uninitialized memory problems. */
#define _CRT0_FLAG_FILL_DEADBEEF 0x0040

[jimmy...@gmail.com]

> If you want to access more then 4GB total, then a memory window is set up,
>
> which you then can point to the
>
> remaining unused memory.

If user setup a memory window to access "more than 4GB", the <pointer> is still 32-bit ? Am I correct ?

My goal is to allocate one memory buffer and its "physical address" is beyond 4GB. Then this address will be set to H/W register for DMA transfer...(Besides CPU can access this buffer, too) Thus I have to get more than 32-bit pointer and then assign it to H/W...

I do not know if CWSDPMI+DJGPP can do this kind of task...

Thanks !

[Georg Potthast]

The memory mapped registers usually "hang out" at the end of the 4GB memory area.

I think there should be enough memory within the 4 GB area to allocate a DMA buffer there. But to allocate the buffer anywhere starting above the 4 GB area you will have to be able to write a 64bit linear address into the HW register. So far I have only seen 32bit HW registers.

If you manage to write a 64bit linear address into the HW register, CWSDPMI
would need to provide a DPMI function like "Int 31H Function 0800H" for the area above 4 GB to allow you to access that with 32bit addresses. I doubt that this was on the agenda yet.

[Georg Potthast]

Thank you very much for the information. I did not know about these functions and will try that.

Georg

[Charles Sandmann]

<jimmy...@gmail.com> wrote in message
news:cbe4c56f-4098-445b...@googlegroups.com...

>If user setup a memory window to access "more than 4GB", the <pointer> is
>still 32-bit ? Am I correct ?

Correct. Where that 32-bit pointer points in physical memory is controlled
by the page tables. All memory over the 4GB is handled in 4MB page chunks.
It is possible that 8MB in DJGPP address space would not be contiguous in
physical memory, but it will be
mapped into you address space in the order you touch it.

>My goal is to allocate one memory buffer and its "physical address" is
>beyond 4GB.
>Then this address will be set to H/W register for DMA transfer...(Besides
>CPU can
> access this buffer, too) Thus I have to get more than 32-bit pointer and
> then assign it to H/W...

Let's suppose your computer has 4GB physical memory. Typically between
2.5GB and 3.5GB of that memory is actually below the 4GB address point. The
remaining typically starts at the 4GB address point. On this computer you
could just sbrk() up to 4092K,
then touch the memory in order (first byte in each 4MB aligned page). If
you then look at the physical map, you will very likely
have at least a 500MB buffer you can configure that actually is above the
4GB address.

There is a very old program -
http://homer.rice.edu/~sandmann/djgpp/cwsdma2.zip - that was designed for
creating DMA buffers under CWSDPMI. Note that this hasn't been updated for
r7 and physical addresses > 4GB, but slightly modified code can provide what
you are looking for.

From this program, you can also see it is possible to modify the page tables
and re-map your own memory as needed.

> >I do not know if CWSDPMI+DJGPP can do this kind of task...

You would be responsible for the HW writes, but you can certainly get full
control of your memory layout. If you have lots of memory, like 64GB, then
you would need to manage it from DJGPP; CWSDPMI does not bother with
managing more than
the first 8GB.

[jimmy...@gmail.com]

> Let's suppose your computer has 4GB physical memory. Typically between
> 2.5GB and 3.5GB of that memory is actually below the 4GB address point. The
> remaining typically starts at the 4GB address point. On this computer you
> could just sbrk() up to 4092K,
> then touch the memory in order (first byte in each 4MB aligned page).

I think what you want to express is: the remaining memory will be "re-mapped" to above 4GB address via sbrk(). Am I correct ?

> If you then look at the physical map, you will very likely
> have at least a 500MB buffer you can configure that actually is above the
> 4GB address.

Here "at least a 500MB buffer you can configure" means: application(or program) can access this buffer using "indirect" way, am I correct ?
(where indirect way means you have to invoke api(or system call) to get pointer first, then access it...)

If above is correct, then can I get the "physical memory address" of that buffer ?
(the reason I ask is: H/W DMA transfer requires only the physical memory address !)

* To sum up, s/w access that buffer(above 4GB physically) indirectly but h/w access it directly(no transform, no remap)

[Georg Potthast]

I refer you to DPMI Int 31H Function 0800H again. If Charles would extend that to work with EBX:ECX you could get the physical address of memory.

[Charles Sandmann]

><jimmy...@gmail.com> wrote in message
>news:3f7ac344-a8b1-4300...@googlegroups.com...

>> Let's suppose your computer has 4GB physical memory. Typically between
>> 2.5GB and 3.5GB of that memory is actually below the 4GB address point.
>> The
>> remaining typically starts at the 4GB address point. On this computer
>> you
>> could just sbrk() up to 4092K,
>> then touch the memory in order (first byte in each 4MB aligned page).
>
> I think what you want to express is: the remaining memory will be
> "re-mapped" to above 4GB address via sbrk(). Am I correct ?

No - DJGPP only works with 32-bit addresses. As far as it is concerned,
there is nothing beyond 4GB. PC hardware on the other hand typically stops
with memory at 3GB. CWSDPMI works with memory mapping via page tables, so
can collect memory from wherever it exists to make a virtual contiguous 4GB
address space (even if there are memory holes in the physical memory).

Even though memory is allocated it is not committed into memory until it is
accessed (which makes lots of sense in a tight memory system with paging to
disk, but provides weird physical mapping if unaware of this behavior -
pages may appear to not exist until they are touched).

The trick for knowing about memory over 4GB is looking at the page tables
(an Intel hardware feature). So DJGPP may say
that memory lives at the 3GB mark, but in reality the physical address is at
4GB.

>> If you then look at the physical map, you will very likely
>> have at least a 500MB buffer you can configure that actually is above the
>> 4GB address.
>
> Here "at least a 500MB buffer you can configure" means: application(or
> program) can access this buffer using "indirect" way, am I correct ?
> (where indirect way means you have to invoke api(or system call) to get
> pointer first, then access it...)

There are many ways to set up the mapping. Unless you have very specific
size needs the easiest way is to allocate
memory with sbrk() and look for the memory chunk above 4GB and use it. More
specific needs means more programming. In any case you just use an ordinary
pointer to access it under DJGPP.

> If above is correct, then can I get the "physical memory address" of that
> buffer ?

As referred to in the previous post, a modified copy of
http://homer.rice.edu/~sandmann/djgpp/cwsdma2.zip
would give you the physical memory mapping.

> (the reason I ask is: H/W DMA transfer requires only the physical memory
> address !)

Which is why the code above has the letters DMA in the title.

[Charles Sandmann]

>I refer you to DPMI Int 31H Function 0800H again. If Charles would extend
>that to work with EBX:ECX you could get the physical address of memory.

Not likely to happen, would require major restructuring of some internal
CWSDPMI code. The current page table workaround works well, and anything
else would also be CWSDPMI specific. Given the very low need for this type
of usage (a handful of people), not worth programming/debugging effort.

Almost all DOS users have no need for 2GB, much less 4GB. A few do, but
even fewer of those need either physical addresses
or more than 4GB. Nice free operating environments will give you a linear
64-bit address space.

Fixing bugs with memory layouts including holes will happen first (certain
hardware), and it's already been sitting in the request list for 9 months.