Message-ID: From: Shawn Hargreaves To: djgpp AT delorie DOT com Subject: Re: far pointers again Date: Tue, 5 Oct 1999 16:49:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Reply-To: djgpp AT delorie DOT com 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.