Is Protected Mode Slower than real mode?
Aluno do DEEC
--
**********
Aluno do curso de Engenharia Electrotecnica e Computadores
Faculdade de Engenharia da Universidade do Porto
Portugal
Scart
Howdy,
from experience, I know that that varies. When you have to use the
registers in 16-bit mode, because there's little register space left, and
you want to put as much as possible in them, that would probably go faster
in (flat) real mode, because, then, 16-bit registers are default. In other
instances, using 32-bit registers might be what you need, and in protected
mode, that's default. You could say that my first example occurs more
often, so the answer would be: yes.
But, .. it -is- easier to code in protected mode..
Scart/MetalMinds..
Ik heb een trechtertje op mijn hoofd..
Kurt Friis Hansen
dee...@tom.fe.up.pt (Aluno do DEEC) wrote:
Yes and no.
It depends on the code, you produce.
If your code contains code involving selectors (in real mode called
segments) - i.e. in "far" calls or (re)loading selector/segment registers,
things will be far slower in protected mode (due to the overhead in
checking access rights and memory composition for the selector) compared to
real mode.
If you employ a "flat" memory scheme, where selectors are never involved
(comparable to the DOS COM format, but allowing addressing of up to 4 GB
memory per selector), there's no extra penalty, if you design your code
wisely.
The underlying extender or operating system may introduce these penalties,
but as far as your code is concerned, there should be no "extra's"
involved, if you employ the "flat model" - as long as you code wisely (but
that applies to all kinds of coding ;-)
Best regards
Kurt Friis Hansen - kfr...@post4.tele.dk
Europe 1996: A bribe a day keeps the taxman away...
Yousuf Khan
dee...@tom.fe.up.pt (Aluno do DEEC) wrote:
Hmmm, that's all I got here. Do you actually have a body to your
message, or are you just letting the subject line say it all for you?
In answer to your question, yes, Protected Mode is overall slower than
Real mode for a lot of things: code branching, I/O accesses, interrupt
processing, etc. But that's because there is more steps to go through
in Protected Mode, to keep everything safe.
Yousuf Khan
--
Yousuf J. Khan & Issa S. Khan | Just because you're paranoid doesn't
yk...@achilles.net | mean that they are not out to get you.
you...@idc.com |
Ottawa, Ont, Canada |
Nation's capital |
Kevin McKerron
Yousuf Khan wrote:
> In answer to your question, yes, Protected Mode is overall slower than
> Real mode for a lot of things: code branching, I/O accesses, interrupt
> processing, etc. But that's because there is more steps to go through
> in Protected Mode, to keep everything safe.
True, many operations are slower in protected mode, but most of them are things that efficient code shouldn't
be doing frequently, such as changing selectors. The section of the CPU that handles segment protection and
memory mapping is active even in real mode (with default limits), although the OS only has control of it when
in PM. In fact, according to my Microsoft MASM 6.0 Quick Reference, I/O access (that doesn't get trapped) is
actually FASTER in protected mode. For example,
in AL,imediate
takes 14 cycles in real mode, but only 9 in protected mode (on a 486.) Note, though, that this is for untrapped
I/O. Any I/O the OS intercepts takes 28, plus the time the OS routines take to respond.
Of course, the few operations in PM that are slower are definitely made up for in the huge increase in overall
program speed that can be gained from not constantly checking to see when you've run into an inappropriately
small 64k segment boundary.
Kevin
Herman Dullink
>in PM. In fact, according to my Microsoft MASM 6.0 Quick Reference, I/O
>access (that doesn't get trapped) is actually FASTER in protected mode.
>For example,
>
> in AL,imediate
>
>takes 14 cycles in real mode, but only 9 in protected mode (on a 486.)
>Note, though, that this is for untrapped I/O. Any I/O the OS intercepts
>takes 28, plus the time the OS routines take to respond.
allowed to access this particular I/O port. In Win NT, only device drivers
are allowed to acces I/O.
Same story in DPMI, the PM host won't allow you to access the RESET pin of the
CPU...
Only if you write your own non-DPMI, non-Window, non-OS/2 compatible PM
program,
you can gain of faster I/O.
>Of course, the few operations in PM that are slower are definitely made up for in the huge increase in overall
>program speed that can be gained from not constantly checking to see when you've run into an inappropriately
>small 64k segment boundary.
PM/RM has no effect on the segmentation unit. It doesn't matter if the SU has
to check for 64K or 4G.
Herman
Kevin McKerron
Herman Dullink wrote:
> In win32, _all_ I/O instructions are trapped. In win95 to see if you're
> allowed to access this particular I/O port. In Win NT, only device drivers
> are allowed to acces I/O.
> Same story in DPMI, the PM host won't allow you to access the RESET pin of the
> CPU...
> Only if you write your own non-DPMI, non-Window, non-OS/2 compatible PM
> program,
> you can gain of faster I/O.
I know that hardware is virtualized in PM operating systems, but I don't see why there couldn't be a DOS based
DPMI host that wouldn't virtualize anything. In fact, I suspect CWSDPMI doesn't. I am hoping that C.W. Sandmann
(who I've seen post in here) will respond.
> PM/RM has no effect on the segmentation unit. It doesn't matter if the SU has
> to check for 64K or 4G.
I know. What I mean, is that a real mode program that has to manipulate a huge data object, ESPECIALLY if it's
accessed in random order, wastes a lot of time checking and adjusting segment indexes to make up for the 64k
limit. In protected mode, you can just set the segment limit to the object's size, so you need not constantly
adjust the segment. I should have made myself more clear, sorry.
You're right though, some people don't realize that the segmentation unit is still active in real mode, as I
believe I mentioned in a post to someone else.
Later,
Kevin
Yousuf Khan
mcke...@idirect.com (Kevin McKerron) wrote:
>Yousuf Khan wrote:
>> In answer to your question, yes, Protected Mode is overall slower than
>> Real mode for a lot of things: code branching, I/O accesses, interrupt
>> processing, etc. But that's because there is more steps to go through
>> in Protected Mode, to keep everything safe.
>True, many operations are slower in protected mode, but most of them are things that efficient code shouldn't
>be doing frequently, such as changing selectors.
That's right, I wasn't really taking a weighted view of the typical
activities of a typical program, I was just counting cycles on
individual instructions.
>The section of the CPU that handles segment protection and
>memory mapping is active even in real mode (with default limits), although the OS only has control of it when
>in PM.
Actually, an OS in RM could still have control of it. A lot of the
mechanisms are still working and they are triggered by the same
exceptions and faults. They are mapped to the same vectors in RM as
they are in PM. So a RM OS would simply need to intercept those
vectors.
About the only vector not functioning in RM that I can think of is
page faulting. But that's equivalent to a PM OS turning off paging.
>In fact, according to my Microsoft MASM 6.0 Quick Reference, I/O access (that doesn't get trapped) is
>actually FASTER in protected mode. For example,
> in AL,imediate
>takes 14 cycles in real mode, but only 9 in protected mode (on a 486.) Note, though, that this is for untrapped
>I/O. Any I/O the OS intercepts takes 28, plus the time the OS routines take to respond.
Yes, that's one of the wierd ones, which doesn't really make much
common sense, but it's there staring us in the face. It was there with
the 386 as well. I really don't know why the extra five cycles in RM.
What extra could possibly be required to be done in RM?
>Of course, the few operations in PM that are slower are definitely made up for in the huge increase in overall
>program speed that can be gained from not constantly checking to see when you've run into an inappropriately
>small 64k segment boundary.
No doubt.