rpk@august-east.ai.mit.edu (Robert Krajewski) (09/30/90)
In article <4990@hsv3.UUCP> jls@headland.UUCP (James Seidman) writes: >BTW, I have heard that loading segment registers in protected mode takes >a VERY long time (36 cycles sticks in my mind). I'm not sure if this is the exact number, but it is pretty bad compared to a normal register load. And it doesn't matter if ES or DS is repeatedly loaded with the same selector over and over again, either, at least on the 286. That's because the 286 does not keep track of LDT (remember, that's the per-task descriptor/selector table) that was in effect the last time that particular segment register was reloaded. It can't cache the segment-related information, since the same descriptor bits can map to different segments in different address spaces. And, on the 386, there probably wasn't enough incentive to be clever about this due to the overall improvement in speed, and the expectation that the processor would be used (mostly) to run 32-bit software, where this concern shrinks away. Of course, in reality, only a version small portion of PCs (except those running Unix, still a distinct minority) have never used this feature, except in a few industrial strength programs that run under DOS extenders (Autocad, Paradox 386, Golden Common Lisp 32bit, &c.). If you are really concerned about the performance of a large application that has to be delivered under Windows on a 386 (or better), peruse the 32-bit memory DLL information described in one of the appendices of the SDK documentation. There's not much support for actually using it: you must run out of your own 32-bit world (including the stack segment), so you must deal with data passing, stack switching, and startup issues. But for some, it may pay off, rather than waiting for OS/2 2.0. ---- Robert P. Krajewski Internet: rpk@ai.mit.edu ; Lotus: robert_krajewski.lotus@crd.dnet.lotus.com