[Coco] VCC, MMU & AWE

Walter Zambotti zambotti at iinet.net.au
Mon Jun 12 02:31:57 EDT 2017


>First: don't start a new thread by replying to an old one and changing the subject. That doesn't >actually start a new thread.

I need to read the instructions on how to start a new thread!  

>Second: mremap() does not do what you think it does, and is a GNU specific extension to the C >library. mremap() has nothing to do with moving one part of the address space to another - it's used >to change the size of an existing mapping.

Probably correct, but I have found some sample mremap code for performing memory page swapping which is effectively what needs to be done.  Granted I haven't tested that code.

Regarding compatibility:

Even if it didn't work as required it would not be too much to make it:

1.  A user config option: Enable Hardware MMU Acceleration (Windows Only) (Y/N) or.
2. Have the code to try to enable it by default and on the exception default back!

Regardless of all that there may be a situation where AWE cannot mimic the MMU and my testing has found that the same physical page cannot be mapped into the virtual window more than once.

So AWE could not handle something like this (for example where every page is set to the same page):

MMUreg[0][0] = 56;
MMUreg[1][0] = 56;
...
MMUreg[7][0] = 56;

Regardless of the implications of this I'm sure the MMU does not perform any checking and would allow it.

The closest thing in AWE would be to replace the duplicate pages with a NULL page pointer that would cause a memory access violation on any attempt to access those pages.

I'm sure the MMU does not have support for memory access violations!

So it may not be possible after all!

Anyway I think it's worth exploring all the options and documenting the results so that in the future if certain limitations are removed then we know what we have available for extending the development of VCC.

Walter

-----Original Message-----
From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of William Astle
Sent: Monday, 12 June 2017 12:58 PM
To: coco at maltedmedia.com
Subject: Re: [Coco] VCC, MMU & AWE

On 2017-06-11 10:26 PM, Walter Zambotti wrote:
> However I have already tested AWE support in WINE (Linux) and it is not there so until the function stubs are fully implemented this would be a Windows only modification!!!
> 
> However I am only using three AWE functions and Linux provides the mremap function which may make it possible to allow rudimental AWE support.

First: don't start a new thread by replying to an old one and changing the subject. That doesn't actually start a new thread.

Second: mremap() does not do what you think it does, and is a GNU specific extension to the C library. mremap() has nothing to do with moving one part of the address space to another - it's used to change the size of an existing mapping.

Further, there is no mechanism on any platform other than Windows to do anything like AWE. This is likely the reason AWE is not implemented in Wine - it would have to be simulated with no operating system assistance at an immense performance and complexity penalty. Given that this also seems like an abuse of AWE given it's actual purpose which is to allow a
32 bit process to access memory beyond 4GB, it seems like there would not be a lot of applications that would be used under Wine that would benefit from such an implementation. Scarce resources and all.

It may be a reasonable "optimization" under Windows. However, it has no benefit on any other platform and will make the previously stated goal of eventually getting VCC running on platforms other than Windows more difficult in the long term. It also, as you have discovered, prevents VCC from running under Wine which would eliminate all current Linux and Mac users of VCC from the user base.

--
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco



More information about the Coco mailing list