Re: Slightly off-topic: a question on the Pentium arc hitecture

My copy of the architecture spec (Vol III, 3.4.2, p 3-9) indicates that
software must reload segment registers when the descriptor tables are
modified (and I think modifying CR3 to select a different GDT counts as
modifying the GDT); setting CR3 will invalidate the TLB and therefore cause
GDT accesses to go through the new translation, but the processor wont know
that it needs to load new descriptor info into the hidden portions of the
segment registers unless you explicitely reload these registers (with the
same values)

/simgr

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, January 14, 2003 10:20 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium arc
hitecture

I actually mean the GDT. Let me give you some background. I’m trying to
figure out if it is possible to context-switch in a Pentium by (1) saving
registers, (2) frigging CR3, (3) restoring registers, (4) return to caller.
This would mean that every process has its own GDT precisely at the same
linear address (and possibly its own TSS, also at the same GDT offset), so
that changing CR3 would flip the virtual to physical memory mapping
underneath the segment registers but not the virtual addresses themselves.
This is for my OS class at college. The feasibility of the scheme hinges on
how the segment register cache works, and that’s not very well documented in
the P4 books.

So, the question is, can I switch GDTs under the CS/DS/SS’s very nose by
just changing CR3, and not bothering to save and restore the segment
registers ?

Alberto.

-----Original Message-----
From: Andy Champ [mailto:xxxxx@earthling.net]
Sent: Tuesday, January 14, 2003 4:32 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium
architecture

Alberto,
I can’t imagine what you ar doing that requires this (writing your own
kernel?) and I’m terribly out of date but since no-one else has commented…
CR3 is the task’s PDBR. It’s normally loaded on a task switch - indeed
my Pentium manual excludes mov cr3,xxx from the list of operations.
(You can only move to CR0, CR2, CR4, or from any of CR0 1 2 3 4.)
Also I think you mean the task’s LDT not GDT…
IMHO exploring the dusty corners of the CPU like this, instead of task
switching in the way Intel intended, is a recipe for finding obscure
bugs in the CPU. Certainly if you do something that is not documented
it may not work on all the CPUs. Don’t forget to allow for AMD & Cyrix!
The PIII manual says
“These instructions have the following side effects:
* When writing to control register CR3, all non-global TLB entries are
flushed. Refer to Section 3.7., Translation Lookaside Buffers (TLBs) in
Chapter 3, Protected-Mode Memory Management of the Intel Architecture
Software Developer’s Manual, Volume 3, for a detailed description of the
flags and fields in the control registers.”
which seems to mean you are in the clear on the PIII. I don’t have the
position on the PII, and I’d guess the PIV does the same. The specs are
IAC downloadable at
http://developer.intel.com/design/Pentium4/manuals/
http://developer.intel.com/design/PentiumIII/manuals/
http://developer.intel.com/design/PentiumII/manuals/
http://developer.intel.com/design/Pentium/manuals/
http://developer.intel.com/design/celeron/manuals/

then there’s another set on the AMD site…

Hope this helps a little.

Andy

Moreira, Alberto wrote:

This is a trifle off-topic, but maybe some of you guys have an answer.
Assume each process has its own GDT with say, three entries: a code
segment at position 1, a data segment at position 2 and a tss at
position 3. Assume that I switch from process A to process B by writing
CR3.

If I use a sequence like

mov cr3,eax

mov eax,[ds+blah]

I take that the base address for ds is taken from the ds register
cache and not from the new GDT ? Or is the architecture intelligent
enough to reload the cache on the fly from the descriptor in the new GDT
? Furthermore, if I intersperse a ds load, such as

mov cr3,eax
mov eax,2;
mov ds,eax
mov eax,[ds+blah]

Does the ds register cache get reloaded, or is the processor too
intelligent for its own good, and assumes that because the selector
being loaded is the same as before, there’s no need to reload ?

Thanks if anyone can shed any light !

Alberto.

The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please notify
us immediately and then destroy it.


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.


You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

I kind of believe that if neither CS, DS nor SS changes from process to
process, switching CR3 might work. If we assume flat mode, for example, and
fixed segment descriptors offsets in the GDT, neither CS, DS nor SS will
change when I context-switch, neither will their caches.

Say that every GDT has a few fixed descriptors, for example,

System CS points to GDT offset 8,
System DS to GDT offset 16,
System SS to GDT offset 24,
User CS points to GDT offset 32,
User DS to GDT offset 40,
User SS to GDT offset 44,
All CS, DS and SS selectors map the whole memory.

I could swap GDTs by flipping CR3, and neither the GDTR, CS, DS nor SS would
know I did it, neither would their caches - after all the whole
segmentation stuff operates on linear addresses. A possible switching
sequence could be,

push edi
push esi
mov esi,thisprocessid
mov edi,nextprocessid
push eax
push ebx
push ecx
push edx
push ebp
mov [esi*savesize+savearea],esp
mov eax,[edi+cr3image]
mov cr3,eax
mov esp,[edi*savesize+savearea]
pop ebp
pop edx
pop ecx
pop ebx
pop eax
pop esi
pop edi
ret

Note that if the “savearea” only keeps each process’s esp and cr3,
“savesize” will be 8. I can’t see any flaw with this scheme, but I may be
missing something !

Alberto.

-----Original Message-----
From: Graham, Simon [mailto:xxxxx@stratus.com]
Sent: Tuesday, January 14, 2003 11:23 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium arc
hitecture

My copy of the architecture spec (Vol III, 3.4.2, p 3-9) indicates that
software must reload segment registers when the descriptor tables are
modified (and I think modifying CR3 to select a different GDT counts as
modifying the GDT); setting CR3 will invalidate the TLB and therefore cause
GDT accesses to go through the new translation, but the processor wont know
that it needs to load new descriptor info into the hidden portions of the
segment registers unless you explicitely reload these registers (with the
same values)

/simgr

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, January 14, 2003 10:20 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium arc
hitecture

I actually mean the GDT. Let me give you some background. I’m trying to
figure out if it is possible to context-switch in a Pentium by (1) saving
registers, (2) frigging CR3, (3) restoring registers, (4) return to caller.
This would mean that every process has its own GDT precisely at the same
linear address (and possibly its own TSS, also at the same GDT offset), so
that changing CR3 would flip the virtual to physical memory mapping
underneath the segment registers but not the virtual addresses themselves.
This is for my OS class at college. The feasibility of the scheme hinges on
how the segment register cache works, and that’s not very well documented in
the P4 books.

So, the question is, can I switch GDTs under the CS/DS/SS’s very nose by
just changing CR3, and not bothering to save and restore the segment
registers ?

Alberto.

-----Original Message-----
From: Andy Champ [mailto:xxxxx@earthling.net]
Sent: Tuesday, January 14, 2003 4:32 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium
architecture

Alberto,
I can’t imagine what you ar doing that requires this (writing your own
kernel?) and I’m terribly out of date but since no-one else has commented…
CR3 is the task’s PDBR. It’s normally loaded on a task switch - indeed
my Pentium manual excludes mov cr3,xxx from the list of operations.
(You can only move to CR0, CR2, CR4, or from any of CR0 1 2 3 4.)
Also I think you mean the task’s LDT not GDT…
IMHO exploring the dusty corners of the CPU like this, instead of task
switching in the way Intel intended, is a recipe for finding obscure
bugs in the CPU. Certainly if you do something that is not documented
it may not work on all the CPUs. Don’t forget to allow for AMD & Cyrix!
The PIII manual says
“These instructions have the following side effects:
* When writing to control register CR3, all non-global TLB entries are
flushed. Refer to Section 3.7., Translation Lookaside Buffers (TLBs) in
Chapter 3, Protected-Mode Memory Management of the Intel Architecture
Software Developer’s Manual, Volume 3, for a detailed description of the
flags and fields in the control registers.”
which seems to mean you are in the clear on the PIII. I don’t have the
position on the PII, and I’d guess the PIV does the same. The specs are
IAC downloadable at
http://developer.intel.com/design/Pentium4/manuals/
http://developer.intel.com/design/PentiumIII/manuals/
http://developer.intel.com/design/PentiumII/manuals/
http://developer.intel.com/design/Pentium/manuals/
http://developer.intel.com/design/celeron/manuals/

then there’s another set on the AMD site…

Hope this helps a little.

Andy

Moreira, Alberto wrote:

This is a trifle off-topic, but maybe some of you guys have an answer.
Assume each process has its own GDT with say, three entries: a code
segment at position 1, a data segment at position 2 and a tss at
position 3. Assume that I switch from process A to process B by writing
CR3.

If I use a sequence like

mov cr3,eax

mov eax,[ds+blah]

I take that the base address for ds is taken from the ds register
cache and not from the new GDT ? Or is the architecture intelligent
enough to reload the cache on the fly from the descriptor in the new GDT
? Furthermore, if I intersperse a ds load, such as

mov cr3,eax
mov eax,2;
mov ds,eax
mov eax,[ds+blah]

Does the ds register cache get reloaded, or is the processor too
intelligent for its own good, and assumes that because the selector
being loaded is the same as before, there’s no need to reload ?

Thanks if anyone can shed any light !

Alberto.

The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please notify
us immediately and then destroy it.


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.


You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

That seems reasonable; what about the other segment registers and the LDTR?
Will they be the same as well?

/simgr

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, January 14, 2003 1:40 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium arc
hitecture

I kind of believe that if neither CS, DS nor SS changes from process to
process, switching CR3 might work. If we assume flat mode, for example, and
fixed segment descriptors offsets in the GDT, neither CS, DS nor SS will
change when I context-switch, neither will their caches.

Say that every GDT has a few fixed descriptors, for example,

System CS points to GDT offset 8,
System DS to GDT offset 16,
System SS to GDT offset 24,
User CS points to GDT offset 32,
User DS to GDT offset 40,
User SS to GDT offset 44,
All CS, DS and SS selectors map the whole memory.

I could swap GDTs by flipping CR3, and neither the GDTR, CS, DS nor SS would
know I did it, neither would their caches - after all the whole
segmentation stuff operates on linear addresses. A possible switching
sequence could be,

push edi
push esi
mov esi,thisprocessid
mov edi,nextprocessid
push eax
push ebx
push ecx
push edx
push ebp
mov [esi*savesize+savearea],esp
mov eax,[edi+cr3image]
mov cr3,eax
mov esp,[edi*savesize+savearea]
pop ebp
pop edx
pop ecx
pop ebx
pop eax
pop esi
pop edi
ret

Note that if the “savearea” only keeps each process’s esp and cr3,
“savesize” will be 8. I can’t see any flaw with this scheme, but I may be
missing something !

Alberto.

-----Original Message-----
From: Graham, Simon [mailto:xxxxx@stratus.com]
Sent: Tuesday, January 14, 2003 11:23 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium arc
hitecture

My copy of the architecture spec (Vol III, 3.4.2, p 3-9) indicates that
software must reload segment registers when the descriptor tables are
modified (and I think modifying CR3 to select a different GDT counts as
modifying the GDT); setting CR3 will invalidate the TLB and therefore cause
GDT accesses to go through the new translation, but the processor wont know
that it needs to load new descriptor info into the hidden portions of the
segment registers unless you explicitely reload these registers (with the
same values)

/simgr

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, January 14, 2003 10:20 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium arc
hitecture

I actually mean the GDT. Let me give you some background. I’m trying to
figure out if it is possible to context-switch in a Pentium by (1) saving
registers, (2) frigging CR3, (3) restoring registers, (4) return to caller.
This would mean that every process has its own GDT precisely at the same
linear address (and possibly its own TSS, also at the same GDT offset), so
that changing CR3 would flip the virtual to physical memory mapping
underneath the segment registers but not the virtual addresses themselves.
This is for my OS class at college. The feasibility of the scheme hinges on
how the segment register cache works, and that’s not very well documented in
the P4 books.

So, the question is, can I switch GDTs under the CS/DS/SS’s very nose by
just changing CR3, and not bothering to save and restore the segment
registers ?

Alberto.

-----Original Message-----
From: Andy Champ [mailto:xxxxx@earthling.net]
Sent: Tuesday, January 14, 2003 4:32 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium
architecture

Alberto,
I can’t imagine what you ar doing that requires this (writing your own
kernel?) and I’m terribly out of date but since no-one else has commented…
CR3 is the task’s PDBR. It’s normally loaded on a task switch - indeed
my Pentium manual excludes mov cr3,xxx from the list of operations.
(You can only move to CR0, CR2, CR4, or from any of CR0 1 2 3 4.)
Also I think you mean the task’s LDT not GDT…
IMHO exploring the dusty corners of the CPU like this, instead of task
switching in the way Intel intended, is a recipe for finding obscure
bugs in the CPU. Certainly if you do something that is not documented
it may not work on all the CPUs. Don’t forget to allow for AMD & Cyrix!
The PIII manual says
“These instructions have the following side effects:
* When writing to control register CR3, all non-global TLB entries are
flushed. Refer to Section 3.7., Translation Lookaside Buffers (TLBs) in
Chapter 3, Protected-Mode Memory Management of the Intel Architecture
Software Developer’s Manual, Volume 3, for a detailed description of the
flags and fields in the control registers.”
which seems to mean you are in the clear on the PIII. I don’t have the
position on the PII, and I’d guess the PIV does the same. The specs are
IAC downloadable at
http://developer.intel.com/design/Pentium4/manuals/
http://developer.intel.com/design/PentiumIII/manuals/
http://developer.intel.com/design/PentiumII/manuals/
http://developer.intel.com/design/Pentium/manuals/
http://developer.intel.com/design/celeron/manuals/

then there’s another set on the AMD site…

Hope this helps a little.

Andy

Moreira, Alberto wrote:

This is a trifle off-topic, but maybe some of you guys have an answer.
Assume each process has its own GDT with say, three entries: a code
segment at position 1, a data segment at position 2 and a tss at
position 3. Assume that I switch from process A to process B by writing
CR3.

If I use a sequence like

mov cr3,eax

mov eax,[ds+blah]

I take that the base address for ds is taken from the ds register
cache and not from the new GDT ? Or is the architecture intelligent
enough to reload the cache on the fly from the descriptor in the new GDT
? Furthermore, if I intersperse a ds load, such as

mov cr3,eax
mov eax,2;
mov ds,eax
mov eax,[ds+blah]

Does the ds register cache get reloaded, or is the processor too
intelligent for its own good, and assumes that because the selector
being loaded is the same as before, there’s no need to reload ?

Thanks if anyone can shed any light !

Alberto.

The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please notify
us immediately and then destroy it.


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.


You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.


You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The other segment registers will have to be saved and restored accordingly.
The LDT may also come in the wash, because it’s defined by a descriptor in
the user’s GDT; although I suspect one might need to fix the LDT size to be
equal for every process. The weak link is, of course, that it’s not possible
to prevent users from reloading DS or SS, which would throw a monkey wrench
into this scheme.

Alberto.

-----Original Message-----
From: Graham, Simon [mailto:xxxxx@stratus.com]
Sent: Wednesday, January 15, 2003 5:08 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium arc
hitecture

That seems reasonable; what about the other segment registers and the LDTR?
Will they be the same as well?

/simgr

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, January 14, 2003 1:40 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium arc
hitecture

I kind of believe that if neither CS, DS nor SS changes from process to
process, switching CR3 might work. If we assume flat mode, for example, and
fixed segment descriptors offsets in the GDT, neither CS, DS nor SS will
change when I context-switch, neither will their caches.

Say that every GDT has a few fixed descriptors, for example,

System CS points to GDT offset 8,
System DS to GDT offset 16,
System SS to GDT offset 24,
User CS points to GDT offset 32,
User DS to GDT offset 40,
User SS to GDT offset 44,
All CS, DS and SS selectors map the whole memory.

I could swap GDTs by flipping CR3, and neither the GDTR, CS, DS nor SS would
know I did it, neither would their caches - after all the whole
segmentation stuff operates on linear addresses. A possible switching
sequence could be,

push edi
push esi
mov esi,thisprocessid
mov edi,nextprocessid
push eax
push ebx
push ecx
push edx
push ebp
mov [esi*savesize+savearea],esp
mov eax,[edi+cr3image]
mov cr3,eax
mov esp,[edi*savesize+savearea]
pop ebp
pop edx
pop ecx
pop ebx
pop eax
pop esi
pop edi
ret

Note that if the “savearea” only keeps each process’s esp and cr3,
“savesize” will be 8. I can’t see any flaw with this scheme, but I may be
missing something !

Alberto.

-----Original Message-----
From: Graham, Simon [mailto:xxxxx@stratus.com]
Sent: Tuesday, January 14, 2003 11:23 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium arc
hitecture

My copy of the architecture spec (Vol III, 3.4.2, p 3-9) indicates that
software must reload segment registers when the descriptor tables are
modified (and I think modifying CR3 to select a different GDT counts as
modifying the GDT); setting CR3 will invalidate the TLB and therefore cause
GDT accesses to go through the new translation, but the processor wont know
that it needs to load new descriptor info into the hidden portions of the
segment registers unless you explicitely reload these registers (with the
same values)

/simgr

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Tuesday, January 14, 2003 10:20 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium arc
hitecture

I actually mean the GDT. Let me give you some background. I’m trying to
figure out if it is possible to context-switch in a Pentium by (1) saving
registers, (2) frigging CR3, (3) restoring registers, (4) return to caller.
This would mean that every process has its own GDT precisely at the same
linear address (and possibly its own TSS, also at the same GDT offset), so
that changing CR3 would flip the virtual to physical memory mapping
underneath the segment registers but not the virtual addresses themselves.
This is for my OS class at college. The feasibility of the scheme hinges on
how the segment register cache works, and that’s not very well documented in
the P4 books.

So, the question is, can I switch GDTs under the CS/DS/SS’s very nose by
just changing CR3, and not bothering to save and restore the segment
registers ?

Alberto.

-----Original Message-----
From: Andy Champ [mailto:xxxxx@earthling.net]
Sent: Tuesday, January 14, 2003 4:32 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Slightly off-topic: a question on the Pentium
architecture

Alberto,
I can’t imagine what you ar doing that requires this (writing your own
kernel?) and I’m terribly out of date but since no-one else has commented…
CR3 is the task’s PDBR. It’s normally loaded on a task switch - indeed
my Pentium manual excludes mov cr3,xxx from the list of operations.
(You can only move to CR0, CR2, CR4, or from any of CR0 1 2 3 4.)
Also I think you mean the task’s LDT not GDT…
IMHO exploring the dusty corners of the CPU like this, instead of task
switching in the way Intel intended, is a recipe for finding obscure
bugs in the CPU. Certainly if you do something that is not documented
it may not work on all the CPUs. Don’t forget to allow for AMD & Cyrix!
The PIII manual says
“These instructions have the following side effects:
* When writing to control register CR3, all non-global TLB entries are
flushed. Refer to Section 3.7., Translation Lookaside Buffers (TLBs) in
Chapter 3, Protected-Mode Memory Management of the Intel Architecture
Software Developer’s Manual, Volume 3, for a detailed description of the
flags and fields in the control registers.”
which seems to mean you are in the clear on the PIII. I don’t have the
position on the PII, and I’d guess the PIV does the same. The specs are
IAC downloadable at
http://developer.intel.com/design/Pentium4/manuals/
http://developer.intel.com/design/PentiumIII/manuals/
http://developer.intel.com/design/PentiumII/manuals/
http://developer.intel.com/design/Pentium/manuals/
http://developer.intel.com/design/celeron/manuals/

then there’s another set on the AMD site…

Hope this helps a little.

Andy

Moreira, Alberto wrote:

This is a trifle off-topic, but maybe some of you guys have an answer.
Assume each process has its own GDT with say, three entries: a code
segment at position 1, a data segment at position 2 and a tss at
position 3. Assume that I switch from process A to process B by writing
CR3.

If I use a sequence like

mov cr3,eax

mov eax,[ds+blah]

I take that the base address for ds is taken from the ds register
cache and not from the new GDT ? Or is the architecture intelligent
enough to reload the cache on the fly from the descriptor in the new GDT
? Furthermore, if I intersperse a ds load, such as

mov cr3,eax
mov eax,2;
mov ds,eax
mov eax,[ds+blah]

Does the ds register cache get reloaded, or is the processor too
intelligent for its own good, and assumes that because the selector
being loaded is the same as before, there’s no need to reload ?

Thanks if anyone can shed any light !

Alberto.

The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please notify
us immediately and then destroy it.


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.


You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.


You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.