On 12 April 2012 16:09, Stas Sergeev <s...@list.ru> wrote: > > I havent noticed: wasn't writing anything. > Actually, I was unsubscribed from the list, as > you explained, because of the bounces. > Now obviously to re-subscribe the one only > need to post to the list. After my today's post > I started to receive all mails. > I wonder if I need to commit something to get > re-subscribed to the notify list...
you should be able to subscribe using https://lists.sourceforge.net/lists/listinfo/dosemu-cvs > I was mentioning zero page instead, > thinking that you write-protect it to trap the NULL derefs, > but this doesn't seem to be the case. When mmap_min_addr > 0, then mem_base > 0 and all NULL derefs are trapped. Otherwise I know we talked about it but never got to implement it before the non-zero memory base changes beyond the init stage. > 2. lowmem_base is not the real alias, so you can only > access it if you got the reference to it from the _properly > written_ dosaddr_to_unixaddr(), which doesn't exist as > of yet. > The things like IS_GENERIC_LOWMEM_ADDR() and the > direct uses of LOWMEM() is basically the violation of the > design I intended, but the properly written dosaddr_to_unixaddr() > looks like the valid extension to it. But then it is not written. :) > (but at least we agree that it have to be written, so fear not) well I agree things should be cleaned up for sure. As far as I can see LOWMEM() is only used in a few places -- it could be completely removed. I think the lowmem_base areas are useful as r/w mirrors of r/o areas so can be used directly if needed; if the only place that adds lowmem_base to a DOS address, based on mapping info, is dosaddr_to_unixaddr() then that's fine with me. > > Some writes (mainly disk reads by int13 and the mfs, and xms > > transfers) may actually involve code. That's one place where > > e_invalidate() comes in -- the other places are where the memory is > > potentially outside the non-aliased conventional memory range, which > > is why e_invalidate() is also in dpmi.c. (In total I counted 6 or 7 > > e_invalidate() calls, which doesn't look so excessive to me). > Yes but then the emm.c is a candidate too... It is indeed. I haven't seen its memmove's causing a page fault so far but I'm sure you can get them with the right EMS-using DOS program. > What's the use destinguishing the code and the data? > If you have an area protected with the CPU emulator > and someone writes to it, you'd better invalidate, no > matter is it a code or data, or am I missing something? The CPU emulator splits a page in 256 chunks of 16 bytes to see for which it has generated JIT code. As soon as code is generated the whole page is write-protected. If a byte is written for which no code is generated (no matter if it is in actual fact code or data), there is no problem and you don't need to invalidate. It could be that a page consists of 4095 bytes data (or 4095 bytes of untranslated code) and1 byte code; yet the page will be write-protected, and any data writes to it (by the generated code or by DOSEMU itself) will be trapped. In that case you can avoid the trap by writing to an unprotected equivalent page. > so why not just something like that: > #define WRITE_WORD() { \ > if (cpu_emulator) e_invalidate(); \ > write_word(); \ > } while (0) so that's too expensive, because you need to do m(un)protect() calls, and later regenerate code. > OK, I still don't understand anything. Firstly, this: > --- > #define MEMCPY_P2UNIX(unix_addr, dos_addr, n) \ > memcpy((unix_addr), lowmemp(dos_addr), (n)) > --- > suggests that it takes the DOS address. This macro comes from the adjustments to allow DOSEMU to run with non-zero base for mmap_min_addr>0. Before, sometimes addresses were coded as pointers: e.g. (char *)0x2000 and sometimes as integers. Now instead, of using (char *)0x2000 we use &mem_base[0x2000]. Formerly the MEMCPY_2UNIX dealt with both integers and pointers by using casts. Now this won't work anymore, so I introduced MEMCPY_P2UNIX which takes a pointer. Here dos_addr really means "potentially an address in DOS space" -- it is potentially converted from &mem_base[xxx] to &lowmem_base[xxx]; unix_addr is an address that is *always* in DOSEMU space. > Secondly, I can't follow the logic. I think we never had the > precise definition of what is the linux pointer and what is > the DOS pointer. Yes that is the man source of confusion here I think :) > I think you are basically working around the lack of the > properly functional dosaddr_to_unixaddr(). You shouldn't > do p=&mem_base[0xb8000], but rather p=dosaddr_to_unixaddr(0xb8000). > Or are there other reasons to keep lowmemp()? > I mean, let's aim for simplicity. :) If the meaning of the function > is not obvious, it is a suspect for cleanup. One problem is that there are still quite a few places that don't use the READ_BYTE (etc) macros, and take pointers directly into DOS space (e.g. MFS, ReadVTOC in mscdex.c that takes a pointer "buf" that is sometimes in Linux and sometimes in DOS space, snprintf in dpmi/msdos.c). For those I sometimes need to convert a pointer, e.g. &mem_base[0x1000] it points to writable space &lowmem_base[0x1000] to avoid page faults. > I think that's a great work! > Run win.com, and hooplah - windows-3.1 is up and running on > x86-64 dosemu... I'd say WOW! :) Even more amazing and weirdly with the non-zero base. In that case the real LDT has all offsets shifted by (unsigned int)(&mem_base), e.g. when the LDT that DOS applications think they deal with has a segment with a base of 0, its entry in the real LDT that is managed using modify_ldt() has a base of mem_base. Bart ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Dosemu-devel mailing list Dosemu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dosemu-devel
