Mail Archives: djgpp/1998/10/02/21:40:34
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
- Raw text -