Sender: nate AT cartsys DOT com Message-ID: <36157FE7.69E77F6F@cartsys.com> Date: Fri, 02 Oct 1998 18:37:43 -0700 From: Nate Eldredge X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i486) MIME-Version: 1.0 To: "Miles F. Bintz Ii" CC: Eli Zaretskii , djgpp AT delorie DOT com Subject: Re: Access phys. mem above 1 meg References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Miles F. Bintz Ii wrote: > The whole concept of near and far doesn't exist in protected mode. Yes, it does. The 386 is a 32-bit machine, but rightly or wrongly, it's still a segmented architecture. As long as we have segments, we will have near and far. The other extreme is to take the Unix approach, and create one segment that spans the entire address space (so that everything is near) and do all the protection with paging, but DPMI doesn't work that way. > I get > the feeling that this is not the *proper* way to do it. Not to mention, > it *is* called a "hack"... Only by you. The farptr functions or their assembly-language equivalents are the standard way to access memory outside your segment. The nearptr, aka Fat DS, is indeed a hack, but farptr is not. > Is there any way that I can map that memory into part of my data > segment? Sure, with `__dpmi_map_device_in_memory_block'. But it's only supported by DPMI 1.0 hosts, all of which AFAIK cost money (QDPMI, 386Max, etc). Windows doesn't support it (thank you, Microsoft), and neither does CWSDPMI (at the moment, though that could change). > And in fact, the FAQ says this method is slow... but then later goes on to > say that 'experience says.... its not that bad'. But recommends using > nearptr hack if I need that additional speed. With the `_farns*' family, it's a `mov' instruction, with a segment override. That takes one extra cycle. At 300+ MHz, one cycle is not much time. And you have big chunks of data to move, `movedata' has a small, *fixed* overhead, which will be a very few cycles slower than a `memcpy', even for enormous transfers. > > > I would like to be able to say > > > > > > char *myptr = 0xda000000 > > > myptr[0] = 0xab; > > > > This is exactly what nearptr allows you to do. So what's the problem? > > > > Near pointer takes away protection. There ain't no such thing as a free lunch. > As it turns out, I've decided that the far ptr hack will suffice to > read/write small pieces of data. For my "performance sensitive" > reads/writes I will probably use a section of memory in DS and use the > movedata function to get it out to the correct memspace. Do you know any > of the details on movedata? Does this use DMA? How is the performance of > this function when moving large blocks of data? It boils down to a `rep; movsl', so that's as fast as you're going to get with the CPU. DMA requires that your *device* do the work, so if it could, you'd probably know. Suggestion: Try it, get it working, *then* worry about speed. Use a profiler. -- Nate Eldredge nate AT cartsys DOT com