Board index » delphi » Protected mode vs. Real mode

Protected mode vs. Real mode

Hello!

Im experiencing a slight problem when I'm converting all my programs into
Protected mode applications;
I've made a dottunnel with a weird logo flying around in it... It runs pretty
smooth with Midas and all that stuff included when I compile it in REAL mode,
but it goes really shocky and slow when I compile it in Protected mode. So, I
wonder if ANYONE know why Protected mode slows down my program so much? Is
there a compile flag I've got set that shouldn't be or something like that?
I've tried with the $G+ directive and all that stuff, but it won't go
smooth!

 

Re:Protected mode vs. Real mode


Quote
Barbatron (jol...@rbk.sollentuna.se) wrote:
> Hello!

> Im experiencing a slight problem when I'm converting all my programs into
> Protected mode applications;
> I've made a dottunnel with a weird logo flying around in it... It runs pretty
> smooth with Midas and all that stuff included when I compile it in REAL mode,
> but it goes really shocky and slow when I compile it in Protected mode. So, I
> wonder if ANYONE know why Protected mode slows down my program so much? Is
> there a compile flag I've got set that shouldn't be or something like that?
> I've tried with the $G+ directive and all that stuff, but it won't go
> smooth!

 Programs run slowly in PM because nearly every operation requires to be
seriously tested by the CPU. In major cases the CPU checks the validity of
memory address's reference. For example we have the following code in
assembler:

                mov     es, AnImmediate
                mov     es:[OffsetValue], ax

 In general, CPU will perform the following action here:

1) tests if AnImmediate belongs to Global Descriptor Table (GDT) or Local
one (LDT);
2) tests if the Priviledge Level of AnImmediate meets the PL of the
current process, if no performs other additional checks;
3) looks for AnImmediate'th element in the GDT/LDT;
4) checks if the segment AnImmediate is present in memory;
5) checks the Access Rights of the segment;
6) checks if the OffsetValue is within the range of the segment's limit;
7) if paging is enabled, checks the page(s) validity.

 Eh, great, isn't it?

 I think that the first step in the performance improving will be the
avoiding the segment registers reloading. There're internal cache
registers for segment and system registers that are used for the fast
memory access, because having been loaded a selector CPU won't pass all
the checks next time the code access this segment as it knows that this
selector is valid. Most compilers are too silly to trace if register value
is changed and reload registers all the time. So I'm afraid you need to
write your own stuff.
 If this won't do any good, use Direct Memory Access (DMA).

  Option {+G} won't improve the performance because it only tells the
compiler to use new instruction set, i.e. instead of

                        push    bp
                        mov     bp, sp

it geneartes
                        enter   XXXX, XX.

Regards,
Alex.
nin...@redline.ru,
myacco...@glas.apc.org

Other Threads