Mail Archives: djgpp/1999/10/05/14:49:49
Eli Zaretskii writes:
>> I was told that under linux, one can create other descriptors in the
>> ldt and reference to them by using far pointers (of course).
>
> I'd guess that you'd need to do the same on Linux. In other words, you
> cannot have a true 48-bit far pointer in Linux, unless you do it in
> assembly.
>
> Can someone who has easy access to Linux check that?
I think it is just about the same as djgpp, except far less well
supported in libc (no farptr.h, no movedata, etc). Certainly this
can't be done without using asm, or C library functions that are
themselves implemented in asm.
I don't know anything about how you'd allocate new selectors in the
GDT. No doubt it is possible, but you probably need special rights
to do it.
The thing is, though, that you never _need_ to do such things in
Linux. There is no need to interface with old 16 bit OS calls, and
the Unix API makes it easy to map special memory regions directly
into your address space (for example call mmap() on /dev/mem if
you want to use a physical address range, or use /dev/fb if you
want to access the video framebuffer), so even quite lowlevel
hardware hacking programs never need to go within a million miles
of a far pointer.
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.
>> Right now, I have to use temporary variables to store the
>> information when I decide to, say, use printf to display a number which
is
>> stored in another segment. When I want to print a string part stored in
>> another segment I should design a printf which handles far pointers or
copy
>> the string to the ds segment? I don't know exactly what to do
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.
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.
> You might look at the sources of _far* functions and movedata: they all
> are written in fast assembly that works exactly as optimal code emitted
> by a compiler would.
To write efficient farptr code you do need to manually take care of
loading the selector with _farsetsel(), and then use the _farns*()
functions, though. A naive function that just used the _farpoke()
family of routines without presetting the selector would be much
slower than a compiler would produce.
Not that I'm trying to justify those horrible "far" and "near"
keywords, personally I think they are one of the worst abominations
ever imposed on the C language :-)
> Measurements generally confirm that there's no visible performance
> penalty, even if you compare with the nearptr hack.
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.
Shawn Hargreaves.
- Raw text -