Mail Archives: djgpp/1999/10/06/08:27:24
Shawn Hargreaves (SHargreaves AT acclaimstudios DOT co DOT uk) wrote:
: That, IMHO, is the right way to do it. The need to use far pointers
: in djgpp is a misfeature of the design of DOS and DPMI, and not a
: good thing if there are other alternatives.
IMHO, everything that is possible on a platform, should be somehow possible
in C. The x86 processors support multisegmented memory models in protected
mode. Many c compilers support far pointers. Why wouldn't you support it
just because you think a flat memory model is better?
: I would tend to copy the string to local memory first: farptr memory
: is awkward to access, and it is usually better to think of it as a
: kind of very fast backing storage, and swap things into your real
: address space whenever you need to do serious work on them.
As a assembly programmer, I dislike copying information when you don't have to.
: But I have to ask, why do you want to do this at all? I think the best
: answer to "how do I do a printf with farptr data" is "don't do that".
: It looks to me like you are used to working with realmode segmented
: memory, but you need to understand that protected mode works
: differently, and generally I think that this is a wrong design to be
: trying at all. Give some more details about what your program is
: actually doing, and we can suggest other approaches that might be more
: useful.
My os is supposed to use a segmented memory model. Every process has its own
ldt with a code segment, a data segment and a video buffer and probably more.
Interfacing with the os is done by passing messages to drivers etc. which
are processes on their own. No process can possibly reach data that doesn't
belong to it. That is the story. In asm life was easy just considering far
pointer support. But writing an os in asm only is very much work. So I decided
on using c. But I _need_ those far pointers.
: I agree. Allegro uses entirely farptr access, and when I tried
: changing it to the nearptr method, I saw only a few percent
: speed improvement on the putpixel function, and no measurable
: difference on any of the more complex real world routines. This
: was a mixture of functions that were written by hand in asm,
: and others in C using farptr functions, so I think it was quite
: an accurate test.
I don't want to have test results and other stuff to justify the fact that
the usage of far pointers in djgpp results in less efficient code.
So what is this gcc group that maybe should be told about considering far
pointers?
Thanx for all comments so far,
David
- Raw text -